Wat is DNS-propagatie en hoe beperk je de impact?

DNS-propagatie is de periode waarin sommige resolvers nog de oude waarde van een record blijven geven nadat je die op de gezaghebbende nameserver hebt gewijzigd. Er wordt niets over het internet verspreid: elke resolver bewaart zijn antwoord in de cache tot de TTL verstrijkt. De vertraging loopt van enkele minuten tot 24 of 48 uur bij een wijziging van nameservers, afhankelijk van de TTL van het record vóór de wijziging en, bij nameservers, van de delegatie-TTL van de registry. Zo werkt het en zo beperk je de gevolgen.

Belangrijkste punten

Je wijziging is direct zichtbaar op de gezaghebbende server. De vertraging komt alleen van de caches van resolvers, die de oude waarde bewaren tot de TTL verloopt.
Hoe lang de oude waarde blijft hangen, bepaalt de TTL die gold vóór de wijziging, niet de TTL die je net hebt ingesteld. Verlaag die dus op tijd.
Een wijziging van nameservers is het traagst, omdat die afhangt van de delegatie-TTL van de registry, waar je geen controle over hebt.
Foutmeldingen als "deze naam bestaat niet" worden ook gecachet: een naam bezoeken voordat het record bestaat kan de fout verlengen.

Wat DNS-propagatie niet is: een uitzending

De term is misleidend. Geen enkele server stuurt je wijziging naar andere servers. Zodra je een wijziging bij je DNS-aanbieder opslaat, geeft de gezaghebbende nameserver van de zone meteen de nieuwe waarde. De vertraging zit elders, in de caches.

Wanneer een apparaat het adres van een domeinnaam opzoekt, gaat de aanvraag door meerdere lagen, en elke laag kan het antwoord onthouden:

de browser, waarvan de cache meestal ongeveer een minuut duurt en zich niet altijd aan de TTL houdt;
het besturingssysteem, dat recente antwoorden bewaart;
de recursieve resolver van je internetprovider of van een openbare dienst (bijvoorbeeld 8.8.8.8 bij Google, 1.1.1.1 bij Cloudflare), die de DNS-hiërarchie doorloopt en het resultaat opslaat.

Elke resolver past de TTL toe die de gezaghebbende server hem meegaf op het moment dat hij het antwoord cachete. Omdat ze niet allemaal tegelijk hebben gevraagd, verlopen hun kopieën op verschillende momenten. Een record met een TTL van 3600 seconden dat 5 minuten geleden is gecachet, wordt over 55 minuten vernieuwd. Vandaar de tegenstrijdige meldingen: de een ziet de nieuwe site, de ander de oude, een derde een foutmelding.

Hoe lang DNS-propagatie duurt

De duur hangt af van het type wijziging. Een TTL van een dag (86.400 seconden) komt vaak voor, en voor records die zelden veranderen, zoals nameservers, liggen de waarden hoger.

Type wijziging	Gebruikelijke duur	Wat bepaalt het
Een bestaand record wijzigen (A, AAAA, CNAME, MX, TXT)	Tot de lengte van de oude TTL, van enkele minuten tot 24 uur afhankelijk van de configuratie	De TTL die gold vóór de wijziging
Een record aanmaken dat niet bestond	Wisselend, meestal hooguit enkele uren	De SOA van de zone (SOA-TTL en MINIMUM-veld)
Nameservers wijzigen bij de registrar	Enkele uren tot 48 uur	De delegatie-TTL van de registry, vaak een tot twee dagen
Een resolver met eigen limieten	Kan de opgegeven TTL overschrijden	Een ingestelde boven- of ondergrens (standaard 86.400 s bij Unbound, 604.800 s bij BIND)

De drie factoren die de vertraging bepalen

De TTL van vóór de wijziging

Stel dat een record een TTL van 86.400 seconden heeft en je zet die vandaag op 300. Een resolver die het record gisteren cachete, bewaart de oude waarde tot 24 uur, wat de nieuwe waarde ook is: de TTL van 300 seconden geldt pas zodra zijn kopie wordt vernieuwd. Bij een CNAME heeft elke naam in de keten een eigen TTL, en de langste bepaalt de totale vertraging.

De delegatie bij de registry

