Domæneflytning uden nedetid: Sådan migrerer du DNS sikkert

En DNS-flytning der går galt, koster typisk din klient e-mail i timevis og hjemmesidenedetid der er svær at forklare bagefter. Det er sjældent teknisk komplekst - det er næsten altid forhastelse og manglende forberedelse der er årsagen. Den gode nyhed er at en DNS-migration med de rette forberedelser kan gennemføres uden et eneste sekunds mærkbar nedetid.

De to fejl der ødelægger flest DNS-flytninger

Langt de fleste problemer ved domæneflytninger stammer fra to meget konkrete fejl. Begge kan undgås med forberedelse.

MX-records der slettes eller glemmes. Når du skifter DNS-host, er det fristende at oprette de vigtigste records - typisk A-recorden til din webserver - og glemme alt det andet. MX-records er de records der fortæller verden hvilken mailserver der modtager e-mail til dit domæne. Mangler de i den nye DNS-zone, begynder afsendende mailservere at afvise eller bounce e-mails inden for minutter. Og fordi mange mailservere forsøger genforsendelse i op til 4-5 dage, opdager du måske ikke problemet med det samme - du opdager det når klienten ringer og spørger hvorfor de ikke har fået svar på deres tilbud.

TTL der er sat for højt. TTL (Time To Live) bestemmer hvor længe DNS-resolvere rundt om i verden cacher en record. Hvis din TTL er sat til 86400 sekunder - altså 24 timer - vil DNS-ændringer ikke slå igennem for alle brugere før op til et døgn efter skiftet. Det betyder at selv korrekt konfigurerede records ikke hjælper de brugere der stadig har den gamle IP-adresse cachet. Se mere om hvordan DNS cache fungerer og hvorfor det har direkte konsekvenser for din migrationsstrategi.

Forberedelse del 1: Dokumentér alle eksisterende DNS-records

Inden du rører en eneste indstilling, skal du have et komplet billede af den nuværende DNS-zone. Brug DNSinfos DNS opslag til at foretage opslag på alle relevante recordtyper for domænet - A, AAAA, MX, TXT, CNAME, NS og SRV.

Gem resultatet i et dokument. Ikke som et screenshot du ikke kan søge i - som en tabel eller tekstfil du kan sammenligne med den nye zone bagefter. Denne dokumentation tjener to formål: den er din kopi-skabelon til den nye DNS-host, og den er din fejlfindingsreference hvis noget går galt.

Vær særligt opmærksom på TXT-records. Her gemmer sig typisk:

• SPF-records - definerer hvilke mailservere der må sende på domænets vegne. En manglende SPF-record betyder at udgående mail risikerer at lande i spam. Læs mere om hvordan SPF-records fungerer og hvad konsekvenserne er hvis de er forkerte.

• DKIM-records - typisk placeret som TXT-records på subdomænet selector._domainkey. Disse er nemme at overse fordi de ikke sidder direkte på roddomænet. Artiklen om hvad DKIM er forklarer præcis hvilke records du skal lede efter.

• DMARC-records - placeret på _dmarc.domæne.dk. En manglende DMARC-record er ikke kritisk for maillevering, men den er en del af den fulde e-mailautentificeringskæde.

• Domænebekræftelser fra Google Search Console, Microsoft 365 og andre tjenester der bruger TXT-records til at verificere ejerskab.

Glem heller ikke at tjekke for eventuelle CAA-records (Certificate Authority Authorization) og SRV-records brugt af tjenester som Microsoft Teams eller VoIP-systemer.

Forberedelse del 2: Sænk TTL mindst 24-48 timer inden flytningen

Når du har dokumenteret alle records, er dit næste skridt at sænke TTL på alle records til 300 sekunder - fem minutter. Det gøres i den nuværende DNS-zone, altså hos den DNS-host du forlader.

Logikken er simpel: når TTL er 300 sekunder, vil DNS-resolvere verden over maksimalt cache de gamle records i fem minutter. Det betyder at du efter et navneserverskift kan forvente at størstedelen af verden ser de nye records inden for 5-15 minutter - frem for op til 24 timer med en standard TTL på 86400.

Du skal vente 24-48 timer efter at have sænket TTL inden du foretager selve flytningen. Årsagen er at den eksisterende cache hos resolvere skal udløbe med den gamle, høje TTL-værdi. Sænker du TTL kl. 14:00 i dag og skifter navneservere kl. 14:05, er der stadig resolvere der har cachet den gamle TTL og vil ignorere din ændring i op til 24 timer.

Kopiér alle records til den nye DNS-host INDEN navneserverskiftet

Dette er det mest kritiske trin - og det der oftest springes over. Den nye DNS-zone skal være komplet og korrekt konfigureret, inden du peger navneserverne derhen. Rækkefølgen er ikke til diskussion.

Opret alle records fra din dokumentation i den nye DNS-zone. Brug de samme værdier præcis som de fremgår af dit opslag - ingen kreative fortolkninger. Vær opmærksom på:

• Trailing dot-notation: Mange DNS-hosts kræver at hostnames i records som MX og CNAME afsluttes med et punktum (eksempelvis mail.example.com.). Andre håndterer det automatisk. Tjek din nye DNS-hosts dokumentation.

• Relative vs. absolutte værdier: Nogle DNS-hosts bruger relative navne (kun www frem for www.domæne.dk). Kopier ikke blindt uden at forstå konventionen hos den nye host.

