DNS-propagatie is de tijd tussen het wijzigen van een DNS-record en het moment waarop iedereen de nieuwe waarde ziet. Er wordt eigenlijk niets verspreid: resolvers op het internet blijven de kopie uit hun cache serveren tot de TTL (time to live) verloopt, en vragen het daarna opnieuw. De meeste recordwijzigingen zijn overal zichtbaar binnen de TTL van het oude record, vaak een paar minuten tot een uur. Een wijziging van nameservers bij de registrar kan tot twee dagen duren. Wil je weten hoe ver een wijziging is, vraag dan eerst de eigen nameservers van het domein wat ze publiceren, en vraag daarna een paar publieke resolvers wat ze nog in hun cache hebben.
Wat er gebeurt als je een record wijzigt
De browser van een bezoeker vraagt het niet rechtstreeks aan je DNS-provider. De vraag gaat langs meerdere caches, en elk daarvan kan uit het geheugen antwoorden:
De browser onthoudt recente antwoorden een korte tijd.
Het besturingssysteem heeft een eigen resolvercache.
Een recursieve resolver bij de provider, op het bedrijfsnetwerk of een publieke dienst zoals 1.1.1.1 of 8.8.8.8 bewaart elk antwoord zo lang als de TTL toestaat.
De gezaghebbende (authoritative) nameservers van je domein bevatten de echte records. Alleen zij weten in eerste instantie van je wijziging.
Sla je een wijziging op bij je DNS-provider, dan serveren de authoritative nameservers die meestal binnen enkele seconden of minuten. Elke cache verderop houdt het oude antwoord vast tot de kopie verloopt. Twee bezoekers op verschillende netwerken kunnen dus een tijdje verschillende servers zien, en dat is normaal, geen fout. De TTL stel je zelf per record in, in seconden; de woordenlijst over DNS-propagatie geeft de korte versie.
Hoe lang DNS-propagatie duurt
Gewone records: de oude TTL
Voor een A-, AAAA-, CNAME-, MX- of TXT-record is de langste wachttijd de TTL die het oude record had toen resolvers het in hun cache opsloegen. Een record met een TTL van 3600 kan tot een uur na je wijziging uit de cache worden geserveerd. De TTL verlagen op hetzelfde moment als de wijziging helpt niet, want resolvers die de oude kopie al hebben, houden die vast voor de oude TTL.
Nameserverwijzigingen: de bovenliggende zone
Een domein verhuizen naar een andere DNS-provider betekent de NS-records wijzigen bij de registrar. Die worden gepubliceerd in de bovenliggende zone, zoals .com, en die zone bepaalt hun TTL, niet jij. Je ziet het zelf door een .com-server rechtstreeks te bevragen:
dig +norecurse @a.gtld-servers.net example.com NS
Het antwoord toont de nameservers met een TTL van 172800 seconden, oftewel 48 uur. Daar komt het advies “tot 48 uur” vandaan. In die periode vragen sommige resolvers het aan de oude provider en andere aan de nieuwe, dus beide moeten dezelfde records serveren tot de wijziging is doorgevoerd.
Nieuwe namen: negatieve caching
Heeft iemand een naam opgezocht voordat die bestond, bijvoorbeeld een nieuw subdomein dat je te vroeg testte, dan kunnen resolvers ook het antwoord “deze naam bestaat niet” in hun cache bewaren. RFC 2308 bepaalt hoe lang: de laagste waarde van het minimumveld van het SOA-record en de eigen TTL van het SOA-record. Daarom kan een gloednieuw subdomein op het ene netwerk een tijdje DNS_PROBE_FINISHED_NXDOMAIN geven en op het andere gewoon werken.
Applicaties die adressen vasthouden
Een programma dat lang draait, zoals een applicatieserver of een proxy, zoekt een hostnaam soms één keer op bij het starten en houdt het adres vast tot het herstart, wat de TTL ook zegt. Praat één dienst nog met de oude server terwijl de rest al is overgestapt, herstart die dan voordat je DNS verdenkt.
Zo controleer je DNS-propagatie
Werk van de bron naar buiten. Controleer eerst of de wijziging is gepubliceerd en kijk daarna welke caches nog het oude antwoord hebben.
1. Zoek de authoritative nameservers op
dig NS example.com +short
Zijn dit niet de nameservers van de provider waar je de wijziging hebt gedaan, dan heb je de verkeerde zone aangepast. Dat is een veelvoorkomende reden dat een wijziging “nooit doorkomt”.
2. Bevraag elke nameserver rechtstreeks
dig @ns1.example-dns.com example.com A +short
dig @ns1.example-dns.com example.com SOA +short
Herhaal dit voor elke nameserver in de lijst. Ze moeten allemaal de nieuwe waarde teruggeven en hetzelfde SOA-serienummer, het derde veld van het SOA-antwoord. Een server met een ouder serienummer heeft de update nog niet ontvangen; dat is propagatie binnen je provider, en die is meestal binnen een paar minuten rond.
3. Bevraag publieke resolvers
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
Zonder +short toont dig de TTL bij elk antwoord. Bij een resolver is dat getal de resterende tijd van de gecachte kopie: een oude waarde met nog 1200 seconden te gaan, is binnen 20 minuten vervangen. Op Windows bevraag je met nslookup -type=A example.com 1.1.1.1 een specifieke resolver, zonder TTL. Onze gratis DNS-lookup toont de antwoorden en TTL’s voor elk recordtype vanaf de resolver van onze server in Stockholm, zonder dat je iets hoeft te installeren.
4. Volg de delegatie na een nameserververhuizing
dig +trace example.com
+trace begint bij de root en volgt de verwijzingen omlaag tot aan je nameservers, zonder onderweg caches te gebruiken. Eindigt de trace bij de nieuwe provider, dan is de wijziging bij de registrar actief en moeten alleen de caches nog bijtrekken.
Plan een wijziging zodat propagatie geen pijn doet
Na een wijziging kun je propagatie niet versnellen, maar vooraf kun je haar wel kort maken. Voor een verhuizing naar een nieuwe server:
WanneerStapMinstens één oude TTL voorafVerlaag de TTL van het record, bijvoorbeeld van 3600 naar 300 seconden.Voor de wijzigingZet de nieuwe server op en test hem, bijvoorbeeld met een regel in je hosts-bestand of met curl –resolve.De wijzigingLaat het record naar de nieuwe server wijzen en controleer het authoritative antwoord.Tijdens de propagatieLaat de oude server draaien met dezelfde content. Sommige bezoekers komen daar nog uit.Een dag of zo laterVerhoog de TTL weer en zet de oude server uit.
Bij een nameserververhuizing kopieer je eerst elk record naar de nieuwe provider en vergelijk je de twee zones record voor record, inclusief MX en TXT. Een vergeten TXT-record breekt de e-mailauthenticatie; de SPF-, DKIM- en DMARC-checker laat zien of die nog slaagt. Gebruikt het domein DNSSEC, volg dan de stappen van de nieuwe provider voor het DS-record bij de registrar, want een DS-record dat niet bij de nieuwe nameservers past, laat validerende resolvers SERVFAIL antwoorden.
Caches legen die je zelf beheert
Je kunt je eigen caches legen om de nieuwe waarde eerder te zien, handig bij het testen. Voor je bezoekers verandert dat niets.
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows: ipconfig /flushdns
Chrome: open chrome://net-internals/#dns en leeg de hostcache.
Publieke resolvers: bij Cloudflare en Google kun je één naam uit hun cache verwijderen, via de purge-pagina van 1.1.1.1 en de flush-pagina van Google Public DNS.
De resolver van je internetprovider en die van je bezoekers kun je niet van buitenaf legen. Die verlopen in hun eigen tempo.
Als het geen propagatie is
Geven de authoritative nameservers nog de oude waarde, dan helpt wachten niet. Zoek dan naar een van deze oorzaken:
De verkeerde zone of provider. Het record is gewijzigd bij een provider die het domein niet meer gebruikt.
De verkeerde naam. Het hoofddomein (example.com) en www.example.com zijn aparte records.
Een proxy ervoor. Staat er een CDN of proxy aan voor het record, dan geeft publieke DNS bewust de adressen van de proxy terug, niet die van je server.
Een record dat nooit is opgeslagen, of een typefout in de waarde. Vergelijk wat je in het paneel van de provider ziet met het antwoord van dig.
Het item DNS-recordtypen legt uit wat elk record doet, en de checklist voor een website die down is behandelt de stappen na DNS.
Weet wanneer een record verandert met Uptimecheck
Propagatie is de geplande soort DNS-wijziging. De ongeplande soort, een typefout tijdens een migratie of een gekaapt registraraccount, is degene waarvoor je een alert wilt. DNS-monitoring van Uptimecheck bewaakt A-, AAAA-, CNAME-, MX-, NS-, SOA-, TXT- en CAA-records:
De monitor bevraagt de authoritative nameservers van het domein rechtstreeks, dus een wijziging is bij de volgende check zichtbaar, zonder resolvercache ertussen. Geven de nameservers verschillende antwoorden, dan staat dat op de monitorpagina.
Een nieuwe set records levert een alert op zodra twee checks op rij die hebben gezien, met de oude en de nieuwe waarden, en wordt bewaard in de geschiedenis van het record.
Vul de waarden in die je verwacht, en de check faalt zodra de gepubliceerde records daar niet mee overeenkomen. Zo weet je ook zeker dat een geplande wijziging live is gegaan.
Checks draaien zo vaak als elke minuut. Start bevat 10 DNS-monitors, Professional 25 en Business 150.
Combineer het met uptimechecks op de site zelf en monitoring van domeinverloop. Lees hoe je DNS-monitoring instelt om er een aan te maken, en hoe je gekaapte DNS-records herkent voor de waarschuwingssignalen.
Weet het meteen als je records veranderen. Probeer Uptimecheck 14 dagen gratis, geen creditcard nodig.