A-record

En A-record er en post i DNS, som forbinder et domænenavn med en IPv4-adresse. Når en bruger skriver et domæne i browseren, hjælper DNS med at finde den server, der skal svare. A-recorden er en af de mest almindelige forbindelser i den proces.

Bogstavet A står for address. Et eksempel kan være, at eksempel.dk peger på IP-adressen 203.0.113.10. IP-adressen identificerer den server eller tjeneste, som skal modtage webtrafikken.

En A-record kan gælde for selve domænet eller et subdomæne. shop.eksempel.dk kan pege på én server, mens eksempel.dk peger på en anden. Derfor er det vigtigt at se på både værtsnavn og værdi, ikke kun på domænet som helhed.

A-recorden er tæt forbundet med hosting, men de er ikke det samme. Hosting er den serverplads og drift, hvor siden ligger. DNS-posten fortæller, hvor domænet skal finde den. Man kan flytte hosting uden at flytte domænet ved at ændre DNS.

Den bruger IPv4-adresser. Den tilsvarende record til IPv6 kaldes AAAA. Mange almindelige opsætninger bruger fortsat A-recorden som den centrale post for webtrafik.

Find først den korrekte IP-adresse hos hostingudbyderen eller platformen. Kopiér den præcist. En enkelt forkert ciffergruppe kan sende domænet til en anden server eller gøre hjemmesiden utilgængelig.

Kontrollér værtsfeltet. Nogle kontrolpaneler bruger @ for roddomænet, andre viser domænenavnet, og enkelte forventer et tomt felt. Følg udbyderens format i stedet for at gætte.

Se på www-versionen. Den kan have sin egen A-record eller være en CNAME, der peger på roddomænet. Begge dele kan fungere, men opsætningen skal være konsekvent med webserverens redirects og canonical.

Planlæg ændringen med TTL. En lavere TTL før en flytning kan få nye opslag til at hente den ændrede IP hurtigere. Sænk værdien i god tid, fordi eksisterende caches beholder den gamle TTL, indtil den udløber.

Dokumentér den gamle værdi. Tag et skærmbillede eller eksportér zonen, før du ændrer noget. Hvis den nye server ikke svarer korrekt, kan I hurtigt pege tilbage uden at lede efter den tidligere IP.

Test efter ændringen fra flere netværk og med et DNS-opslag. Browserens egen cache kan vise den gamle side, selv om posten er korrekt opdateret. Kontrollér også SSL, redirects og formularer på den nye server.

En virksomhed får bygget en ny hjemmeside på en ny server. Domænet og mailen bliver hos den nuværende udbyder. To dage før lancering sænkes TTL på den A-record, der peger webtrafikken mod serveren, fra 86.400 til 300 sekunder.

På lanceringsdagen ændres A-recorden til den nye server-IP. MX-records og øvrige mailposter røres ikke. Efter få minutter begynder nye DNS-opslag at pege på den nye side, mens enkelte brugere kortvarigt kan se den gamle på grund af cache.

Webserveren er på forhånd sat op til både domænet med og uden www, og et gyldigt SSL-certifikat er klar. Derfor ender brugerne ikke på en sikkerhedsadvarsel, når DNS skifter.

I et dårligt forløb ændrer en medarbejder alle DNS-poster, fordi “hjemmesiden skal flyttes”. Både A-, MX- og TXT-poster slettes og erstattes med en standardzone. Websitet kommer online, men virksomhedens mail stopper. Fejlen skyldes ikke A-recorden alene, men manglende forståelse af zonen.

Eksemplet viser, hvorfor en webflytning bør afgrænses. Den nye hjemmeside kræver måske kun én eller to ændringer. Resten af DNS kan have funktioner, som ikke er synlige i browseren.

Den største faldgrube er at ændre roddomænets A-record uden at kontrollere subdomæner. En gammel DNS-record for www kan fortsat pege et andet sted, så brugere får forskellige sider afhængigt af adressen.

En anden fejl er at bruge en privat IP-adresse som 192.168.x.x. Den virker kun på et lokalt netværk og kan ikke bruges som offentlig destination for et almindeligt website.

Pas også på delte servere. En A-record sender trafikken til en IP, men serveren skal vide, hvilket domæne der efterspørges. Hvis domænet ikke er tilføjet på hostingen, kan serveren vise en standardside eller en anden fejl.

