Sådan flytter du et .dk-domæne til en ny udbyder

.dk-domæner er organiseret anderledes end de fleste generiske topdomæner. DK Hostmaster fungerer som den centrale registry og kundevendte myndighed, mens de hosting- og domæneudbydere du møder på markedet blot er forhandlere, der videresender ordrer og betalinger.

Hvem gør hvad?

Hvad betyder “at flytte et .dk-domæne”?

Når man taler om at flytte et .dk-domæne, drejer det sig næsten altid om et forhandler-skift. DNS-servere, webhotel og e-mail kan flyttes samtidig, men det er ikke en forudsætning. Selve domænet bliver hele tiden liggende hos DK Hostmaster; du flytter blot den partner, der håndterer din betaling og evt. tekniske ydelser.

Godkendelse uden epp- eller auth-kode

I modsætning til .com, .net og mange andre TLD’er benytter .dk-domæner ikke en EPP/Auth-kode. I stedet:

1. Den nye udbyder indsender en forhandler­anmodning til DK Hostmaster.
2. DK Hostmaster sender straks en e-mail til registrantens kontakt­adresse.
3. Registranten logger ind på selvbetjeningen (typisk med MitID/MitID Erhverv) og godkender med få klik.

Godkendelsen bliver i praksis gennemført på få minutter, hvorefter WHOIS opdateres med den nye forhandlerkode. Hele processen er automatiseret, og der er ingen “låste” perioder som ved andre TLD’er.

Tidslinje - Fra bestilling til færdigt skift

• Tidspunkt 0: Du bestiller flytning hos ny udbyder.
• + 2-5 min: E-mail fra DK Hostmaster lander i indbakken.
• + 5-15 min: Du logger ind og godkender.
• + 0-5 min: Forhandler­skiftet er registreret, og fakturering overgår til ny udbyder.

Med andre ord: flytningen er typisk overstået samme dag, forudsat at kontakt-e-mailen er korrekt, og at du har MitID klar. Eventuelle ændringer af navneservere eller hosting foregår som separate handlinger før eller efter selve forhandlerskiftet.

En vellykket domæneflytning starter længe før du klikker på ”Godkend” hos DK Hostmaster. Følg nedenstående tjekliste, så minimerer du risikoen for uventede stop i både webtrafik og mail.

1. Kontrollér registrant- og kontaktoplysninger
   Log ind på DK Hostmasters selvbetjening (MitID / MitID Erhverv) og bekræft, at:
   • Navn, adresse og CVR/CPR-nr. er korrekte.
   • Kontakt-e-mailen er en aktiv mailbox, du har adgang til (den modtager selve godkendelseslinket).
   • Evt. tech- eller billing-kontakter er opdaterede, hvis andre skal modtage driftsmails eller fakturaer.
2. Tjek domænets status
   
   • Udløbsdato: Flyt ikke få dage før domænet skal fornyes - betal evt. først.
   • Ubetalte fakturaer hos DK Hostmaster spærrer for flytning; betal eller afklar med supporten.
   • Spærringer: ”Registrar-lock” eller igangværende tvister (DIFO, Retten) skal ophæves før skift.
3. Planlæg timing
   Vælg et tidspunkt med lav trafik - typisk uden for almindelig åbningstid. Husk at godkendelseslinket udløber efter 4 døgn; simpel plan:
   • Dag -2 til -1: Klargør DNS-backup & sænk TTL.
   • Dag 0: Initier flytning, godkend i selvbetjening samme dag.
   • Dag +1: Verificér at alt svarer korrekt, hæv TTL igen.
4. Tag fuld backup af DNS-zonen
   

   Eksportér alle poster fra nuværende navneserver - mange kontrolpaneler har en “zone export”-funktion, ellers brug dig axfr, drill eller et API.

   Posttype	Eksempler du bør gemme
   A / AAAA	Webserverens IPv4 og IPv6
   MX	Mailserver(e) + prioritet
   CNAME	www, autodiscover, ftp, etc.
   TXT	SPF, Google-site-verification m.fl.
   SPF	v=spf1 include:… ~all
   DKIM	selector._domainkey TXT-poster
   DMARC	_dmarc TXT-record

5. Sænk TTL 24-48 timer før
   

   Reducer “Time To Live” til f.eks. 300-600 sekunder. Dermed kan du hurtigt dirigere trafikken til den nye navneserver uden lang overgangsperiode. Husk at hæve TTL igen, når alt fungerer.

6. Sørg for adgang til selvbetjeningen
   Tjek i god tid, at dit MitID virker, og at du kender brugernavn/password til DK Hostmaster, hvis totrins-login skulle drille.

Når ovenstående punkter er fluebenet, er du klar til at vælge ny udbyder og starte selve flytteprocessen.

