DNS-propagatievertraging is de tijd die verstrijkt tussen het wijzigen van een record en het moment waarop elke bezoeker daadwerkelijk de nieuwe waarde ziet; die periode kan variëren van vijf minuten tot twee volle dagen. Als je net bent verhuisd naar een andere host, van e-mailprovider bent gewisseld of je domein naar nieuwe nameservers hebt laten wijzen, wil je een eerlijk antwoord over wat dit versnelt en wat je simpelweg niet kunt beïnvloeden. Eén instelling bepaalt het grootste deel van de wachttijd: TTL. Alles daarna, zoals resolvergedrag, ISP-caching en registry-timing, valt buiten je controle, hoe vaak je de pagina ook ververst.
Wat veroorzaakt DNS-propagatievertraging
DNS-propagatie is niet één gebeurtenis die overal tegelijk plaatsvindt. Omdat DNS-gegevens voor de snelheid op meerdere lagen worden gecached, moet elke wijziging zich een weg banen door duizenden recursieve resolvers, ISP-servers en eindapparaten voordat deze iedereen bereikt. Elke resolver, van je router thuis tot je ISP, slaat een DNS-antwoord voor een bepaalde periode op en blijft dat opgeslagen antwoord serveren in plaats van de authoritatieve server opnieuw te raadplegen. Die opslagperiode heeft een naam.
TTL, time to live, is een getal in seconden dat aan elk DNS-record is gekoppeld en dat recursieve resolvers vertelt hoe lang ze het gecachete antwoord mogen hergebruiken voordat ze opnieuw bij de authoritatieve nameserver moeten controleren. Een record met een TTL van 3600 kan door een resolver een uur lang worden vastgehouden; eentje met 86400 kan een volle dag worden bewaard. Dat ene getal is de reden waarom dezelfde wijziging voor de ene bezoeker direct zichtbaar kan zijn en voor een ander urenlang onzichtbaar blijft.
Er is hier nog een addertje onder het gras. Sommige resolvers negeren simpelweg een lage TTL, en bepaalde ISP-resolvers hanteren hun eigen minimale cache-ondergrens, meestal 300 seconden, ongeacht wat jij publiceert. Wanneer een apparaat je domein opvraagt, vraagt het een caching DNS-server om het antwoord; die server slaat de reactie op voor de duur van de TTL en zal gedurende die periode niet teruggaan om op updates te controleren. Je kunt die server niet dwingen om eerder te controleren.
TTL verlagen vóór een migratie: de enige knop waar je controle over hebt
TTL wordt vooraf ingesteld, wat betekent dat dit het enige onderdeel van dit proces is dat je daadwerkelijk kunt plannen. Een stapsgewijze verlaging werkt beter dan een plotselinge daling op de dag van de migratie. Een veelgebruikt schema ziet er zo uit:
Zeven dagen vóór de verhuizing controleer je de TTL op elk kritiek record (A, MX, CNAME en dergelijke) en kap je alles wat hoger is af op 24 uur. Drie dagen van tevoren breng je dat getal terug naar 3600 seconden, oftewel één uur. Tussen 24 en 48 uur vóór de overstap verlaag je het nogmaals naar 300 seconden, oftewel vijf minuten, wat zorgt voor de snelst haalbare propagatie tijdens de daadwerkelijke omschakeling.
Het wachten is net zo belangrijk als het getal. De oude, langere TTL moet eerst uit de caches verlopen voordat de nieuwe, kortere overal effect sorteert, dus de vooraankondiging is niet optioneel. De TTL een uur voor de overstap verlagen is te laat om nog te helpen. Voer de daadwerkelijke wijziging pas door zodra die lage TTL de tijd heeft gehad om zich te verspreiden.
E-mail verdient een eigen vermelding, aangezien een kapot MX-record betekent dat berichten worden teruggestuurd in plaats van een langzame paginalading. Verlaag de TTL op MX-records 48 uur vóór de migratie om propagatie voldoende tijd te geven. Bevestig dat de nieuwe mailserver daadwerkelijk werkt voordat je een DNS-record aanpast dat ernaartoe wijst. Schakel MX-records om tijdens een rustig moment voor het verkeer, doorgaans 's nachts of in het weekend.
Zodra de nieuwe server stabiel is, maak je de tijdelijke instelling ongedaan. Verhoog de TTL weer naar 3600 seconden of hoger zodra alles naar behoren werkt, aangezien een langere TTL dagelijks beter presteert en de korte waarde alleen nuttig is rondom de omschakeling zelf. Het permanent kort houden ervan zorgt voor extra belasting en afhankelijkheid van je authoritatieve DNS-servers zonder dat het op de lange termijn voordelen biedt.
Wat mensen verkeerd begrijpen over DNS-propagatie
Het woord zelf veroorzaakt de meeste verwarring. Er wordt in werkelijkheid niets over het internet "verstuurd"; resolver-caches verlopen simpelweg op basis van de TTL die de zonebeheerder heeft ingesteld, en er is geen mechanisme dat je wijziging ergens rondbazuint. De enige betrouwbare manier om te bevestigen dat een wijziging live is, is door dit te controleren met een multi-resolver tool, resolver voor resolver, in plaats van op je eigen browser te vertrouwen.
Het cijfer "24 tot 48 uur" wordt als een natuurwet beschouwd, maar voor normale recordbewerkingen is dat niet zo. Dat getal stamt uit de begindagen van commerciële DNS, toen registrars routinematig TTL's van 24 uur afdwongen en sommige ISP-resolvers daar nog hun eigen vertraging bovenop deden. Met een moderne TTL van 300 seconden die ruim van tevoren is ingesteld, zijn de meeste recordwijzigingen binnen minuten verwerkt, niet dagen.
Wijzigingen aan nameservers zijn de echte uitzondering, en TTL helpt hier niet op de manier zoals bij gewone records. Het wijzigen van nameservers voegt een extra laag propagatie toe bij de registry zelf, en wijzigingen in nameserver-records kunnen tot 48 uur duren omdat registries hun zonebestanden volgens hun eigen planning bijwerken, niet die van jou. Die vertraging bestaat omdat nameserver-records afkomstig zijn van de root-nameservers, die meestal een TTL van twee volle dagen, 172,800 seconden, meegeven, waardoor resolvers overal de oude delegatie zo lang vasthouden.
ISP's voegen een extra variabele toe die je niet vanaf je eigen bureau kunt controleren. Sommige providers negeren gepubliceerde TTL-instellingen volledig en verversen hun eigen gecachete records slechts elke twee of drie dagen. Als een wijziging op elke publieke checker voltooid lijkt maar één bezoeker nog steeds op de oude server uitkomt, is de resolver van hun ISP meestal de reden, niet jouw configuratie.
Wat dit in de praktijk betekent
Voordat je iets aanpast, maak je een lijst van elk record dat gekoppeld is aan de dienst die je verhuist: A, AAAA, CNAME, MX en eventuele TXT-records voor SPF of DMARC. Noteer de huidige TTL van elk, want dat cijfer is je echte tijdlijn, geen gok. Vierenveertig uur vóór de migratie verlaag je de TTL op de A-, AAAA- en CNAME-records die je wilt wijzigen naar 300 seconden. Laat records die je niet aanpast met rust.
Wijzig het IP-adres en de nameservers als afzonderlijke gebeurtenissen in plaats van tegelijkertijd, omdat het combineren ervan het veel moeilijker maakt om te zien welke laag nog verouderd is. Houd de oude server of mailbox draaiende gedurende het volledige oude TTL-venster, zodat iedereen die nog op een gecached antwoord zit niet tegen een doodlopend spoor aanloopt. Deze simpele gewoonte voorkomt het grootste deel van wat mensen een migratiestoring noemen.
Controleer de status met een tool die hiervoor gemaakt is, niet met je eigen browser. Het publieke resolver-netwerk van Google, 8.8.8.8, is een van de grootste ter wereld en is over het algemeen TTL-compliant, wat het een betrouwbaar referentiepunt maakt. Als je eigen verbinding na het verstrijken van het TTL-venster nog steeds het oude antwoord toont, zal een herstart van je router of overschakelen naar een publieke resolver zoals Google Public DNS vaak sneller de nieuwe cache-status ophalen dan wachten op je ISP.
Zodra de overstap over alle resolvers heen stabiel is bevestigd, verhoog je de TTL weer naar een productiewaarde en ga je verder. Het hele proces beloont geduld tijdens de voorbereidingsfase, niet urgentie op de dag zelf. Een migratie die 48 uur van tevoren is gepland met een TTL van 300 seconden is bijna altijd beter dan een overhaaste migratie op het laatste moment.