Wanneer je van nameservers wisselt, voer je de wijziging door bij de registrar, die haar doorgeeft aan de registry van het topniveaudomein. Resolvers die nog de oude lijst met nameservers kennen, blijven die bevragen tot de delegatie verloopt. Die TTL is van de registry: je kunt hem niet inkorten.

Resolvers die de TTL niet letterlijk volgen

Sommige resolvers begrenzen of verhogen TTL-waarden, en browsers hebben een eigen kortlevende cache. Overal dezelfde duur kan dus niet worden gegarandeerd. De TTL is een theoretische grens, geen belofte van elke cache.

De valkuil van negatieve caching

De meeste gidsen bespreken de TTL van records en vergeten de negatieve antwoorden. Als een resolver ontdekt dat een naam niet bestaat (een NXDOMAIN-antwoord) of geen record van het gevraagde type heeft, kan hij die afwezigheid onthouden. RFC 2308 stelt de duur van de negatieve cache vast op de kleinste van twee waarden: de SOA-TTL van de zone en het MINIMUM-veld. Een tot drie uur noemt de RFC redelijk, en waarden boven een dag geven problemen.

Het typische scenario: je test nieuw.example.com voordat het record bestaat, krijgt een fout en maakt daarna het record aan. Voor jouw resolver "bestaat" de naam niet tot de negatieve cache afloopt, ook al staat het record al een minuut online. Zo voorkom je het:

maak het record aan voordat je de naam test of aankondigt;
als je DNS-aanbieder de SOA laat aanpassen, houd het MINIMUM-veld dan gematigd;
leeg je lokale cache voordat je concludeert dat het "niet werkt": Microsoft vermeldt dat ipconfig /flushdns ook negatieve cachevermeldingen weggooit.

Methode om de impact van een migratie te beperken

Noteer de huidige TTL van elk betrokken record (zie de opdrachten hieronder). Die bepaalt de vertraging.
Verlaag de TTL naar 300 seconden, minstens zo ver van tevoren als de oude TTL duurt. Bij 86.400 seconden doe je dat 24 tot 48 uur voor de omschakeling. Controleer het minimum dat je aanbieder accepteert.
Bereid de nieuwe bestemming voor: website, mailserver of CDN die klaar is om met dezelfde inhoud als de oude te antwoorden. Beide moeten tijdens de overgang werken.
Schakel het record om, één wijziging tegelijk, zodat je weet wat je moet controleren.
Controleer eerst de gezaghebbende server, dan openbare resolvers.
Laat de oude server draaien minstens tot de langste oude TTL voorbij is, en zet hem pas daarna uit.
Verhoog de TTL weer (3600 seconden of meer) zodra alles stabiel is.

Bij een wijziging van nameservers maak je eerst de volledige zone opnieuw aan bij de nieuwe aanbieder (A, CNAME, MX, TXT inclusief SPF en DKIM, en al het overige), controleer je of die correct antwoordt en wijzig je pas daarna de nameservers bij de registrar. Laat de zone bij de oude aanbieder 48 uur online en identiek: resolvers die de oude delegatie nog kennen, blijven die bevragen.

Controleren wat elke resolver ziet

Met de opdracht dig (macOS, Linux) of nslookup (Windows) vergelijk je wat de gezaghebbende server en meerdere openbare resolvers antwoorden.

# Waarde en resterende TTL bij openbare resolvers
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1

# Voor het domein ingestelde nameservers
dig +short NS example.com

# Waarde van de gezaghebbende server (vervang door je eigen nameserver)
dig +noall +answer example.com A @ns1.dns-aanbieder.example

# SOA-serienummer, om te vergelijken tussen nameservers
dig +short SOA example.com @ns1.dns-aanbieder.example
dig +short SOA example.com @ns2.dns-aanbieder.example

# Equivalent in Windows
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.com

In het antwoord van een resolver daalt de getoonde TTL van aanvraag tot aanvraag: het is de tijd die resteert voordat zijn kopie verloopt. Geeft een resolver de oude waarde met een TTL die blijft aftellen terwijl de gezaghebbende server al de nieuwe geeft, dan hoef je alleen te wachten.

Vergelijk ook het SOA-serienummer van je nameservers. Als die verschillen, geeft een server verouderde gegevens: het probleem ligt dan bij je DNS-aanbieder, niet bij de propagatie. Op dns.google kun je een specifiek recordtype opvragen, ook SOA, en de probleemoplossing van Google Public DNS beschrijft deze controle.

