Je maakt een nieuw subdomein aan. De beheeromgeving toont het record, een collega kan de site bereiken, maar je computer meldt nog steeds NXDOMAIN. Is de wijziging mislukt? Niet per se. Een resolver kan ook onthouden dat een naam eerder niet bestond. Dit opgeslagen negatieve antwoord is een toestand op zich.
De DNS-troubleshootinghandleiding van Cloudflare, bijgewerkt op 21 oktober 2026, beschrijft precies dit geval. Het gaat om een actuele technische uitleg, niet om de lancering van een nieuw DNS-product. Het onderscheid is de moeite waard, omdat achter het alledaagse woord “cache” verschillende, totaal uiteenlopende opslagplaatsen schuilgaan: DNS-antwoorden, browserinhoud en gecachte webbestanden.
Het eerdere niet-bestaan kan nog opgeslagen zijn
Een recursieve resolver zoekt de naam namens jou op. Als die eerder een negatief antwoord heeft ontvangen, kan hij dat antwoord een beperkte tijd hergebruiken. Wordt het record intussen op de gezaghebbende nameserver aangemaakt, dan merkt de resolver dat niet noodzakelijk op hetzelfde moment.
De nieuwe TTL van het A-record dat je zojuist hebt aangemaakt, verkort deze bestaande negatieve toestand niet met terugwerkende kracht. Voor negative caching speelt de SOA-informatie van de zone een rol. RFC2308 beschrijft de beginwaarde als de kleinste van de SOA-TTL en SOA.MINIMUM. De tijd die voor een opgeslagen antwoord daadwerkelijk resteert, is weer iets anders.
Ons eigen rekenvoorbeeld gebruikt alleen verzonnen getallen: een negatieve vermelding kan aanvankelijk 300 seconden geldig zijn. Na 120 seconden wordt het echte DNS-record aangemaakt. Een resolver zou dan nog 180 seconden van zijn oude antwoord over kunnen hebben. Dit illustreert de tijdsrelatie; het is geen gemeten duur voor Cloudflare of je domein.
Twee alleen-lezen-query's scheiden bron en cache
De eerste vraag is: wat zegt de verantwoordelijke gezaghebbende nameserver? De tweede: wat zegt de recursieve resolver die je apparaat daadwerkelijk gebruikt? Verschillende antwoorden kunnen de fout afbakenen. Ze bewijzen niet automatisch negative caching; ook typefouten of een onjuiste delegatie moeten worden uitgesloten.
dig @YOUR-AUTHORITATIVE-NAMESERVER neu.example.com A
dig @YOUR-RECURSIVE-RESOLVER neu.example.com A
dig @YOUR-RECURSIVE-RESOLVER neu.example.com A +noall +authorityVervang de placeholders door de servers die je daadwerkelijk hebt vastgesteld. De commando's zijn alleen-lezen-sjablonen en zijn hier niet uitgevoerd. Bekijk de responscode, naam, recordtype en, indien aanwezig, SOA-gegevens samen. Een antwoord voor een host met een vergelijkbare spelling zou geen geschikte vergelijking zijn.
Noteer ook het tijdstip en de gebruikte resolver. Anders vergelijk je mogelijk ongemerkt verschillende paden. Het legen van de lokale DNS-cache verwijdert niet automatisch het opgeslagen antwoord van een upstream resolver. Juist daarom kan het herstarten van de browser de toestand die je waarneemt missen.
DNS en CDN beantwoorden verschillende vragen
DNS helpt een naam om te zetten. Een CDN-cache houdt daarentegen bepaalde HTTP-inhoud gereed. Het legen van gecachte afbeeldingen of stylesheets vertelt een DNS-resolver niet dat een eerder onbekende naam nu bestaat. De maatregel past dan simpelweg niet bij de laag waar het probleem ligt.
De aan-de-slaghandleiding van Cloudflare voor Cache, voor het laatst bijgewerkt op 12 oktober 2026, beschrijft ook het verschil tussen proxied en DNS-only: inhoud van een DNS-only host gaat niet door de Cloudflare-cache alleen omdat de DNS daar wordt beheerd. Een bestaand DNS-record is daarom geen bewijs dat inhoud actief wordt gecachet.
Van DomainStudio naar het daadwerkelijke antwoord
In KENJTEC DomainStudio aikun je je eigen DNS-records beheren met type, doel en TTL. De geïmplementeerde route gebruikt Cloudflare voor het zonebeheer. Na een wijziging moet je de resolutie nog steeds beoordelen aan de hand van de daadwerkelijke DNS-antwoorden; “opgeslagen” en “al zichtbaar bij elke resolver” zijn verschillende uitspraken.
Wachttijden kunnen daarom niet worden vervangen door een algemene belofte van succes. Controleer eerst de spelling, de verantwoordelijke nameservers en het gezaghebbende antwoord. Pas daarna is de resterende cachetijd een bruikbare verklaring. Zo wordt “DNS heeft gewoon tijd nodig” een navolgbare diagnose waarin elke waarneming bij de juiste technische laag hoort.
Bronnen en status
Onderzoek en documentatie per 25 oktober 2026. Algemene DNS-problemen · Aan de slag met Cache · RFC2308 — Negative Caching of DNS Queries.
