Je update de DNS-records van een domein, slaat de wijziging op en verwacht dat de nieuwe website of e-maildienst onmiddellijk werkt. Maar een collega ziet nog steeds de oude website, een online controletool toont een ander adres, of het e-mailverkeer vertoont inconsistente gedragingen. Deze vertraging wordt vaak DNS-propagatie.
De uitdrukking kan de indruk wekken dat een enkele update door een centraal internetsysteem reist. DNS is echter gedistribueerd. Domein informatie wordt opgeslagen en gecached op autoritatieve naamserver, recursieve resolvers, routers, besturingssystemen en applicaties. Elk systeem kan zijn informatie op een ander moment vernieuwen.
De meeste DNS-wijzigingen worden zichtbaar wanneer caches verlopen en resolvers nieuwe records ophalen. Hoe lang dit duurt, hangt af van de vorige Time to Live (TTL) van het record, het gedrag van de resolver en of de configuratie van de autoritatieve DNS correct is. Er bestaat geen universele tijd die garandeert dat elke gebruiker het nieuwe antwoord zal zien.
Deze gids legt uit wat mensen bedoelen met DNS-propagatie, waarom DNS-wijzigingen op verschillende momenten zichtbaar worden, hoe je de huidige antwoorden van een domein kunt controleren en wat je moet doen wanneer een update nog steeds onvolledig lijkt.
Wat betekent DNS-propagatie?
DNS-propagatie is de gebruikelijke term voor de periode waarin verschillende gebruikers of DNS-resolvers verschillende antwoorden kunnen ontvangen nadat de DNS-recordswijzigingen zijn doorgevoerd. Een gebruiker in één netwerk kan het nieuwe IP-adres al zien, terwijl de resolver van een andere gebruiker nog steeds een verouderd, gecached adres teruggeeft.
De onderliggende DNS-wijziging wordt uitgevoerd op de autoritatieve nameservers voor het domein. Recursieve resolvers halen vervolgens records op en cachen deze voor hun gebruikers. Deze resolvers hoeven niet elke keer dat iemand het domein bezoekt opnieuw de autoritatieve servers te raadplegen. Ze kunnen een gecachte antwoorden hergebruiken zolang deze geldig blijft.
Dit is waarom “voortplanting” beter begrepen kan worden als cacheverval en vernieuwing. Er is geen centrale kopie die op elk internetverbonden apparaat tegelijk moet worden bijgewerkt. Het autoritatieve record kan al correct zijn, zelfs terwijl sommige resolvers nog steeds oudere gecachte gegevens serveren.
Hoe DNS-caching werkt
Wanneer een browser het IP-adres van een domein moet opzoeken, vraagt deze het besturingssysteem om de naam te resolveren. Het besturingssysteem kan een cached antwoord hebben. Zo niet, dan vraagt het een geconfigureerde recursieve resolver, zoals die wordt beheerd door een internetprovider, een bedrijf of een openbare DNS-dienst.
De recursieve resolver kan ook een cached antwoord hebben. Als dat antwoord nog binnen de cache-leefduur valt, kan het deze retourneren zonder contact op te nemen met de autoritatieve naamserver. Wanneer het gecachte record verloopt, kan de resolver het autoritatieve DNS-systeem bevragen en het bijgewerkte antwoord opslaan.
Caching vermindert de opzoektijd en de belasting van de DNS-infrastructuur. Het betekent ook dat wijzigingen in records niet noodzakelijkerwijs op hetzelfde moment zichtbaar zijn voor elke resolver. Het oude antwoord blijft bruikbaar voor een resolver totdat de cache verloopt of de resolver deze anderszins vernieuwt.
Verschillende gebruikers kunnen verschillende recursieve resolvers gebruiken. Zelfs mensen in hetzelfde huishouden kunnen verschillende antwoorden zien als hun apparaten verschillende DNS-diensten, VPN's, mobiele netwerken of lokale caches gebruiken.
Wat is TTL in DNS?
TTL staat voor Levensduur. Het is een waarde, meestal gemeten in seconden, die aangeeft hoe lang recursieve resolvers een DNS-record mogen cachen voordat ze controleren op een bijgewerkt antwoord.
Bijvoorbeeld, een TTL van 3600 betekent één uur. Als een resolver een record met die TTL ophaalt, kan het antwoord doorgaans tot wel een uur worden gebruikt voordat het moet worden ververst. Een TTL van 300 betekent vijf minuten.
De TTL die na een wijziging van belang is, is meestal de TTL van het oude record dat resolvers al hebben gecached. Het direct verlagen van de TTL vlak voor het wijzigen van een record kan de wachttijd voor resolvers die de vorige, hogere TTL hebben gecached, niet verkorten. Deze resolvers kunnen het oude antwoord blijven gebruiken tot de oorspronkelijke cachetijd verstrijkt.
Voor geplande migraties verlagen beheerders vaak vooraf de TTL, wachten lang genoeg tot de vorige TTL is verlopen en passen vervolgens de DNS-instelling aan. Nadat de wijziging stabiel is, kunnen ze de TTL weer verhogen om herhaalde queries te verminderen. De geschikte waarden zijn afhankelijk van de dienst en het wijzigingsproces van de operator.
Waarom duurt het bij DNS-wijzigingen verschillende lang?
De meest voorkomende reden is dat resolvers verschillende gecachte kopieën hebben. Sommigen hebben het record al verfrist, terwijl anderen nog steeds een niet-verlopen antwoord gebruiken. Een resolver kan ook zijn eigen verfrisgedrag toepassen of negatieve antwoorden cachen, wat antwoorden zijn die aangeven dat een record niet bestaat.
Lokaal cachegebruik kan een extra laag toevoegen. Een computer, router, browser of beveiligingsapplicatie kan tijdelijk DNS-informatie bewaren. Het opnieuw starten van een browser of het wissen van de DNS-cache van het besturingssysteem kan in sommige gevallen helpen, maar verandert niet wat een recursieve resolver nog steeds heeft gecached.
Wijzigingen in de DNS-provider kunnen extra timingfactoren introduceren. Als je de autoritatieve naamserver van het domein bij de registrar wijzigt, moeten resolvers mogelijk ook de delegatie-informatie vernieuwen, evenals de records die door die naamserver worden aangeboden. Dit is een andere wijziging dan het bewerken van een A- of AAAA-record binnen dezelfde DNS-hostingservice.
Tot slot kan een update op de autoritatieve bron niet correct zijn. Als het verkeerde record is bewerkt, de wijziging niet is opgeslagen, het domein andere autoritatieve naamserver gebruikt of het record een syntaxisfout bevat, zal wachten de onderliggende configuratie niet oplossen.
DNS-propagatie versus autoritatieve DNS-updates
Een autoritatieve DNS-server biedt de officiële records voor een domein of zone. Wanneer u een record bewerkt in het beheerpaneel van uw DNS-provider, zou de provider de autoritatieve gegevens die hij aanbiedt moeten bijwerken.
Een recursieve resolver biedt DNS-antwoorden aan clientapparaten. Deze kan nog steeds gegevens uit de cache bevatten die vóór de wijziging zijn opgeslagen. Daarom kan de autoritatieve server het nieuwe adres teruggeven, terwijl een recursieve resolver nog steeds het oudere adres retourneert.
Dit onderscheid is nuttig bij het oplossen van problemen. Controleer eerst wat de autoritatieve naamserver返回的结果。如果它们已经返回预期的记录，则更改已在源端发布，剩余差异可能是由于缓存或解析器行为导致的。如果权威服务器仍然返回旧值或无值，请调查DNS提供商的配置和记录本身。
Het wijzigen van nameservers voegt nog een laag toe. De bovenliggende DNS-zone moet verwijzen naar de beoogde autoritatieve nameservers, en die servers moeten de juiste zone bedienen. Een correcte record op een DNS-provider is niet nuttig als het domein is gedelegeerd aan de nameservers van een andere provider.
Veelvoorkomende DNS-wijzigingen en hun effecten
Het wijzigen van een Een record changes the IPv4 address returned for a hostname. Changing an AAAA-record wijzigt zijn IPv6-adres. Als beide aanwezig zijn, kunnen clients afhankelijk van hun netwerk en verbindingsgedrag gebruikmaken van het ene of het andere adresfamilie.
Het wijzigen van een CNAME-record wijzigt de hostnaam waarnaar een alias verwijst. Resolvers moeten mogelijk vervolgens de doelpagina en het adres opzoeken. Een wijziging in de records van het doel kan het eindresultaat beïnvloeden, zelfs als de CNAME zelf ongewijzigd blijft.
Het wijzigen van een MX-record beïnvloedt welke mail servers e-mail voor een domein ontvangen. Mail systemen kunnen deze records cachen, en het kan tijd duren voordat updates in de e-mailrouting zichtbaar worden. Bij het wisselen van mail providers moeten beheerders MX-records en eventuele gerelateerde mailauthenticatierecords, zoals SPF, DKIM of DMARC, apart verifiëren.
Veranderen nameservers wijzigingen aanbrengen in de DNS-provider die autoritair is voor het domein. Dit vereist correcte delegatie bij de registrar en correcte zoneconfiguratie bij de nieuwe provider. Een migratie van nameservers moet zorgvuldig worden gepland, omdat ontbrekende records bij de nieuwe provider ervoor kunnen zorgen dat websites, e-mail of andere diensten niet beschikbaar zijn.
Hoe controleren of een DNS-wijziging is doorgevoerd
Begin met het opvragen van het domein vanaf de computer die u gebruikt. Op Windows, macOS en Linux nslookup is algemeen beschikbaar:
nslookup example.comOm een IPv4-adresrecord te controleren, gebruikt u:
nslookup -type=A example.comVoor IPv6:
nslookup -type=AAAA example.comVoor mail-serverrecords:
nslookup -type=MX example.comOp macOS en Linux, dig biedt gedetailleerdere uitvoer:
dig voorbeeld.nl AOm alleen het antwoordsdeel weer te geven:
dig voorbeeld.nl A +noall +answerU kunt een specifieke recursieve resolver opvragen om antwoorden te vergelijken. Bijvoorbeeld:
dig @1.1.1.1 example.com AOp Windows kunt u een DNS-server opgeven met:
nslookup example.com 1.1.1.1Vervang example.com met uw domein. Het resolveradres in deze voorbeelden is slechts één mogelijke publieke resolver; u kunt ook de DNS-service van uw organisatie of provider raadplegen.
Noteer de resolver die je hebt opgevraagd, het antwoord en de tijd. Het vergelijken van resultaten van meerdere resolvers helpt bepalen of het verschil lokaal is voor één resolver of zich breder voordoet.
Hoe een autoritatieve naamserver te bevragen
Om de autoritatieve nameservers voor een domein te vinden, gebruikt u:
dig example.com NSQuery vervolgens één van die name servers direct voor het record dat je hebt gewijzigd:
dig @ns1.example-dns.com example.com AVervang ns1.example-dns.com met een autoritatieve server die voor uw domein is vermeld. Als de directe query het verwachte adres retourneert, maar een recursieve resolver de oude teruggeeft, zijn de autoritatieve gegevens bijgewerkt en gebruikt de resolver mogelijk nog steeds een gecachet antwoord.
U kunt ook vragen dig om het delegatieproces te traceren:
dig +trace example.comDit volgt de DNS-hiërarchie vanaf de root naar de autoritatieve servers van het domein. Het kan helpen bij het identificeren van delegatieproblemen, hoewel de uitvoer gedetailleerder is dan de meeste basiscontroles vereisen.
Als u het configuratiescherm van een DNS-provider gebruikt, controleer dan of het domein daadwerkelijk is gedelegeerd aan de daar vermelde nameservers. Een record kan correct zijn in het dashboard van één provider, terwijl het publieke domein naar een andere provider verwijst.
Wat als sommige gebruikers de oude website zien?
Controleer eerst of het gezaghebbende A- of AAAA-record de beoogde waarde heeft. Query vervolgens verschillende recursieve resolvers en controleer of ze hetzelfde antwoord teruggeven. Als de gezaghebbende gegevens correct zijn, maar sommige resolvers een ouder adres teruggeven, is caching een waarschijnlijke verklaring.
Controleer vervolgens de lokale configuratie van de gebruiker. Een VPN, DNS-resolver van het bedrijf, beveiligingsproduct, browsercache of lokaal hosts-bestand kan invloed hebben op het adres dat wordt teruggegeven. Vergelijk het resultaat met dat van een ander netwerk, zoals een mobiele verbinding, om te zien of het gedrag verandert.
Controleer ook of zowel de oude als de nieuwe servers reageren. Een migratie kan inconsistent lijken als de oude host nog steeds een gecachte versie serveert of anders doorverwijst. Het DNS-record kan correct zijn, terwijl de oude server nog steeds toegankelijk is voor gebruikers wiens resolver niet is verfrist.
Als het probleem alleen IPv4 of alleen IPv6 beïnvloedt, vergelijk dan A- en AAAA-record apart. Een apparaat kan via IPv6 verbinding maken terwijl een ander gebruikmaakt van IPv4. De ene adresfamilie kan naar de nieuwe server verwijzen, terwijl de andere nog steeds naar de oude verwijst.
Wat als een website niet beschikbaar is na een DNS-wijziging?
Controleer of de autoritatieve naamserver van het domein correct zijn en bereikbaar. Verifieer vervolgens of de relevante records op die servers bestaan. Als u onlangs de naamserver hebt gewijzigd, zorg er dan voor dat de nieuwe DNS-provider alle vereiste records heeft, inclusief website-, e-mail-, verificatie- en servicerecords.
Bevestig dat de doelserver klaar is om verbindingen voor het domein te accepteren. Het bijwerken van DNS verandert alleen waar klanten worden doorverwezen. Het configureert niet de webserver, installeert geen certificaat, opent geen firewallpoort of kopieert geen websitebestanden.
Als DNS het verwachte IP-adres retourneert maar de website nog steeds niet werkt, test dan de server en de applicatie apart. Het probleem kan liggen bij de webserver, firewall, TLS-certificaat, hostingconfiguratie of applicatie. Een DNS-opzoekactie bevestigt alleen naamresolutie; deze bevestigt niet dat de service gezond is.
Voor een algemene routekaart tussen uw apparaat en een bestemming, raadpleeg onze gids voor het gebruik van traceroute om problemen met de netwerkverbinding te diagnosticerenTraceroute en DNS-opzoekopdrachten testen verschillende onderdelen van de verbinding, dus ze zijn nuttig in combinatie bij het terugbrengen van een probleem.
Negatieve caching en resultaten van “Record niet gevonden”
Resolvers kunnen de feitelijke afwezigheid van een record cachen. Dit wordt negatieve caching genoemd. Als een resolver een naam heeft opgevraagd voordat het record werd aangemaakt, kan het tijdelijk blijven doorgaan met het teruggeven van een “niet gevonden”-respons, zelfs nadat het record is toegevoegd.
Negatief cacheën heeft ook een TTL, gebaseerd op informatie in het SOA-record van de zone en resolverregels. Het exacte gedrag kan variëren. Als een nieuw aangemaakt subdomein niet onmiddellijk wordt opgelost, controleer dan eerst de autoritatieve naamserver. Als deze het nieuwe record retourneert, wacht dan tot de negatieve caches verlopen zijn en vergelijk andere resolvers.
Een respons “record niet gevonden” kan ook aangeven dat het record is toegevoegd aan de verkeerde zone, de hostnaam onjuist is ingevoerd of het domein andere autoritatieve nameservers gebruikt. Bevestig de volledige hostnaam, het recordtype en de DNS-provider voordat u ervan uitgaat dat het probleem enkel door propagatievertraging wordt veroorzaakt.
Hoe een DNS-migratie plannen
Voordat u records voor een productiedienst wijzigt, lijst u alle hostnamen op en registreert u de service waarop deze afhankelijk is. Een website kan gebruikmaken van A- en AAAA-records, terwijl e-mail afhankelijk is van MX-, SPF-, DKIM- en DMARC-records. Applicaties kunnen ook afhankelijk zijn van verificatie- of service-discovery-records.
Als de wijziging gepland is, verlaag dan de relevante TTL vooraf en wacht ten minste de vorige TTL-periode voordat je de bestemming wijzigt. Bereid de nieuwe server of provider voor voordat je DNS bijwerkt. Test het waar mogelijk direct en bevestig dat certificaten, firewallregels, applicatie-instellingen en e-maildiensten klaar zijn.
Controleer na de wijziging autoritatieve antwoorden en verschillende recursieve resolvers. Monitor de beschikbaarheid van websites, e-mailbezorging en applicatiefouten. Houd de oude service gedurende de overgangsfase beschikbaar waar dit praktisch haalbaar is, omdat sommige gebruikers deze nog kunnen bereiken terwijl verouderde cache-antwoorden verlopen.
Zodra de nieuwe configuratie stabiel is, herstelt u een geschikte TTL. Het langdurig aanhouden van een zeer lage TTL kan het volume van DNS-query's verhogen zonder veel voordeel te bieden voor een service die zelden verandert.
Veelvoorkomende misverstanden over DNS-propagatie
Een veelvoorkomend misverstand is dat elke DNS-wijziging precies 24 of 48 uur duurt. Er bestaat geen vaste, universele duur. De effectieve vertraging hangt af van eerdere TTL-waarden, resolver-caching, delegatiewijzigingen en de juistheid van de autoritaire configuratie.
Een ander misverstand is dat het wissen van de browsercache de DNS overal bijwerkt. Het kan wel informatie verwijderen die op dat apparaat is opgeslagen, maar het kan de cache van een externe recursieve resolver niet wissen. Op dezelfde manier kan het herstarten van een router de lokale cache wissen, maar verandert dit niets aan de autoritatieve records.
Een derde misverstand is dat een DNS-checker die verschillende antwoorden toont, bewijst dat het domein defect is. Verschillende antwoorden kunnen optreden tijdens een geplande migratie, vooral wanneer resolvers op verschillende tijdstippen gegevens hebben gecached. De belangrijke vraag is of de autoritatieve records correct zijn en of de resterende verschillen consistent zijn met de vorige TTL.
Tot slot configureert DNS-propagatie niet de bestemmingsdienst. Een correct IP-adres kan nog steeds leiden tot een onbeschikbare website als de server, firewall, TLS-certificaat of applicatie niet klaar is.
Veelgestelde vragen over DNS-propagatie
Hoe lang duurt DNS-propagatie?
Er is geen gegarandeerde duur. Sommige wijzigingen zijn snel zichtbaar, terwijl andere inconsistent blijven totdat de gecachte records verlopen zijn. De vorige TTL, het gedrag van de resolver en of de nameservers zijn gewijzigd, hebben allemaal invloed op de timing.
Maak het verlagen van de TTL een verandering direct?
Nee. Het verlagen van een TTL beïnvloedt de toekomstige caching nadat resolvers de nieuwe TTL hebben opgehaald. Resolvers die het oude record al hebben gecached, kunnen dit blijven gebruiken tot de vorige TTL is verlopen.
Waarom tonen DNS-checkers verschillende resultaten?
Ze kunnen verschillende recursieve resolvers bevragen vanuit verschillende locaties. Die resolvers kunnen verschillende cached antwoorden hebben, op verschillende momenten worden ververst of verschillende antwoorden ontvangen als gevolg van geografische DNS-beleidsmaatregelen.
Moet ik de DNS-cache van mijn computer wissen?
Het kan helpen wanneer uw eigen apparaat een oude antwoord heeft gecached. Het verwijdert geen caches die worden bijgehouden door uw internetprovider, bedrijfsresolver of openbare DNS-service.
Waarom lost mijn website wel op, maar wordt deze niet geladen?
DNS kan het juiste adres teruggeven, terwijl de bestemmingsserver of -applicatie een probleem heeft. Controleer de webserver, firewall, TLS-certificaat en hostingconfiguratie apart.
Kunnen wijzigingen in nameservers langer duren dan wijzigingen in records?
Ze kunnen aanvullende delegatie-informatie bevatten bij de registrar en het bovenliggende DNS-domein. De nieuwe provider moet ook een volledige en correcte zone serveren. Verifieer zowel de delegatie als de records op de nieuwe autoritatieve servers.
DNS-wijzigingen kunnen op verschillende momenten zichtbaar worden omdat autoritatieve naamserver en recursieve resolvers aparte rollen hebben, en resolvers antwoorden cachen volgens de TTL-waarden. Een gebruiker kan een oud adres zien terwijl een ander al het nieuwe adres ontvangt.
Om dit te onderzoeken, controleer eerst de autoritatieve naamserver en vergelijk vervolgens antwoorden van verschillende recursieve resolvers. Bevestig het recordtype, de hostnaam, de TTL en de delegatie van de naamserver. Als DNS het verwachte adres retourneert maar de service nog steeds niet beschikbaar is, controleer dan de doelserver en de applicatie als aparte onderdelen van het probleem.
Het begrijpen van caching maakt het plannen en oplossen van problemen met DNS-wijzigingen eenvoudiger. Voor meer basisprincipes van netwerken, ga verder met onze handleidingen naar IP-adressen, standaard gateways, en traceroute.