'Propagatie': waarom de een het al ziet en de ander niet

Module 6: Tijd, cache en verhuizen · Leestijd: 8 minuten

Leerdoel: Na deze les kun je uitleggen waarom een DNS-wijziging niet overal tegelijk zichtbaar is, inschatten hoe lang het duurt en het probleem oplossen als alleen jij de oude situatie nog ziet.

Kernbegrippen: 'propagatie', cache, negatieve cache (NXDOMAIN), SOA-minimum, delegatie-TTL, nameserverwijziging, cache legen

Een misverstand in één woord

Je hebt een record gewijzigd. Je collega ziet de nieuwe website al, jij nog de oude. Op internet lees je dan: "wacht maar, de DNS moet nog propageren." Het woord propagatie (verspreiding) wekt de indruk dat je wijziging als een golf over internet rolt, van server naar server.

Zo werkt het niet. Je wijziging staat meteen op de gezaghebbende nameservers van je domein (of binnen een paar minuten, als je DNS-partij meerdere nameservers synchroniseert). Er wordt niets rondgestuurd. Wat je ziet, is het verlopen van caches: elke resolver geeft het oude antwoord tot de TTL in zijn cache op is (les 6.1). Omdat elke resolver op een ander moment begon te tellen, ziet de een de wijziging eerder dan de ander.

"Propagatie" is dus eigenlijk: wachten tot alle caches leeg zijn gelopen. Dat inzicht helpt je, want je weet nu precies waar je op wacht en hoe lang maximaal.

Hoe lang duurt het?

Dat hangt af van wat je wijzigt.

Bestaande records

Hier is het simpel: de oude TTL is het maximum. Had het record TTL 3600, dan ziet iedereen het nieuwe antwoord uiterlijk een uur na je wijziging. Ziet iemand na ruim een uur nog steeds het oude, dan zit het probleem ergens anders (zie verderop).

Nieuwe records en de negatieve cache

Een nieuw record werkt vaak meteen, behalve als iemand de naam al opvroeg toen hij nog niet bestond. De resolver kreeg toen het antwoord NXDOMAIN ("deze naam bestaat niet") of "deze naam bestaat, maar heeft geen record van dit type". Ook dat "nee" wordt onthouden. Dat heet de negatieve cache.

Hoe lang een "nee" bewaard wordt, staat niet in een record dat niet bestaat. Het komt uit het SOA-record van de zone: volgens RFC 2308 is het de kleinste van twee getallen, de TTL van het SOA-record zelf en het laatste veld van het SOA-record (het "minimum"). Een voorbeeld:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026110701 ; serienummer
                             14400      ; refresh
                             3600       ; retry
                             1209600    ; expire
                             300 )      ; minimum

Hier wordt een "nee" maximaal 300 seconden onthouden (de kleinste van 3600 en 300). Bij sommige zones is dat een uur of meer.

Daarom de gouden regel: open een nieuw subdomein niet in je browser voordat je het hebt aangemaakt. Je computer en je resolver onthouden dan dat het niet bestaat, en jij bent de enige die moet wachten.

Nameservers wijzigen

Bij een nameserverwijziging wacht je op iets anders: de NS-records bij de registry van je extensie. Die records vertellen resolvers waar de nameservers van je domein staan (les 2.1), en ook die worden onthouden. Elke registry kiest daar een eigen TTL voor. Gemeten in november 2026:

Daar komt bij dat een registry je wijziging soms niet meteen publiceert, en dat de nameservers van je oude partij in de tussentijd vaak nog antwoorden met de oude zone. Reken daarom bij een nameserverwissel op een paar uur, en bij .com op maximaal twee dagen. Zorg er dus voor dat beide partijen tijdens de wissel dezelfde, juiste records hebben (les 6.3).

Zie jij als enige nog het oude?

Ziet een online checker het nieuwe antwoord al bij bijna alle resolvers, maar jij niet? Dan zit het oude antwoord bij jou in de buurt. Loop deze stappen na, van snel naar grondig:

1. Privévenster of andere browser. Je browser bewaart DNS-antwoorden en pagina's.
2. Telefoon via 4G of 5G, met wifi uit. Dan gebruik je de resolver van je mobiele provider in plaats van die van je thuisnetwerk.

3. Cache van je computer legen.

   • Windows (Opdrachtprompt): ipconfig /flushdns
   • macOS (Terminal): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux met systemd-resolved: resolvectl flush-caches
