Du opretter et nyt subdomæne. Administrationsgrænsefladen viser posten, en kollega kan nå siden, men din computer melder stadig NXDOMAIN. Er ændringen mislykkedes? Ikke nødvendigvis. En resolver kan også huske, at et navn ikke fandtes før. Dette gemte negative svar er en selvstændig tilstand.
Cloudflares fejlfindingsvejledning til DNS, opdateret den 21. oktober 2026, beskriver netop dette tilfælde. Det er en aktuel teknisk forklaring, ikke lanceringen af et nyt DNS-produkt. Sondringen er værd at foretage, fordi flere helt forskellige lagre forsvinder under hverdagsordet »cache«: DNS-svar, browserindhold og cachelagrede webfiler.
Den tidligere ikke-eksistens kan stadig være gemt
En rekursiv resolver slår navnet op på dine vegne. Hvis den tidligere har modtaget et negativt svar, kan den genbruge dette svar i et begrænset tidsrum. Hvis posten i mellemtiden oprettes på den autoritative navneserver, får resolveren det ikke nødvendigvis at vide i samme øjeblik.
Den nye TTL for den A-post, du lige har oprettet, forkorter ikke med tilbagevirkende kraft denne eksisterende negative tilstand. For negativ caching spiller zonens SOA-oplysninger en rolle. RFC2308 beskriver startværdien som den mindste af SOA TTL og SOA.MINIMUM. Den tid, der faktisk er tilbage for et gemt svar, er igen noget andet.
Vores eget gennemregnede eksempel bruger kun opdigtede tal: en negativ post kan i begyndelsen være gyldig i 300 sekunder. Efter 120 sekunder oprettes den rigtige DNS-post. En resolver kunne så stadig have 180 sekunder tilbage af sit gamle svar. Det illustrerer tidsforholdet; det er ikke en målt varighed for Cloudflare eller dit domæne.
To rene læseforespørgsler adskiller kilde og cache
Det første spørgsmål er: hvad siger den ansvarlige autoritative navneserver? Det andet: hvad siger den rekursive resolver, som din enhed faktisk bruger? Forskellige svar kan indkredse fejlen. De beviser ikke automatisk negativ caching; tastefejl eller forkert delegering skal også udelukkes.
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 +authorityErstat pladsholderne med de servere, du faktisk har identificeret. Kommandoerne er skabeloner, der kun læser, og er ikke blevet kørt her. Se samlet på svarkode, navn, posttype og, hvis de findes, SOA-detaljer. Et svar for en vært med lignende stavemåde ville ikke være en egnet sammenligning.
Notér også tidspunktet og den anvendte resolver. Ellers sammenligner du måske forskellige veje uden at bemærke det. At rydde den lokale DNS-cache fjerner ikke automatisk det gemte svar hos en resolver længere oppe i kæden. Netop derfor kan en genstart af browseren ramme ved siden af den tilstand, du observerer.
DNS og CDN besvarer forskellige spørgsmål
DNS hjælper med at opløse et navn. En CDN-cache holder derimod bestemt HTTP-indhold klar. At tømme cachelagrede billeder eller stylesheets fortæller ikke en DNS-resolver, at et tidligere ukendt navn nu findes. Tiltaget passer så simpelthen ikke til det lag, hvor problemet ligger.
Cloudflares kom-i-gang-vejledning til Cache, senest opdateret den 12. oktober 2026, beskriver også forskellen mellem proxied og DNS-only: Indhold fra en DNS-only-vært passerer ikke gennem Cloudflare-cachen, blot fordi dens DNS administreres dér. En eksisterende DNS-post er derfor ikke bevis for, at indhold aktivt caches.
Fra DomainStudio til det faktiske svar
I KENJTEC DomainStudio aikan du administrere dine egne DNS-poster med type, mål og TTL. Den implementerede rute bruger Cloudflare til zoneadministration. Efter en ændring bør du stadig vurdere opløsningen ud fra de faktiske DNS-svar; »gemt« og »allerede synlig hos alle resolvere« er forskellige udsagn.
Ventetider kan derfor ikke erstattes af et generelt løfte om succes. Kontrollér først stavemåden, de ansvarlige navneservere og det autoritative svar. Først derefter er den resterende cachetid en brugbar forklaring. Det gør »DNS tager bare tid« til en sporbar diagnose, hvor hver observation hører til det rette tekniske lag.
Kilder og status
Research og dokumentation pr. 25. oktober 2026. Generelle DNS-problemer · Kom i gang med Cache · RFC2308 — Negativ caching af DNS-forespørgsler.