• TTL-værdier: Sæt dem til 300 sekunder i den nye zone også - du vil have fleksibilitet de første dage efter migrationen.

Hvad du tjekker på begge sider inden du skifter

Inden du foretager navneserverskiftet, bør du validere den nye zone systematisk. Det er ikke nok at kigge i kontrolpanelet - du skal bekræfte at records faktisk er tilgængelige og syntaktisk korrekte.

Brug DNS opslag til at foretage opslag direkte mod den nye DNS-hosts navneservere inden de er autoritativt aktive. De fleste DNS-opslag-værktøjer - herunder DNSinfos - giver dig mulighed for at specificere hvilken navneserver du vil spørge, så du kan verificere den nye zone uden at vente på propagation.

Tjek som minimum disse records:

• A-record: Peger den på den korrekte IP-adresse for webserveren?

• MX-records: Er alle mailserver-entries til stede med korrekte prioritetsværdier? Brug artiklen om MX-records som reference hvis du er i tvivl om hvad der er korrekt.

• SPF-record: Er TXT-recorden til stede og korrekt formateret? Du kan validere den med SPF analyse-værktøjet.

• DKIM-records: Eksisterer selector-subdomænerne med de korrekte værdier?

• DMARC-record: Er _dmarc-recorden til stede?

Hvis du bruger Microsoft 365 til mail, kan Microsoft 365-værktøjet på DNSinfo give dig et samlet overblik over hvilke records der er nødvendige, og om de er korrekt konfigureret.

Navneserverskiftet hos registraren

Navneserverskiftet foretages hos din domæneregistrar - ikke hos din DNS-host. Det er en vigtig distinktion. Registraren er den virksomhed der administrerer selve domæneregistreringen (typisk der hvor du betaler for .dk-domænet). DNS-hosten er den der hoster selve DNS-zonen.

Når du ændrer navneservere hos registraren, fortæller du i praksis verden: "fra nu af er det disse navneservere der er autoritativt ansvarlige for DNS-zonen for dette domæne." Ændringen propagerer via TLD-navneserverne (for .dk-domæner er det Punktum dk's navneservere) ud til resolvere globalt.

Med en TTL på 300 sekunder vil de fleste resolvere begynde at bruge de nye navneservere inden for 5-30 minutter. Men "de fleste" er ikke "alle" - nogle ISP-resolvere ignorerer TTL-værdier og cacher længere. Forvent en fuldstændig propagation inden for 24-48 timer selv med lav TTL.

Du kan følge navneserverstatus og propagation med Navneserver status-værktøjet på DNSinfo, der viser om dine navneservere svarer korrekt og konsistent.

Overvågning i 24-48 timer efter skiftet

Skiftet er foretaget - men arbejdet er ikke slut. De første 24-48 timer er kritiske, og du bør aktivt overvåge at propagationen forløber som forventet.

Foretag løbende DNS-opslag på de vigtigste records - særligt A-recorden og MX-records - og bekræft at de nu peger på de korrekte værdier i den nye zone. Med DNSinfos DNS opslag kan du hurtigt se hvilke værdier der returneres, og om der er uoverensstemmelser.

Tjek specifikt:

• At hjemmesiden loader korrekt og SSL-certifikatet er gyldigt - brug SSL/TLS analyse til at bekræfte certifikatets status og at det er udstedt for det korrekte domæne.

• At du kan sende og modtage e-mail uden fejlmeddelelser.

• At SPF-validering stadig passerer - send en testmail og tjek mailheadrene for SPF-resultatet.

• At ingen tredjepartstjenester (betalingsgateway, CRM, nyhedsbrevssystem) har mistet adgang på grund af domænebekræftelsesrecords der mangler.

Hvis noget er galt, har du stadig mulighed for hurtigt at korrigere det - med en TTL på 300 sekunder vil en rettelse slå igennem inden for få minutter.

DNS Monitor som sikkerhedsnet under og efter migrationen

En migration er netop det tidspunkt hvor utilsigtede ændringer har størst konsekvens. DNS Monitor - tilgængeligt som del af DNSinfos værktøjskasse - kan opsættes til at overvåge dine kritiske DNS-records og give dig besked hvis noget ændrer sig uventet.

Under migrationen giver det dig en aktiv bekræftelse af at propagationen skrider frem som planlagt. Efter migrationen fungerer det som et løbende sikkerhedsnet - hvis en record ved en fejl overskrives eller slettes i den nye DNS-zone, opdager du det med det samme frem for at vente på at klienten klager over nedetid.

Det er særligt værdifuldt i de første uger efter en flytning, hvor risikoen for utilsigtede ændringer er størst fordi teamet stadig orienterer sig i den nye DNS-hosts interface.

Den vigtigste regel: Dokumentér alt, før du rører noget

Hele denne metode bygger på ét fundament - at du aldrig foretager en DNS-flytning uden først at have et komplet, verificeret snapshot af den eksisterende zone. En DNS-flytning der går galt, er næsten altid umulig at rekonstruere præcis fordi ingen huskede at gemme den originale konfiguration. Med fuld dokumentation i hånden, lav TTL sat i god tid og en komplet ny zone klar inden navneserverskiftet, er en migration fra en DNS-host til en anden ikke en risikofyldt operation - det er en kontrolleret overgang med et defineret tilbagefaldsscenario hele vejen igennem.