Endelig bør man ikke forvente øjeblikkelig ens visning overalt. DNS er distribueret og cachet. Ændringen kan være korrekt, selv om enkelte netværk fortsat ser den gamle værdi i en periode.

A-recorden indeholder ikke en mappe eller en fuld URL. Den kan ikke pege direkte på eksempel.dk/ny-side/. Den peger kun værtsnavnet mod en IPv4-adresse. Omdirigering til en bestemt sti sker på webserveren eller gennem en redirect-tjeneste.

Flere A-records kan bruges på samme navn. Det kan fordele eller give redundans, men opsætningen kræver, at alle destinationer kan håndtere samme website korrekt. Det er ikke en simpel backup, hvis serverne har forskelligt indhold.

En CDN- eller cloudtjeneste kan bede om en CNAME i stedet for en A-record. Følg den konkrete leverandørs instruktion. A-recorden er grundlæggende, men ikke altid den bedste eller mulige løsning for hvert værtsnavn.

Nameserverne bestemmer, hvor den autoritative DNS-zone ligger. Du skal ændre A-recorden i det system, som nameserverne faktisk peger på. En ændring i et gammelt kontrolpanel har ingen effekt, hvis zonen styres et andet sted.

For en webshop bør lancering også kontrollere betaling, callbacks og tredjepartsintegrationer. Selve A-recorden kan være korrekt, mens en ekstern service stadig sender data til en gammel URL eller blokeres af den nye server.

En A-record kan bruges til et wildcard som *.eksempel.dk, så mange ikke-definerede subdomæner peger på samme IP. Det kan være praktisk i bestemte platforme, men kan også skjule stavefejl og skabe utilsigtede værtsnavne. Brug wildcard bevidst.

Hvis domænet ligger bag et CDN, kan DNS-panelet vise en proxy-status ud over IP-adressen. I den situation kan den offentlige IP være CDN’ens og ikke origin-serverens. Ændringer bør følge CDN-udbyderens arkitektur.

IPv4-adressen i dokumentationseksempler bør ikke kopieres til en rigtig zone. Adresser som 192.0.2.0/24 og 203.0.113.0/24 er reserveret til eksempler. Den virkelige værdi skal altid komme fra den konkrete hostingudbyder.

På delt hosting kan flere domæner bruge samme IP. Det er normalt. Webserveren skelner mellem dem via værtsnavnet. Derfor er en “unik IP” ikke et krav for en almindelig virksomhedshjemmeside.

Når en gammel server udfases, bør den holdes tilgængelig længe nok til at håndtere resterende cache og tilbagerulning. Slukker man den i samme sekund A-recorden ændres, kan brugere med gammel DNS-cache møde en fejl, selv om den nye opsætning er korrekt.

Et DNS-opslag kan returnere flere IP-adresser på skift. Det kan være bevidst load balancing, men hvis kun én server har den nyeste kode, får brugerne et tilfældigt resultat. Alle adresser under samme navn skal derfor være planlagt som en samlet løsning.

Ved brug af en proxy kan den oprindelige server være skjult. Hvis en udvikler ændrer A-recorden direkte til origin-IP’en, kan sikkerhedsregler, cache og beskyttelse blive omgået. Kontrollér om den viste record er “proxied” eller ren DNS.

En ændring bør desuden koordineres med overvågning. Når det nye endpoint går live, skal HTTP-status, svartid og certifikat kontrolleres automatisk eller manuelt. DNS-succes er kun det første trin i en fungerende lancering.

Et stagingmiljø bør ikke bruge samme A-record som produktionen, medmindre serveren er konfigureret til at skelne tydeligt mellem værtsnavnene. Brug et separat subdomæne og beskyt det mod indeksering, så testversionen ikke bliver fundet af Google.

Når en ekstern leverandør beder om at ændre A-recorden, bør virksomheden få målet og formålet skriftligt. “Peg domænet på vores server” er ikke nok dokumentation. Den nye IP, lanceringsdato og plan for tilbageførsel skal være kendt.

Kontrollér til sidst den offentlige IP fra mere end ét DNS-værktøj, så en lokal cache ikke bliver forvekslet med den autoritative opsætning.

Læs også om forskellen på HTTP og HTTPS, hvis du vil forstå, hvad der sker, efter DNS har sendt besøgende hen til webserveren.