Wat is DNS-propagatie? Uitleg, duur en controle

Je hebt net een DNS-wijziging doorgevoerd, bijvoorbeeld nieuwe nameservers, een ander IP-adres of een aangepast MX-record, en er verandert nog niets. Dat is normaal. DNS-propagatie is de tijd die het kost voordat zo'n wijziging overal op internet zichtbaar is. In dit artikel lees je wat DNS-propagatie precies is, waarom het tijd kost, hoe lang het duurt en hoe je de voortgang zelf controleert.

Wat is DNS-propagatie?

DNS-propagatie is de periode waarin een DNS-wijziging overal zichtbaar wordt. De term is eigenlijk misleidend, want er wordt niets actief verstuurd of gepusht. Zodra je een wijziging opslaat, is die vrijwel direct actief op de autoritatieve nameservers van je domein. Dat zijn de servers die het officiële antwoord over jouw domein geven. Bij LJPc beheer je je DNS in Plesk en een wijziging die je daar opslaat, staat vrijwel meteen op onze nameservers ns1, ns2 en ns3.ljpc.network.

De vertraging die je ervaart, komt niet van die nameservers, maar van caching onderweg. Overal tussen jou en de nameservers bewaren DNS-resolvers een kopie van het vorige antwoord. Zolang die kopie nog geldig is, krijg je de oude waarde te zien. Propagatie is dus geen verspreiding van nieuwe gegevens, maar het verlopen van verouderde kopieën.

Een DNS-aanvraag loopt via meerdere schakels: de resolver van je internetprovider, soms een publieke resolver zoals die van Google (8.8.8.8) of Cloudflare (1.1.1.1), de cache van je besturingssysteem en zelfs de cache van je browser. Elke schakel bewaart het antwoord onafhankelijk, en elke kopie verloopt op een eigen moment. Daardoor kan de wijziging bij jou al zichtbaar zijn terwijl een ander nog het oude adres ziet.

Waarom kost een DNS-wijziging tijd?

De TTL bepaalt hoe lang een antwoord wordt bewaard

Elk DNS-record heeft een TTL (Time To Live). Dat is een getal in seconden dat aangeeft hoe lang een resolver het antwoord mag bewaren voordat hij het opnieuw ophaalt. Een veelgebruikte standaardwaarde is 3600 seconden, oftewel 1 uur. Staat de TTL van je oude record op een uur, dan kan een resolver dat oude antwoord tot een uur lang blijven teruggeven, ook nadat jij de nieuwe waarde al hebt opgeslagen.

Bij LJPc is de standaard-TTL 1 uur (3600 seconden). Je kunt de TTL per record aanpassen tussen 60 en 86400 seconden (een minuut tot een dag). Een lagere TTL zorgt voor snellere wijzigingen, maar iets meer DNS-verkeer; een hogere TTL doet het omgekeerde.

Niet elke resolver houdt zich netjes aan de TTL

In theorie verloopt een antwoord in de cache precies na de TTL. In de praktijk negeren sommige providers de TTL en bewaren ze antwoorden langer om verkeer te besparen. Ook staan er caches op plekken waar jij geen invloed op hebt. Dat verklaart waarom een wijziging niet overal op hetzelfde moment doorkomt en waarom je soms geduld moet hebben, ook al klopt alles aan jouw kant.

Hoe lang duurt DNS-propagatie?

Voor een gewone recordwijziging, zoals een nieuw IP-adres in een A-record, gaat het vaak snel: van een paar minuten tot enkele uren, afhankelijk van de TTL. De bekende vuistregel is dat je maximaal 24 tot 48 uur moet aanhouden. Die uiterste termijn geldt vooral bij hoge TTL-waarden, bij providers die de TTL oprekken en bij het wisselen van nameservers.

Nameserver- en registrarwijzigingen duren het langst

Wissel je van nameservers of registreer je een domein, dan komt er een extra schakel bij. De koppeling van je domein naar de juiste nameservers, de zogenoemde delegatie, moet dan eerst worden bijgewerkt bij de registry van het topleveldomein (bijvoorbeeld de organisatie achter .nl of .com). Die stap heeft zijn eigen cachetijden. Reken voor een nameserverwijziging daarom eerder op de volledige 24 tot 48 uur dan voor een losse recordwijziging. Wat nameservers precies doen, lees je in ons artikel over het NS-record.