Inden du trykker “Bestil” hos den første og bedste forhandler, kan det betale sig at lave et systematisk service-eftersyn. En .dk-flytning er som regel overstået på få minutter, men vælger du den forkerte partner, kan konsekvenserne mærkes i årevis.

1. Sammenlign kerneydelser og prisstruktur

*WHOIS-privacy er irrelevant for .dk, da personhenførbare data alligevel skjules for privatpersoner.

2. Tjek dns-motoren - Den er hjertet i driften

• Anycast-netværk: Giver kortere svartider globalt og øger robusthed mod DDoS.
• DNSSEC-understøttelse: Spørg, om nøgler kan flyttes automatisk, og om udbyderen signer hele zonen.
• Avancerede record-typer: CAA, SRV, SSHFP, NAPTR m.fl. - nødvendige til moderne services og certificates.
• API & automatisering: REST eller AXFR/IXFR? Er der Terraform- eller Ansible-moduler, så DevOps-teamet kan holde alt i kode?
• 24/7 overvågning & SLA: Få svarsorter og kompensation beskrevet på skrift, fx “99,99 % oppetid på DNS-responser”.

3. Aftal rollefordelingen tydeligt

1. Før flytningen
   • Hvem lægger den midlertidige spejlzone på de nye navneservere?
   • Skal du eller udbyderen sænke TTL og foretage tests?
2. Under cut-over
   • Hvem overvåger propagation og står klar, hvis noget går galt?
   • Hvor hurtigt kan den gamle udbyder genetablere DNS, hvis zonechecken fejler?
3. Efter flytningen
   • Er det kundens ansvar at holde DNS-poster opdateret, eller tilbyder udbyderen managed DNS?
   • Sørg for adgang til kontrolpanel/API med det samme - ikke først når regningen er betalt.

4. Få klarhed over web- og mail-migrering

Selve domænet flytter kun navneserverpegeren. Hvis du også skal have:

• Webhotel: Får du kopieret filer, databaser og eventuelle cron-jobs, eller skal du selv bruge FTP/SSH?
• E-mail: Tilbyder udbyderen IMAP-synk eller Mail Transfer Service, så gamle mails ikke går tabt?
• SSL/TLS-certifikater: Kan de automatisk genudstedes via Let’s Encrypt, eller skal de uploades manuelt?

Indgå skriftlig aftale om tidsplan, ansvarspunkter og rollback-strategi.

5. Lav et simpelt beslutningsskema

Når du har alle data, kan et pointsystem hjælpe:

• Pris (0-10)
• Support & SLA (0-10)
• DNS-features (0-10)
• Migreringshjælp (0-5)
• Bindingsfrihed (0-5)

Udbyderen med højeste score er sjældent den billigste, men typisk den, der giver færrest hovedpiner på lang sigt.

Tip: Keep it simple. Kan du ikke forklare din nye driftmodel på én slide, er løsningen sandsynligvis for kompleks.

Selve flytningen af et .dk-domæne foregår i et samarbejde mellem tre parter: dig som registrant, din nye udbyder og DK Hostmaster. I praksis er det en enkel proces, så længe dine kontaktoplysninger er i orden.

1. Bestil flytningen hos den nye udbyder
   Læg domænet i kurven som “Flyt” eller “Transfer”, og gennemfør bestillingen. Udbyderen sender herefter en digital anmodning til DK Hostmaster om at blive ny forhandler.
2. Hold øje med godkendelses-mailen fra DK Hostmaster
   Når anmodningen er registreret, udsender DK Hostmaster en e-mail til den kontakt-e-mail, der er angivet på domænet. Mailen indeholder et link til selvbetjeningen, hvor du logger ind med MitID / MitID Erhverv.
   (Bemærk: Der bruges ikke EPP/Auth-kode til .dk-domæner.)
3. Log ind og godkend skiftet
   Når du er logget ind, bliver du præsenteret for anmodningen. Bekræft, at det er den korrekte udbyder, og tryk “Godkend”. Godkendelsen slår igennem på få minutter; i travle perioder kan det tage op til en time.
4. Bekræft hos den nye udbyder
   De fleste udbydere sender en velkomstmail, når DK Hostmaster melder skiftet gennemført. Log ind i udbyderens kontrolpanel og kontroller, at domænet står som “Aktiv” eller “Overført”.

Hvis godkendelsesmailen udebliver

• Se efter i spam-/uønsket post.
• Log ind på DK Hostmasters selvbetjening og tjek, om kontakt-e-mailen er korrekt. Ret den om nødvendigt og bed udbyderen gensende anmodningen.
• Kontroller også, at domænet ikke er spærret pga. ubetalte fakturaer eller en aktiv “Registrar-lock”.

