Wat is een DNS-cache, en hoe lang blijven records erin staan?

Waar wordt een DNS-antwoord eigenlijk gecachet?

Eén opzoeking passeert meerdere caches voordat u iets merkt, en elk daarvan houdt zijn eigen kopie bij voor zijn eigen duur:

• De browser. Chrome, Edge en Firefox houden elk een eigen kleine DNS-cache bij, los van die van het besturingssysteem. Chromes cache is zichtbaar op chrome://net-internals/#dns, en die wissen heeft alleen invloed op die browser, niet op de rest van de machine.
• De stub resolver van het OS. Windows draait de DNS Client-service en cachet antwoorden die u kunt opsommen met ipconfig /displaydns; macOS cachet via mDNSResponder; de meeste Linux-desktops draaien systemd-resolved, een lokale cachende stub resolver die u bevraagt met resolvectl. Dit is een echte cache met zijn eigen TTL-aftelling, niet alleen een kopie van wat de browser heeft.
• De router. De meeste thuisrouters draaien een kleine DNS-forwarder die antwoordt vanuit zijn eigen cache voordat hij een query stroomopwaarts doorstuurt, waarom een router herstarten soms een DNS-probleem oplost dat eigenlijk ergens anders zat.
• De recursieve resolver. De resolver van uw provider, of een openbare, verwerkt de meeste opzoekingen op het internet en houdt de grootste en meest gedeelde cache bij. Zodra hij een antwoord heeft, krijgt elk apparaat dat het vraagt de gecachte kopie totdat die verloopt.

Elke laag staat op zichzelf. Het wissen van de cache op uw laptop doet niets met de cache die uw router of uw provider nog bijhoudt, en het doet niets voor de machine van iemand anders.

Wat is een TTL, en wie respecteert die eigenlijk?

Elk DNS-record draagt een time to live: een getal in seconden, ingesteld door wie de zone beheert, dat een resolver vertelt hoe lang hij het antwoord mag hergebruiken voordat hij opnieuw moet vragen. RFC 1035 definieert het als het interval waarin een record "mag worden gecachet voordat de bron van de informatie opnieuw moet worden geraadpleegd", en een TTL van nul betekent dat het antwoord helemaal nooit mag worden gecachet.

Elke cache in de keten, browser, stub resolver, router, recursieve resolver, hoort dat getal te respecteren, aftellend vanaf het moment dat hij het record voor het eerst ophaalde. In de praktijk hanteren sommige resolvers van providers een eigen ondergrens daarbovenop, vaak een uur of meer, ongeacht wat de zone als TTL opgeeft. Daarom helpt het verlagen van een TTL om een toekomstige wijziging te versnellen bij de meeste resolvers, maar is het geen garantie voor elke resolver.

Wat is negatieve caching, en waarom kan een gloednieuw record blijven ontbreken?

Een resolver cachet niet alleen records die bestaan. Als een query terugkomt met geen dergelijke naam (NXDOMAIN) of zonder een record van het gevraagde type, wordt die mislukking ook gecachet, een gedrag dat negatieve caching heet. RFC 2308 stelt de levensduur van de negatieve cache in vanuit het minimum-veld van het SOA-record, en RFC 9520 maakt het cachen van die mislukking nu verplicht in plaats van optioneel voor een compliant resolver.

Dit is het mechanisme achter een bekend probleem: u maakt een nieuw subdomein, vraagt het een seconde te vroeg op, krijgt NXDOMAIN, en de resolver onthoudt "bestaat niet" voor de lengte van de negatieve TTL van de zone, ook al bestaat het record inmiddels. Windows maakt de twee soorten vermeldingen apart zichtbaar: ipconfig /displaydns toont zowel de positieve antwoorden als de negatieve, en ipconfig /flushdns gooit negatieve cachevermeldingen expliciet weg als onderdeel van het wissen van de cache.

Waarom resolvet een site wel voor u en niet voor iemand anders?