4. Router herstarten. Veel routers werken als kleine resolver met een eigen cache.
5. Hosts-bestand controleren. Heb je eerder een nieuwe server getest door het adres in je hosts-bestand te zetten (C:\Windows\System32\drivers\etc\hosts of /etc/hosts)? Die regel gaat vóór de DNS. Haal hem weg. Dit wordt vaak vergeten.
6. Rechtstreeks bij de bron kijken. Vraag het record op bij de gezaghebbende nameserver (dig A example.com @ns1.hosting.example). Staat daar ook nog het oude antwoord, dan is de wijziging niet goed opgeslagen of heb je hem op de verkeerde plek gedaan.

Na de wachttijd nog steeds niets?

Als de TTL al lang verstreken is en ook online tools het oude antwoord tonen, is wachten zinloos. Dan is er iets anders aan de hand. De drie meest voorkomende oorzaken:

• Gewijzigd op de verkeerde plek. Je domein gebruikt de nameservers van een andere partij (bijvoorbeeld Cloudflare of een sitebouwer), en je wijzigde de records bij je hostingpartij. Kijk welke nameservers je domein heeft (les 2.1) en wijzig daar.
• Typefout of ontbrekende punt. mail.example.com zonder punt wordt in veel panelen mail.example.com.example.com (les 2.2).
• De nameservers zijn het onderling niet eens. Een domein heeft minstens twee nameservers. Als die niet goed synchroniseren, geeft de ene het nieuwe en de andere het oude antwoord. Vergelijk het SOA-serienummer bij elke nameserver: dat moet gelijk zijn.

dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.example

In de praktijk: zo ziet het eruit in een paneel

Wil je zien wat resolvers op verschillende plekken in de wereld antwoorden, gebruik dan een online DNS-checker die per land een resolver bevraagt (bijvoorbeeld dnschecker.org). In het voorbeeldpaneel Mijn WebOké controleert de kaart Domein / Email gezondheid de nameservers en records van je domein bij de gezaghebbende nameservers, en de DNS-diagnose vergelijkt de serienummers van de nameservers. Andere aanbieders hebben vaak een vergelijkbare controle in hun paneel; zo niet, dan geven dig en de online tools uit les 8.3 hetzelfde beeld.

Samenvatting

• Er wordt niets "verspreid": je wacht tot caches verlopen.
• Een gewijzigd record is uiterlijk na de oude TTL overal zichtbaar; een nieuw record meestal meteen, tenzij iemand de naam al eerder opvroeg (negatieve cache, bepaald door het SOA-record).
• Een nameserverwissel hangt af van de TTL bij de registry: bij .nl een uur, bij .com twee dagen.
• Zie alleen jij het oude nog? Privévenster, 4G, cache legen, router herstarten en het hosts-bestand nakijken.
• Nog steeds oud bij de gezaghebbende nameserver? Dan is wachten zinloos: zoek de fout.

Quiz

Opdracht

Opdracht Z6.2: Delegatie-TTL en negatieve cache. Twee vragen, beide te beantwoorden met dig of een online dig-tool:

1. Hoeveel seconden onthouden resolvers volgens de .com-registry de nameservers van google.com? Vraag het op bij een .com-server: dig NS google.com @a.gtld-servers.net en kijk naar de TTL in het AUTHORITY-gedeelte.
2. Hoeveel seconden onthoudt een resolver dat een naam onder sidn.nl niet bestaat? Vraag het SOA-record van sidn.nl op bij ns1.sidn.nl en pas de regel uit deze les toe (de kleinste van de SOA-TTL en het SOA-minimum).

Verder lezen

De stappen in deze artikelen gaan over de panelen van WebOké; in andere panelen werkt het vergelijkbaar.

• Hoe lang duurt een nameserver- of DNS-wijziging, en wat als je hem niet ziet?
• Website of e-mail werkt niet na een verhuizing of DNS-wijziging: controleer je domein
• DirectAdmin handleiding 5.11: Wanneer werkt een wijziging? Wachttijd en TTL
• Een subdomein aanmaken, en wat te doen als het niet werkt
• Hoe kan ik mijn domein testen voor hij verhuisd is? (localhost)
• WebOké handleiding 5.17: Domein en e-mail gezondheid: controleren en herstellen