De nieuwe website is opgeleverd, de hosting is omgezet en de bouwer heeft “de dns aangepast”. U tikt uw domein in en krijgt gewoon de oude site te zien. Dat een dns wijziging lang duurt hoort u dan als geruststelling, maar niemand legt uit waarom, en na een halve dag begint u zich af te vragen of er iets fout is gegaan.

Meestal is er niets fout gegaan. Wat u ziet is het gevolg van een geheugen dat op tientallen plaatsen tegelijk staat en niet allemaal op hetzelfde moment wordt ververst. Hieronder leest u wat er precies gebeurt, hoe u kunt zien waar úw computer terechtkomt en op welk moment u wél aan de bel moet trekken.

Wat er gebeurt als u een domein intikt

Uw domeinnaam is niet meer dan een label. Er hoort een ip-adres bij, en dat adres wordt opgezocht in het domeinnaamsysteem. Die opzoeking gaat langs een reeks tussenstations, en elk station onthoudt het antwoord een tijdje om niet steeds opnieuw te hoeven vragen.

  • Uw browser houdt een eigen kleine lijst bij, vaak maar voor een minuut of wat.
  • Uw besturingssysteem bewaart het antwoord ook, soms uren.
  • Uw router doet hetzelfde voor het hele netwerk in het pand.
  • De dns-server van uw internetprovider bewaart het voor al zijn klanten in de regio.
  • De nameservers van het domein zelf geven aan hoelang iedereen het antwoord mag onthouden.

Die laatste waarde heet de ttl, de tijd dat een antwoord geldig blijft. Staat die op 3600, dan mag elke tussenstop het oude adres nog een uur blijven uitdelen, ook nadat u het record allang heeft veranderd. Staat hij op 86400, dan is dat een etmaal.

Waarom een dns wijziging lang duurt bij de een en niet bij de ander

Er is geen centrale schakelaar. Elke tussenstop telt zijn eigen klok af, en die klokken zijn niet gelijkgezet. Uw buurman zit bij een andere provider en ziet de nieuwe site daarom eerder of later dan u. Uw telefoon op het mobiele netwerk gebruikt weer een andere dns-server en loopt vaak vooruit op uw laptop op kantoor.

In de praktijk zien we dit ritme:

  1. Binnen 5 tot 30 minuten is het nieuwe adres bekend bij de grote publieke dns-diensten.
  2. Binnen 1 tot 4 uur volgt het gros van de Nederlandse providers.
  3. Binnen 24 uur is vrijwel iedereen om.
  4. Tot 48 uur houden we aan als uiterste, vooral als de oorspronkelijke ttl hoog stond of als er ook nameservers zijn gewijzigd in plaats van alleen een A-record.

Het klassieke advies “reken op 48 uur” is dus geen slap aftreksel, maar een bovengrens. Wie de wijziging goed voorbereidt, haalt die tijd flink omlaag: zet de ttl een dag van tevoren op 300 seconden, voer daarna pas de wijziging door, en zet hem er een dag later weer op terug.

Controleren waar u zelf uitkomt

Gissen is zonde, want u kunt het gewoon opzoeken. Open een opdrachtvenster en typ nslookup uwdomein.nl. U krijgt het ip-adres dat úw computer op dit moment gebruikt. Vergelijk dat met het adres dat uw hoster van de nieuwe omgeving heeft doorgegeven.

Wilt u weten wat de rest van de wereld ziet, gebruik dan een online propagatiecontrole. Die vraagt het bij tientallen dns-servers wereldwijd op en laat in een oogopslag zien welk deel al is omgezet. Staat daar overal het nieuwe adres en ziet alleen u nog de oude site, dan zit het probleem lokaal.

Lokaal opruimen kan trouwens vrij simpel: sluit uw browser volledig af, leeg de dns-cache van uw besturingssysteem, en herstart eventueel de router. Werkt dat niet, zet dan tijdelijk een publieke dns-server in uw netwerkinstellingen. Verwar dit niet met een pagina die uit de cache van de site zelf komt; dat is een ander mechanisme met een andere oplossing.

Wanneer het géén propagatie meer is

Op een gegeven moment houdt geduld op een verklaring te zijn. Deze signalen wijzen op een echte fout:

  • Na 48 uur ziet nog steeds niemand de nieuwe site. Dan is het record waarschijnlijk niet gewijzigd, of gewijzigd bij de verkeerde partij. Dit gebeurt vaak als de nameservers bij een andere leverancier staan dan waar iemand zat te klikken.
  • De site laadt, maar het slotje is weg of geeft een waarschuwing. Dan is het certificaat op de nieuwe server nog niet aangevraagd of nog niet gekoppeld.
  • De site laadt half: tekst wel, afbeeldingen niet. Meestal staan er nog verwijzingen naar het oude adres in de database.
  • U komt op een pagina van uw hoster in plaats van op de site. Het domein wijst dan naar een lege parkeerplek.
  • De e-mail is stil. Dat is geen kwestie van wachten. Bij een verhuizing worden de MX-records nogal eens meegenomen naar de nieuwe hosting terwijl de mailbox ergens anders staat.

Dat laatste punt verdient extra aandacht, want het is stille schade: mail die geweigerd wordt komt later niet alsnog binnen. Controleer de MX-records direct na de omzetting en stuur uzelf een testbericht vanaf een adres buiten uw eigen domein.

De verhuizing zelf slimmer inrichten

Een paar afspraken maken het verschil tussen een rustige avond en een dag paniek. Verlaag de ttl vooraf. Plan de omzetting op een moment met weinig verkeer, niet op vrijdagmiddag. Laat de oude omgeving nog minstens een week draaien, zodat bezoekers die nog naar het oude adres worden gestuurd een werkende site zien in plaats van een foutmelding. En leg vooraf vast wie welke records beheert.

Blijft de site ook na de propagatie stroef of half werken, dan is het geen dns-vraagstuk meer maar een storing die uitgezocht moet worden.

In de controlelijst voor een site die na een verhuizing hapert staat wat er dan als eerste wordt nagelopen: verwijzingen in de database, het certificaat, de omleidingen en de rechten op de mappen.

Concrete volgende stap: draai nu nslookup op uw eigen domein en vergelijk de uitkomst met het ip-adres dat uw hoster heeft opgegeven. Binnen een minuut weet u of u moet wachten of moet bellen.