Fortrydelse eller ny tidsplan

Når du ser domænet listet med den nye forhandler i whois eller hos DK Hostmaster, er flytningen formelt afsluttet - så kan du trygt gå videre til næste skridt: DNS-skiftet og selve migreringen af web eller mail.

Det er DNS-opsætningen, ikke selve domæneejerskabet, der afgør om dine besøgende ender det rigtige sted. Følger du nedenstående fremgangsmåde, minimerer du risikoen for sort skærm og fejl-bounce på mail.

1. Lav en 1-til-1-kopi af zonen hos den nye udbyder

• Eksportér den nuværende zonefil (de fleste kontrolpaneler har en Export Zone-funktion eller tillader AXFR).
• Importer filen hos den nye udbyder og verificér, at alle poster er med: A/AAAA, MX, CNAME, TXT (SPF, DKIM, DMARC), SRV, CAA m.fl.
• Kontroller automatisk tilføjede standard-poster. Mange udbydere lægger egne mail- eller ftp-A-records ind, som kan kollidere med din opsætning.

2. Kend dk hostmasters zonecheck - Ellers bliver domænet “ikke-delegeret”

Når du beder din nye forhandler om at registrere navneserverne, kører DK Hostmaster automatisk ovenstående test. En fejl betyder, at domænet sættes i “ikke-delegeret”, dvs. ingen svar i .dk-zonen før problemet er løst.

3. Sænk ttl - Og gør det i god tid

1. T-48 timer: Sæt TTL på zone- og kritiske records (A/AAAA, MX, CNAME) ned til fx 300 sek.
2. T-24 timer: Bekræft via dig +trace at de nye lave TTL’er er publiceret.
3. T-0: Skift navneservere hos den nye udbyder / DK Hostmaster.
4. T+4 timer: Når trafikken er stabilt på de nye noder, hæv TTL igen (3.600-86.400 sek.) for mindre cache-load.

4. Test før du skifter

• Kør dig @ny.ns1.dk itforum.dk any og sikre identisk output.
• Brug hosts-fil-trick til at tvinge din browser over på ny IP uden at røre offentlig DNS.
• Foretag drill -D eller zonemaster.net-test for at fange skjulte delegation-fejl.

5. Dnssec - Husk nøglerne!

Signerede .dk-domæner kræver lidt ekstra omtanke:

1. Opsæt DNSSEC hos den nye udbyder og generér nye KSK/ZSK (eller flyt de gamle nøgler).
2. Indsend de nye DS-records via selvbetjeningen før navneserver-skift, så DS peger på de fremtidige nøgler.
3. Overvåg med dnsviz.net for at sikre ubrudt kæde fra root → .dk → dit domæne.

6. Klarmeld og overvåg

Efter delegation:

• Tjek WHOIS - nye navneservere skal fremgå med korrekt redelegerings-tid.
• Overvåg ping/tcp-latency til web-IP’er og kør smtp-test på MX.
• Hold øje med mail-log for SPF permerror eller DKIM-fails (skyldes ofte glemte TXT-records).

Følger du ovenstående, kan du skifte navneservere for et travlt .dk-domæne uden at nogen opdager det - bortset fra dig og din logfil.

Selvom forhandler-skiftet er gennemført hos DK Hostmaster, ligger dine webfiler, databaser og mailbokse stadig fysisk dér, hvor de altid har ligget. Skal du også skifte webhotel eller mailserver, bør du derfor gennemføre en separat migrering - helst uden at brugerne bemærker noget.

1. Overblik: Hvad skal flyttes?

2. Paralleldrift: Undgå nedetid

1. Kopiér alt indhold til det nye miljø, men behold også det gamle aktivt.
2. Sænk TTL på A/AAAA- og MX-records til fx 300 sek. mindst et døgn før cutover - så kan du rulle tilbage hurtigt.
3. Test “skjult” ved at pege hosts-filen på den nye server eller bruge en midlertidig URL/IP og gennemgå funktionalitet, performance og certifikat.
4. Når alt er klar, skift DNS til den nye IP / det nye MX-sæt. Hold øje med logs, load og fejlrater.
5. Lad det gamle miljø køre mindst 48 timer efter skift for at fange sene DNS-cache-hits.

3. Opdater kritiske dns-poster

• MX: peger på ny mailserver. Tjek at den accepterer domænet som local recipient.
• SPF: tilføj/udskift “include:” eller IP-ranges for ny sender.
• DKIM: generér nøgle på ny platform og publicér som TXT-record (selector._domainkey).
• DMARC: tilpas rapport-destinationer og politik (p=none/quarantine/reject), hvis afsendende infrastruktur ændrer sig.
• CAA: giver kun udvalgte CA’er lov til at udstede certifikater; tilføj ny CA hvis nødvendigt.

