DNS wijzigen zonder uitval: veilige volgorde voor je website (2026)

DNS wijzigen zonder uitval begint met weten welke records er nu zijn en welke diensten ze raken. Behandel een wijziging voor web, e-mail en certificaatcontrole als afzonderlijke controles, ook wanneer je die op één dag uitvoert.

Stappenplan

1. Leg de huidige records en eigenaar vast

Noteer recordtype, naam, waarde en beheerder in je eigen veilige beheeromgeving. ICANN beschrijft in zijn actuele DNS-overzicht de rol van het domeinnaamsysteem; dat overzicht vervangt geen controle van jouw registrar of host.

Maak een inventaris uit de beheeromgeving, niet uit losse herinneringen. Zet per record erbij waarvoor je denkt dat het dient en wie kan bevestigen of dat klopt. Denk aan het hoofddomein, www, subdomeinen, mailrecords en records die een externe dienst of certificaatverificatie gebruikt. Kopieer gevoelige waarden niet naar chat of openbaar ticket; werk in een afgesproken, afgeschermde wijzigingsdocumentatie.

2. Bepaal welke diensten je raakt

Scheid website, mail, subdomeinen en verificatierecords. Plan een website-migratie niet alleen vanuit de homepage.

Stel vóór de wijziging de praktische vraag: wat mag absoluut niet stoppen? Een website, mailbezorging en een subdomein voor een portal kunnen onder dezelfde domeinnaam vallen maar technisch anders zijn ingericht. Maak een lijst met ten minste één controle per afhankelijkheid. Weet je niet wie een record gebruikt, verwijder het dan niet om op te ruimen; markeer het als onbekend en zoek eerst de eigenaar.

3. Wijzig één afgebakend onderdeel

Voer alleen de afgesproken recordwijziging uit. Houd oude waarden bij voor herstel, maar deel ze niet in openbare tickets of screenshots. MDN legt uit waarom DNS een laag is tussen de naam en technische bestemming.

Beperk de wijzigingsset tot wat nodig is. Controleer vlak ervoor dat je in het juiste domein en de juiste zone werkt; gelijknamige test- en productiedomeinen zijn een bekende bron van fouten. Leg de oude waarde, nieuwe waarde, tijd en uitvoerder vast in je eigen proces. Een TTL beïnvloedt caching, maar geeft je geen exact tijdstip waarop elke bezoeker hetzelfde antwoord krijgt. Plan daarom een controlevenster in plaats van een minutengarantie.

4. Controleer na de wijziging

Open het bedoelde domein via HTTPS, test kernpaden en controleer de contactroute via de livegangchecklist. Krijg je een browserwaarschuwing, gebruik dan de SSL-foutroute.

Test niet alleen de homepage. Open ook de www-variant als die bestaat, een belangrijke landingspagina, een formulier en een relevante subdomeinroute. Controleer welke bestemming je browser werkelijk opent en of de HTTPS-waarschuwing wegblijft. Voor mail of andere diensten geldt een eigen veilige controle met de verantwoordelijke eigenaar; een werkende website bewijst niet dat die diensten onaangetast zijn.

5. Stop bij onverwachte afhankelijkheden

Raakt de wijziging mail, betalingen of onbekende subdomeinen, stop en laat de eigenaar beoordelen voordat je meer records aanpast.

Dat stopmoment is een kwaliteitsmaatregel, geen mislukking. Een betaling, mailbox of externe verificatie kan gevolgen hebben die je niet met een browsertest ziet. Leg de onverwachte uitkomst vast, zet geen tweede gissing eroverheen en kies daarna tussen herstel van de vorige waarde, aanvullend onderzoek of een nieuw afgebakend wijzigingsvenster.

Besliskader: wijzigen, wachten of herstellen

Wijzig alleen wanneer je vier dingen weet: welk record je aanpast, welke dienst je verwacht te raken, wie de uitkomst beoordeelt en welke vorige waarde je veilig kunt herstellen. Als één onderdeel onbekend is, is wachten meestal beter dan combineren met extra wijzigingen. Kies een venster waarin de eigenaar bereikbaar is en waarin je de belangrijkste route kunt testen. Bij een kleine, geïsoleerde wijziging kan dat kort zijn; bij een domeinverhuizing of mailafhankelijkheid hoort een bredere voorbereiding.

Herstel wanneer de afgesproken kernroute na het redelijke controlevenster onverklaarbaar afwijkt, wanneer een certificaat een andere host toont of wanneer een onbekende dienst geraakt blijkt. Zet de gedocumenteerde vorige waarde terug, noteer het tijdstip en test daarna opnieuw. Ga niet meteen meerdere varianten proberen. Die volgorde houdt het verschil zichtbaar tussen een DNS-probleem, een serverconfiguratie en een fout in de controle zelf.

Controlelijst en overdracht

Eindig met een korte overdracht: welk record is gewijzigd, welke controles zijn uitgevoerd, wat was de uitkomst en welke resterende observatieperiode geldt. Koppel de wijziging aan de migratiehandleiding wanneer hosting of URL's tegelijk veranderen. Na een stabiele uitkomst bewaar je de inventaris op een plek waar de eigenaar hem terugvindt. Zo is een volgende wijziging geen speurtocht naar oude screenshots.

Praktijkcheck voor de omschakeling

Vlak voor de wijziging lees je de inventaris nog eenmaal naast de beheeromgeving. Bevestig domein, recordnaam, recordtype, huidige waarde, nieuwe waarde en uitvoerder. Na de wijziging controleer je de afgesproken website-URL's en laat je de eigenaar van een andere kritieke dienst de eigen controle uitvoeren. Schrijf precies op wat je ziet, ook wanneer het nog niet verandert. Dat laatste is belangrijk: een eerder of later antwoord kan met caching samenhangen en is geen uitnodiging om nieuwe waarden te gaan gokken.

Blijf binnen de gekozen scope. Een schijnbaar ongerelateerd record verwijderen omdat het “oud” lijkt, is geen onderdeel van een veilige omschakeling. Zet zulke observaties op een aparte lijst met eigenaar en doel. Daarmee houd je de live wijziging klein en het vervolgonderzoek controleerbaar.

Vergelijk na afloop ook je documentatie met de werkelijke wijziging. Staat er een andere waarde, naam of uitvoerder dan verwacht, markeer dat als afwijking en laat de eigenaar beslissen over de volgende stap. Deze extra controle kost weinig tijd, maar voorkomt dat een later herstel op een verouderde of onvolledige inventaris leunt.

Veelgemaakte fouten

• Alle records als webrecords zien. E-mail en verificatie gebruiken vaak andere records.
• Geen huidige waarden vastleggen. Dan ontbreekt een snelle vergelijking of herstelroute.
• Meerdere wijzigingen tegelijk doen. Dat maakt oorzaak en effect onduidelijk.
• TTL als garantie lezen. Caches en afhankelijkheden kunnen anders reageren.
• Een certificaatprobleem wegzetten als alleen DNS. Controleer de volledige HTTPS-route.

Officiële bronnen

ICANN over DNS · MDN over DNS

Wil je een DNS-wijziging met een duidelijke terugvalroute laten voorbereiden, stel je vraag via WhatsApp.