DNS verhuizen naar een andere provider is een van de weinige infrastructuurklussen waarbij één vergeten regel je mail of website platlegt, en vaak merk je dat pas als iemand klaagt. De veilige manier is met een zonebestand: de standaard export in BIND-formaat, gedefinieerd in RFC 1035, die vrijwel elke DNS-provider kan lezen en schrijven. Door een zonebestand te downloaden, de import bij de nieuwe provider eerst te bekijken en pas daarna de nameservers te wijzigen, wordt een riskante handmatige kopieerklus iets wat je kunt controleren voordat het gebeurt.
Wat staat er eigenlijk in een DNS-zonebestand?
Een zonebestand is een platte-tekstlijst van alle records in een zone (A, AAAA, CNAME, MX, TXT, SRV, CAA enzovoort), elk met een naam, TTL (time to live) en waarde. Meestal begint het met een $ORIGIN-regel (het domein waartoe de records behoren) en een standaard-$TTL, een directive die met RFC 2308 is toegevoegd voor records die geen eigen TTL opgeven. Een klein voorbeeld:
$ORIGIN example.com.
$TTL 3600
@ 3600 IN A 192.0.2.1
@ 3600 IN MX 10 mail.example.com.
www 300 IN CNAME example.com.
_dmarc 3600 IN TXT "v=DMARC1; p=quarantine"
Wat er bewust níét in staat, is net zo belangrijk. Het SOA-record (start of authority) en de NS-records op de apex horen bij de provider die de zone host. Ze worden opnieuw aangemaakt waar je het bestand ook importeert, en elke fatsoenlijke importer gaat daarvan uit. Weet je niet precies wat een recordtype doet voordat je het verhuist? Onze gids over DNS-recordtypes legt A, AAAA, CNAME, MX, TXT, NS en CAA in gewone taal uit.
Waarom DNS verhuizen naar een andere provider riskant is
Er zijn drie gangbare manieren om een zone te migreren, en twee daarvan gaan ongemerkt mis:
- Records met de hand overtikken. Prima voor vijf records, onwerkbaar voor vijftig. Je vergeet makkelijk een TXT-record voor SPF of een verificatiestring voor een domein waarvan niemand meer weet dat hij bestaat, totdat hij weg is.
- De nieuwe provider je live DNS laten scannen. Een scan vindt alleen namen die hij raadt, zoals veelgebruikte subdomeinen als
www,mailenshop. Alles met een ongebruikelijke naam mist hij, en records achter een proxy ziet hij niet. - Een zonebestand-export uploaden. Dit is de enige methode die volledig is, omdat het bestand elk record bevat dat de oude provider kent, en niet een gok op basis van veelgebruikte namen.
WarningEen DNS-scan is een redelijk alternatief als je geen exportoptie hebt, maar beschouw hem als onvolledig. Kan je oude provider überhaupt een zonebestand exporteren, gebruik dat dan.
DNS verhuizen naar een andere provider met een zonebestand
De volgorde die downtime voorkomt is altijd hetzelfde, welke tools je ook gebruikt:
- Exporteer het zonebestand bij je huidige provider. Zoek naar "Zonebestand exporteren", "BIND-bestand exporteren" of "Records downloaden".
- Maak de nieuwe zone aan bij de doelprovider, of open hem als hij al bestaat.
- Importeer het bestand en lees het voorbeeld voordat je iets bevestigt.
- Controleer de records die zijn binnengekomen, vooral MX en TXT, omdat die het vaakst ongemerkt stukgaan.
- Wijzig de nameservers bij de registrar als laatste, zodra je zeker weet dat de nieuwe zone klopt.
De nameserverwissel als laatste doen is de stap die mensen onder tijdsdruk overslaan, terwijl juist die stap je beschermt: totdat je hem uitvoert, blijft de oude provider elke query beantwoorden. Er is dus geen storing terwijl je een geweigerd record of een typfout oplost.
Wat een goed importvoorbeeld je moet laten zien
Een import van een zonebestand is maar zo veilig als het voorbeeld ervan. Voordat er iets wordt weggeschreven, moet je precies kunnen zien wat er met elke regel in het bestand gebeurt:
| Categorie | Wat het betekent |
|---|---|
| Toe te voegen | Records die de nieuwe zone nog niet heeft; deze worden geïmporteerd |
| Al aanwezig | Er bestaat al een exacte match, dus deze blijft ongemoeid |
| Niet geaccepteerd door provider | Een recordtype dat de API van je nieuwe DNS-host niet ondersteunt |
| Overgeslagen | Een regel die geen record kan worden, met de reden en het regelnummer |
Een import die alleen records toevoegt en nooit overschrijft of verwijdert, verandert niets als je hem twee keer uitvoert. Zo kun je veilig een bestand corrigeren en het opnieuw proberen, zonder je zorgen te maken over dubbele records van wat al goed was binnengekomen.
Records die nooit meegaan in een zonebestand
Sommige dingen komen niet netjes mee, hoe goed de importer ook is:
- SOA- en apex-NS-records. Deze zijn van de provider en worden bij de nieuwe host opnieuw aangemaakt, niet uit het bestand gekopieerd.
- DNSSEC-sleutels. DNSKEY- en RRSIG-records zijn gekoppeld aan de ondertekeningssleutels van de oude provider. Van provider wisselen betekent de zone opnieuw ondertekenen en het DS-record bij de registrar bijwerken. Lees onze gids over of je DNSSEC moet inschakelen voor wat daarbij komt kijken en waarom de volgorde ertoe doet.
- Eigen recordtypes van providers. Gemaksfuncties zoals ALIAS/ANAME-records, redirectregels of providerspecifieke "page rule"-items hebben meestal geen standaardequivalent, dus die komen niet over in de importer van een andere provider.
TipVerlaag je TTL's als het kan een dag of twee voor de overstap. Het protocol vereist het niet, maar met een korte TTL vertrouwen resolvers sneller niet meer op de oude antwoorden zodra je de nameservers omzet. Lees hoe DNS-propagatie echt werkt om te begrijpen waarom oude records kunnen blijven hangen.
Hoe InfraNest dit aanpakt
Met InfraNest download je elke zone die het beheert als standaard zonebestand, en importeer je er een terug in een bestaande of gloednieuwe zone. Het importvoorbeeld werkt precies zoals hierboven beschreven: het toont wat wordt toegevoegd, wat al bestaat, wat de API van je provider niet accepteert en elke overgeslagen regel met de reden, voordat er iets wordt weggeschreven. Het voegt alleen records toe, dus niets wat je al hebt wordt overschreven, en hetzelfde bestand twee keer importeren heeft geen effect.
Een nieuwe zone opzetten bij een nieuwe provider gaat op dezelfde manier: kies in de wizard voor het toevoegen van een zone voor het uploaden van een zonebestand, en de records komen mee terwijl de zone wordt aangemaakt, naast de optie om live DNS te scannen of records uit een bestaande zone te kopiëren. Zodra de nameservers zijn ingesteld, blijft InfraNest de zone vergelijken met wat het openbare internet daadwerkelijk antwoordt, zodat een record dat buiten de tool is gewijzigd wordt gesignaleerd in plaats van later ontdekt. Controleer eerst je huidige records met de gratis DNS lookup-tool en verhuis de zone daarna met vertrouwen via DNS-beheer.
Veelgestelde vragen
#Wat is het verschil tussen een zonebestand importeren en een DNS-scan?
Een scan vraagt openbare resolvers naar veelgebruikte subdomeinnamen en vindt alleen wat hij goed raadt, terwijl een zonebestand elk record bevat dat de oude provider kende, ook ongebruikelijke of onraadbare namen.
#Overschrijft een import van een zonebestand mijn bestaande DNS-records?
Een goed gebouwde importer voegt alleen records toe die nog niet bestaan en overschrijft of verwijdert nooit iets, dus als je hetzelfde bestand twee keer importeert, blijft de zone ongewijzigd.
#Verhuist een zonebestand ook mijn nameservers?
Nee. Een zonebestand bevat alleen recordgegevens; de nameserverdelegatie stel je apart in bij de registrar van je domein, en dat moet altijd de laatste stap van een migratie zijn.
#Kan ik een met DNSSEC ondertekende zone verhuizen met een zonebestand?
Niet direct. DNSKEY- en RRSIG-records zijn gekoppeld aan de ondertekeningssleutels van de oude provider, dus de nieuwe provider moet eigen sleutels genereren en jij werkt het DS-record bij de registrar daarop bij.
Probeer het met een gratis tool
Was dit artikel nuttig?