4. Ssl/tls-certifikater

Da certifikater er bundet til server og privat nøgle, skal de enten genudstedes eller kopieres til den nye platform. Brug helst en automatisk ACME-løsning (Let’s Encrypt eller ZeroSSL) - så fornyes certifikatet automatisk fremover.

5. Tjekliste efter cutover

1. HTTP 301-redirects: Hvis URL-strukturer eller subdomæner ændres, opsæt permanente redirects på .htaccess, Nginx rewrite eller via CMS.
2. Mailflow: Send og modtag testmails fra eksterne tjenester (Gmail, Outlook, Proton). Se efter SPF/DKIM/DMARC-pass i mail-headers (Authentication-Results).
3. Login og API-kald: Verificér CMS-backend, SSH, SFTP, cronjobs og eventuelle webhooks.
4. Performance: Overvåg responstid, database-load og fejl 5xx. Brug f.eks. UptimeRobot eller Pingdom.
5. Slet gammelt miljø først, når du er helt sikker på, at ingen bruger det længere - og husk at tage en sidste sikkerhedskopi.

Når alle tjekpunkter grønner, kan du betragte migreringen som fuldført. Hav dog stadig et recovery-setup klar (backup + rollback-plan), så du hurtigt kan agere, hvis der opstår uforudsete problemer i dagene efter.

Når DK Hostmaster har bekræftet forhandlerskiftet, er arbejdet ikke helt slut. En hurtig checkliste og et par dages overvågning kan spare dig for ubehagelige overraskelser.

1. Bekræft whois-data og forhandler

• Slå domænet op på whois.dk-hostmaster.dk og kontrollér, at:
  1. Forhandler (registrar) nu er den nye udbyder.
  2. Registrant- og kontaktoplysninger (navn, adresse, e-mail, telefon) er korrekte.
  3. Navneservere peger på de planlagte servere - inkl. DNSSEC DS-records, hvis du bruger DNSSEC.

2. Få styr på fornyelse og fakturering

Log ind på selvbetjeningen hos både DK Hostmaster og den nye udbyder, og tilknyt gyldigt betalingskort eller EAN-nummer, så fornyelser sker automatisk.

3. Overvåg dns og e-mail de første 48-72 timer

1. A / AAAA: Indlæs siden via både IPv4 og IPv6 og tjek curl -I https://ditdomæne.dk for 200-svarkode.
2. MX: Brug dig MX ditdomæne.dk +short og send en testmail fra en ekstern konto.
3. SPF, DKIM & DMARC: Valider med MXToolbox eller dig TXT og aflæs DMARC-rapporter.
4. CNAME / CAA / TXT: Verificér evt. 3.-parts-services (Office 365, Google Workspace, Let’s Encrypt m.fl.).

Sæt evt. overvågning op i UptimeRobot eller StatusCake, så du får alarm, hvis DNS eller HTTP/SMTP fejler.

4. Typiske problemer og hurtige løsninger

• Manglende godkendelse
  Domænet stod fortsat hos gammel forhandler, fordi registranten ikke godkendte i tide.
  → Bed den nye udbyder genstarte flytningen og godkend straks via MitID.
• Udløbet domæne
  Flytningen blev initieret tæt på udløbsdatoen, og DK Hostmaster satte domænet i “Deaktiv” status.
  → Betal udestående afgift; flytningen kan derefter fortsætte.
• Fejl i navneservernes zonecheck
  DK Hostmaster melder “ikke-delegeret” pga. manglende SOA eller timeout.
  → Ret zonefilen hos ny udbyder og gentag zonecheck; kontakt udbyderen, hvis du ikke har adgang.
• Ufuldstændig DNS-kopi
  Nogle records blev glemt (f.eks. DKIM eller sub-CNAMEs).
  → Sammenlign den gamle og nye zone (dig/drill) og genskab manglende poster.

5. Hvornår skal du kontakte support?

Når du har udelukket lokale fejl, og enten

• DK Hostmaster WHOIS viser forhandleren korrekt, men domænet er fortsat “ikke-delegeret”.
• E-mail leveres stadig ikke efter 24 timer, og dig MX viser de korrekte poster.
• DNSSEC viser bogus status i DNSSEC-Debugger.

I så fald bør du åbne en ticket hos din nye udbyder med detaljer (tidspunkter, fejllogs). Ved vedvarende tekniske fejl, som udbyderen ikke kan løse, kan du kontakte DK Hostmaster Support på [email protected] eller tlf. 33 64 60 60.

Når ovenstående tjekpunkter er grønne, kan du roligt læne dig tilbage - dit .dk-domæne er nu sikkert forankret hos den nye udbyder og klar til fremtidig drift.