Omdat er geen enkele gedeelde cache is. Twee mensen die twee verschillende resolvers vragen, of dezelfde resolver op twee verschillende momenten, kunnen twee verschillende antwoorden krijgen voor dezelfde naam. De kopie van de ene resolver is misschien nog vers van een opzoeking een uur geleden; de andere heeft de naam misschien nog nooit gezien en haalt de huidige waarde op. Geen van beide heeft ongelijk, ze zitten gewoon op verschillende klokken. Als dit gebeurt vlak nadat u een record heeft gewijzigd, loopt hoe u DNS-propagatie controleert door hoe u meerdere resolvers naast elkaar vergelijkt en leest hoeveel tijd elk nog over heeft.

Hoe leest u de TTL van een record dat nog gecachet is?

Bevraag de naam rechtstreeks en houd de volledige uitvoer aan in plaats van de korte vorm:

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

Het getal voor het recordtype, 847 in dit voorbeeld, is het aantal seconden dat resteert voordat de kopie van die specifieke resolver verloopt; het is niet de oorspronkelijke TTL van het record, die alleen de autoritatieve server met zekerheid kan geven. Voer dezelfde query een paar seconden later opnieuw uit en het getal zal met ongeveer dat aantal seconden zijn gedaald, wat bevestigt dat u een levende aftelling leest in plaats van een statische instelling. Als een naam helemaal niet resolvet in plaats van met een laag getal te resolven, is dat een andere mislukking: hoe u DNS wist behandelt eerst het wissen van uw eigen cache, en wat een DNS-resolver eigenlijk doet behandelt wat er daarna in de keten gebeurt als uw eigen cache niet het probleem is.

Een cache verklaart waarom de ene bezoeker een wijziging meteen ziet en de andere niet; het verklaart geen record dat nergens ooit bijwerkt. Voer een live opzoeking uit met de DNS-querytool om het huidige antwoord te zien vanaf buiten uw eigen netwerk, en als de site bereikbaar moet blijven volgens een schema in plaats van eenmalig gecontroleerd, is dat waar gedistribueerde monitoring vanaf veel controlepunten voor dient. HostTracker monitort al sinds 2004 websites, houdt inmiddels 500.000+ sites in de gaten vanaf 300+ controlepunten in 158 steden, en waarschuwt per e-mail, sms, spraakoproep, Slack, Telegram en meer wanneer een controle faalt, inclusief een controle die een specifiek IP-adres verwacht en het signaleert zodra het antwoord verandert.

Veelgestelde vragen

Maakt een volle DNS-cache mijn computer trager?

Nee. Een DNS-cache is een kleine tabel met namen en adressen, doorgaans hoogstens een paar honderd vermeldingen, en het opzoeken van eentje kost niets meetbaars. Als opzoekingen traag aanvoelen, is de cache zelf niet de oorzaak; een verre of overbelaste resolver is de gebruikelijke.

Lost het wissen van mijn cache dingen op voor andere mensen?

Nee. ipconfig /flushdns, dscacheutil -flushcache en resolvectl flush-caches wissen alleen de cache op de machine waarop u ze uitvoert. Iedereen leest nog steeds vanuit hun eigen browser, hun eigen router en hun eigen resolver, elk op zijn eigen timer.

Is een DNS-cache hetzelfde als een CDN-cache?

Nee, al worden ze verward. Een DNS-cache slaat het antwoord op de vraag "wat is het IP-adres voor deze naam" op. Een CDN-cache slaat de daadwerkelijke pagina- of bestandsinhoud op, op een server dicht bij de bezoeker. De ene wissen heeft geen effect op de andere.

Kan ik mijn eigen TTL instellen als ik het domein niet beheer?

Nee. De TTL is een eigenschap van het record, ingesteld in de autoritatieve zone door wie de DNS van het domein beheert. Als bezoeker heeft u alleen de keuze om een resolver te bevragen die een korte TTL respecteert in plaats van er een die zijn eigen ondergrens afdwingt.

Waarom verandert de TTL die ik zie elke keer dat ik query?

Omdat u een andere resolver vraagt, of dezelfde op een ander moment in zijn aftelling. Bevraag de autoritatieve nameserver rechtstreeks met dig example.com @ns1.yourdns.example om de TTL te zien zoals die oorspronkelijk is ingesteld, zonder dat er al iets is afgeteld.