De caches legen die je zelf beheert

Je eigen cache legen verandert niets voor andere bezoekers, maar laat wel zien wat je zelf echt ziet.

# Windows (opdrachtprompt)
ipconfig /flushdns

# Recente macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux met systemd-resolved
resolvectl flush-caches

Microsoft beschrijft /flushdns en /displaydns op de pagina over de opdracht ipconfig. Sluit daarna de browser volledig af, want die heeft een eigen kortetermijngeheugen.

Twee openbare resolvers bieden ook een purge, handig na een wijziging van nameservers of voor wie ze gebruikt: de tool Flush Cache van Google Public DNS (Google raadt aan zowel het geregistreerde domein als de exacte naam met het verouderde antwoord te legen) en de cache-purge van 1.1.1.1 van Cloudflare, waar je het domein en het recordtype kiest. Resolvers van internetproviders kun je niet legen: je moet wachten tot hun kopieën verlopen.

Veelgemaakte fouten

De TTL verlagen op het moment van omschakelen. Dat is te laat: resolvers houden de kopie vast die met de oude TTL is gemaakt.
De naam testen voordat het record bestaat. Negatieve caching kan de fout verlengen.
Nameservers wijzigen voordat de hele zone opnieuw is aangemaakt. Vergeten mail- of subdomeinrecords werken niet meer voor resolvers die al de nieuwe aanbieder bevragen.
De oude server te vroeg uitzetten. Bezoekers van wie de cache nog niet is verlopen, komen op een server terecht die niet meer antwoordt.
Vanaf je eigen computer concluderen dat de propagatie klaar is. Je lokale cache vertegenwoordigt de andere resolvers niet.
Een zeer lage TTL permanent laten staan. Dat vermenigvuldigt de aanvragen aan je nameservers. Verhoog hem na afloop van de migratie.

Veelgestelde vragen

Hoe lang duurt DNS-propagatie?

Bij een gewijzigd record hooguit de lengte van de oude TTL: een uur bij een TTL van 3600 seconden, 24 uur bij 86.400. Bij een wijziging van nameservers enkele uren tot 48 uur. De meeste resolvers werken ruim voor de maximale termijn bij. Wat overblijft, zijn enkele late caches.

Kan DNS-propagatie worden versneld?

Niet over het hele internet: de caches van anderen kun je niet afdwingen. Je kunt wel de TTL vóór de wijziging verlagen, de openbare resolvers van Google en Cloudflare legen en je eigen caches wissen. Resolvers van internetproviders kun je niet legen.

Welke TTL kies ik vóór een migratie?

Een korte waarde zoals 300 seconden (5 minuten), minstens zo lang toegepast als de oude TTL vóór de omschakeling duurt. Zodra de migratie stabiel is, verhoog je die weer naar 3600 seconden of meer: een permanent zeer lage TTL vermenigvuldigt de aanvragen. Controleer het minimum dat je DNS-aanbieder accepteert.

Waarom ziet mijn collega de nieuwe site en ik niet?

Jullie gaan via verschillende resolvers, die het antwoord op verschillende momenten cachete. Bevraag vanaf beide computers dezelfde openbare resolver om te vergelijken en leeg daarna de lokale cache van de computer die nog de oude versie ziet.

Wat gebeurt er met mijn e-mail tijdens de propagatie?

Een MX-wijziging volgt dezelfde regels: tijdens de vertraging schrijven sommige afzenders nog naar de oude mailserver. Houd die actief tot de overgang voorbij is. Is een server niet beschikbaar, dan bewaren verzendende servers de berichten doorgaans en proberen ze het enkele dagen opnieuw.

Moet ik de cache van mijn computer legen?

Ja, om te controleren wat je ziet, maar voor andere bezoekers verandert er niets. Gebruik de opdracht van je systeem en sluit de browser volledig af. Is de waarde nog steeds oud, dan houdt de resolver van je internetprovider de kopie vast.

Waarom geven online propagatiecontroles verschillende resultaten?

Elke tool bevraagt resolvers in andere landen, die het antwoord op verschillende momenten cachete. Een gemengd resultaat is normaal zolang de TTL niet overal is verlopen. Antwoorden de gezaghebbende nameservers zelf verschillend, vergelijk dan hun SOA-serienummers: het probleem zit dan in de zone, niet in de propagatie.