Et DNS ændring er sjældent det mest synlige punkt i en migrering, men det er ofte her, små fejl bliver dyre. Selve hjemmesiden kan være flyttet korrekt, databasen kan være på plads, og designet kan se fint ud på den nye løsning, men hvis DNS ikke er forberedt ordentligt, kan brugere stadig ramme den gamle server, få fejl i emaillevering eller opleve en periode, hvor siden virker ustabil.
Det gode er, at unødig nedetid som regel kan undgås. Nøglen er ikke at skynde sig med ændringen af navneservere, men at forberede zonen grundigt, sænke relevante TTL værdier i tide og kontrollere, at den nye DNS zone matcher den gamle, før domænet peger om.
Når man taler om DNS ændring, mener man ofte flere ting på én gang. Nogle gange handler det kun om at ændre et A record eller et CNAME, så domænet peger på en ny server. Andre gange flytter man hele administrationen af DNS til en ny provider, hvilket betyder, at domænets navneservere også skal ændres.
Det er en vigtig forskel.
Hvis du kun ændrer enkelte records i den eksisterende zone, bliver den autoritative DNS den samme. Hvis du flytter hele zonen, skal du først oprette alle records det nye sted og derefter opdatere navneserverne hos registraren. AWS beskriver netop denne arbejdsgang i deres guide til migrering af en hosted zone: forbered migrationen, opret ny zone, migrer records, sammenlign gammel og ny zone, og skift først derefter navneservere.
DNS fungerer heller ikke som en kontakt der slås om med det samme. Resolvers cacher svar i en periode, og derfor kan to brugere godt få forskellige svar i overgangsfasen. Den ene kan se den nye side, mens den anden stadig sendes til den gamle server. Det er normalt under propagation, men det stiller krav til planlægningen.
Den mest almindelige årsag er ikke selve skiftet, men at den nye DNS zone ikke er komplet, når navneserverne ændres. Hvis et vigtigt record mangler, bliver problemet synligt, så snart en resolver begynder at spørge den nye zone i stedet for den gamle.
En anden klassiker er, at TTL er sat for højt. Så kan gamle svar blive liggende længe i cache, og ændringerne slår langsomt igennem.
Typiske fejl under migrering af DNS er ofte disse:
Der er også et mere grundlæggende problem, som let overses: Hvis registraren ikke peger på de navneservere, der hører til den nye zone, er den nye zone ikke autoritativ for domænet. Så hjælper det ikke, at alle records er sat korrekt op i den nye DNS løsning. Brugerne spørger ganske enkelt det forkerte sted.
TTL står for “time to live” og angiver, hvor længe et DNS svar må caches hos en resolver. Cloudflare beskriver TTL som det felt, der styrer, hvor længe et record caches, og dermed hvor lang tid det tager, før ændringer når frem til slutbrugere. Jo højere TTL, desto længere kan gamle oplysninger blive brugt.
Det betyder ikke, at lav TTL altid er bedst. Høj TTL giver mere cache og færre opslag, hvilket kan være fint i stabil drift. Ved en migrering vil man ofte gerne have hurtigere gennemslag, og derfor kan det være en fordel at sænke TTL i god tid, inden man ændrer records eller navneservere.
AWS nævner også, at en lavere TTL for NS recordet kan reducere nedetid, hvis der opstår problemer under migreringen af DNS. De angiver 172800 sekunder som en typisk TTL for NS records. Det svarer til to døgn, og det illustrerer meget godt, hvorfor ændring af navneservere nogle gange tager længere tid end forventet.
| Element | Hvad det betyder | Betydning ved migrering |
|---|---|---|
| TTL | Hvor længe et DNS svar må caches | Afgør hvor hurtigt ændringer slår igennem |
| NS record | Record der angiver navneservere | Kritisk ved flytning af hele DNS zonen |
| Navneservere | De servere der svarer autoritativt for domænet | Skal først skiftes, når ny zone er klar |
| Resolver cache | Midlertidigt gemte DNS svar hos brugernes netværk | Kan give blandede resultater i en overgang |
| Autoritativ zone | Den zone som domænet reelt peger på | Det er denne zone, der skal være komplet |
Selv med lav TTL er der ikke garanti for øjeblikkeligt gennemslag. ICANN peger på, at nogle resolvere kan cappe TTL værdier i deres caches. Det er en af grundene til, at man ikke bør planlægge et DNS ændring som en præcis sekund for sekund ændring.
God forberedelse handler om kontrol, ikke hastværk. Når hele DNS zonen flyttes, bør du betragte opgaven som en sammenligning mellem gammel og ny opsætning. Først når de to matcher, giver det mening at pege domænet om.
Den mest robuste arbejdsgang ligner i praksis den, AWS anbefaler. Den fungerer godt, uanset om du flytter en WordPress Hjemmeside, en WooCommerce webshop eller et almindeligt webhotel med flere tjenester knyttet til samme domæne.
En praktisk tjekliste kan se sådan ud:
Hvis du bruger en hostingpartner, der også hjælper med migrering, er det en fordel at afklare ansvarsfordelingen tidligt. Hvem opretter records, hvem kontrollerer email, og hvem opdaterer navneservere hos registraren? Mange problemer opstår, fordi alle tror, at en anden har styr på DNS.
Hostious har også et artikelunivers om fejlfinding og DNS, som kan være relevant i planlægningsfasen, især hvis du arbejder med WordPress migrering eller grundlæggende fejl i DNS: hostious.io/category/fejlfinding/.
Ved en almindelig præsentationsside er konsekvensen af et blandet DNS svar typisk begrænset. Ved WordPress kan det stadig give problemer med login, formularer, cache og medieuploads, hvis gamle og nye miljøer ikke er helt ens.
Ved WooCommerce er kravene højere. Hvis nogle besøgende rammer den gamle side og andre den nye, kan ordredata, lagerstatus og transaktionsforløb blive ujævne i overgangsfasen. Derfor bør webshopmigrering planlægges ekstra stramt, og selve skiftet bør ske i et tidsrum, hvor der er overblik over drift og support.
Det gælder også email, som ofte glemmes, når fokus er på selve websitet.
Når et domæne flyttes, bør disse områder gennemgås særskilt:
Hvis DNSSEC er i brug, bør ændringer håndteres af en teknisk ansvarlig. En fejl her kan gøre domænet utilgængeligt, selv om de almindelige records ser rigtige ud. Tag altid backup af relevante indstillinger, og brug gerne staging eller en testplan, før du ændrer noget i produktion.
Den nye hosting skal være testet, før DNS peger brugerne over. Det lyder oplagt, men mange nøjes med at tjekke forsiden og et par undersider. Det er sjældent nok.
En test bør dække de funktioner, der faktisk skaber værdi på siden. På en WordPress Hjemmeside kan det være kontaktformularer, søgning, login, plugins og mediebibliotek. På en WooCommerce side bør checkout, ordreflow, betalingsintegrationer, emails og eventuelle fragtmoduler indgå.
Hvis hostingpartneren tilbyder staging eller en midlertidig testadresse, er det ofte den sikreste vej. Så kan du validere det nye miljø uden at forstyrre det aktive domæne. Hvis mere tekniske testmetoder overvejes, bør de udføres af en ansvarlig med erfaring i DNS og migrering, så der ikke opstår sideeffekter i produktion.
Når alt er forberedt, bør selve skiftet være så enkelt som muligt. Det er ikke dagen, hvor man vil improvisere.
En kort og kontrolleret arbejdsgang kan være:
Det sidste punkt er vigtigt. Selvom navneserverne er ændret, kan caches ude på nettet stadig sende brugere til den gamle løsning i en periode. Derfor bør den gamle installation ikke lukkes ned for tidligt, hvis der er risiko for, at brugere stadig lander dér.
Det er nemt at tro, at arbejdet er færdigt, når forsiden loader korrekt. Men mange fejl i DNS viser sig først lidt senere.
Email er den klassiske efternøler. Hjemmesiden virker, men MX record eller TXT records er ikke fulgt med, og så begynder leveringsproblemer, fejl i afsendergodkendelse eller manglende modtagelse af beskeder. Det er særligt kritisk for ordremails, formularer og supportadresser.
Subdomæner bliver også tit overset. Det kan være shop.domæne.dk, medlem.domæne.dk, mail.domæne.dk eller mere interne opsætninger til tracking, API eller tredjepartsintegrationer. Hvis de kun findes i den gamle zone, får du fejl, så snart den nye zone bliver autoritativ.
En tredje fejl er at glemme at hæve TTL igen efter migreringen. Lav TTL er praktisk under ændringer, men i almindelig drift kan det give unødigt mange opslag. Når alt er stabilt, kan TTL justeres tilbage til et niveau, der passer til den løbende drift.
Arbejdet med DNS er ikke helt det samme for alle løsninger. Et webhotel med hjemmeside og email på samme domæne kræver typisk særlig opmærksomhed på MX og TXT records. En WordPress hosting flytter ofte fokus til webtrafik, cache og afhængigheder mellem plugins. En WooCommerce hosting kræver ekstra kontrol af checkout, mails og datakonsistens under skiftet.
Derfor er det en fordel at vælge hjælp, hvor hjemmeside, email og DNS bliver set i sammenhæng. Hvis du vil forberede en migrering bedre, kan du starte i Hostious’ eksisterende artikler om DNS og fejlfinding: hostious.io/category/fejlfinding/. Her findes blandt andet indhold om grundlæggende DNS og flytning af WordPress Hjemmesider.
Når DNS ændring planlægges roligt og i den rigtige rækkefølge, bliver det sjældent dramatisk. Det handler mest af alt om disciplin: sænk TTL i tide, kopiér records korrekt, sammenlign zoner grundigt, og skift først navneservere, når den nye opsætning faktisk er klar.
Fra minutter til døgn – det styres af TTL. Sænk TTL til fx 300 sekunder i god tid før skiftet, så går overgangen hurtigt, og en eventuel rollback gør det samme.
DNS-cache hos internetudbydere og i browsere holder på den gamle IP, til TTL udløber. Lad derfor det gamle site køre videre et par dage – så rammer alle et fungerende site imens.
MX (mail), SPF/DKIM/DMARC (TXT) og verifikationsposter. Webtrafik er kun A/AAAA/CNAME – glemmer du mailposterne, flytter hjemmesiden fint, mens mailen dør.