Veelvoorkomende situaties na een wijziging

Bijna elke klacht na een DNS-wijziging is met caching te verklaren. Verander je het IP-adres, dan blijft je website bij een deel van de bezoekers nog even op de oude server staan. Pas je het MX-record aan, dan komt e-mail nog een tijdje op de oude mailserver binnen. De onderstaande tabel vat de meest voorkomende situaties samen.

Propagatie versnellen: verlaag de TTL vooraf

Je kunt propagatie niet forceren. Niemand kan de caches van alle providers wereldwijd voor je leegmaken. Wat je wel kunt doen, is de wachttijd vooraf verkleinen door de TTL te verlagen voordat je de wijziging doorvoert.

1. Verlaag ruim van tevoren de TTL van het record dat je gaat wijzigen, bijvoorbeeld naar 300 seconden (5 minuten).
2. Wacht daarna minstens zo lang als de oude TTL was (bij een uur dus zeker een uur), zodat die oude, hoge waarde overal uit de cache is verlopen.
3. Voer nu de eigenlijke wijziging door. Resolvers bewaren het nieuwe antwoord dan nog maar 5 minuten, dus een fout herstel je snel.
4. Werkt alles stabiel, zet de TTL dan weer terug naar een normale waarde zoals 3600 seconden.

Belangrijk: het verlagen van de TTL helpt alleen vooraf. Verlaag je de TTL pas nadat je de wijziging hebt doorgevoerd, dan staat de oude, hoge TTL al in de caches en moet je die alsnog uitzitten.

Hoe controleer je DNS-propagatie?

Gebruik een online propagatiechecker

Een propagatiechecker zoals whatsmydns.net bevraagt DNS-servers op tientallen locaties wereldwijd tegelijk en laat per locatie zien welk antwoord terugkomt. Zo zie je in een oogopslag waar de nieuwe waarde al actief is en waar nog niet. Handig om te volgen hoe ver een wijziging is.

Controleer zelf met dig (macOS en Linux)

Met het commando dig vraag je een record rechtstreeks op. Vergelijk het antwoord van een publieke resolver met dat van de autoritatieve nameserver om te zien of je wijziging goed is opgeslagen.

# Vraag het huidige A-record op
dig example.com A +short

# Vergelijk een publieke resolver met de autoritatieve nameserver
dig @8.8.8.8 example.com +short
dig @ns1.ljpc.network example.com +short

Geeft een autoritatieve nameserver (ns1.ljpc.network) al de nieuwe waarde, maar 8.8.8.8 nog de oude, dan is je wijziging correct opgeslagen en wacht je alleen nog op het verlopen van de cache. In de volledige uitvoer van dig, dus zonder +short, zie je bij het record een getal dat per seconde aftelt. Dat is de resterende TTL in de cache.

Controleer met nslookup (Windows)

Op Windows gebruik je nslookup. De server die je wilt bevragen zet je achter de domeinnaam.

nslookup example.com
nslookup -type=mx example.com
nslookup example.com 8.8.8.8

De melding "Non-authoritative answer" betekent alleen dat het antwoord uit de cache van de resolver komt. Dat is normaal en geen fout.

Wis je lokale DNS-cache

Je eigen computer bewaart DNS-antwoorden ook. Wil je zelf sneller de nieuwe waarde zien, wis dan je lokale cache met het commando voor jouw systeem:

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd): sudo resolvectl flush-caches

Let op: je browser houdt een eigen DNS-cache bij, los van je besturingssysteem. Sluit je browser volledig af of wis die cache apart. Het wissen van je eigen cache helpt alleen jou; de rest van de wereld moet nog steeds de TTL uitzitten. Werkt het na de maximale wachttijd nog steeds niet, dan gaat het waarschijnlijk niet om propagatie maar om een echte fout in de instellingen. Loop in dat geval de stappen in ons artikel over DNS-problemen oplossen na.

Kom je er niet uit of blijft een wijziging na de maximale wachttijd hangen? Neem gerust contact op met onze support, dan kijken we met je mee.