DNS-posten är sparad men ger ändå NXDOMAIN: varför DNS-cache och CDN inte är samma sak

Du skapar en ny underdomän. Administrationsgränssnittet visar posten, en kollega kan nå webbplatsen, men din dator rapporterar fortfarande NXDOMAIN. Har ändringen misslyckats? Inte nödvändigtvis. En resolver kan också komma ihåg att ett namn tidigare inte fanns. Detta lagrade negativa svar är ett eget tillstånd.

Cloudflares felsökningsguide för DNS, uppdaterad den 21 oktober 2026, beskriver exakt detta fall. Det är en aktuell teknisk förklaring, inte lanseringen av en ny DNS-produkt. Distinktionen är värd att göra eftersom flera helt olika lager försvinner under vardagsordet ”cache”: DNS-svar, webbläsarinnehåll och cachade webbfiler.

Den tidigare icke-existensen kan fortfarande vara lagrad

En rekursiv resolver slår upp namnet åt dig. Om den tidigare har fått ett negativt svar kan den återanvända det svaret under en begränsad tid. Om posten under tiden skapas på den auktoritativa namnservern får resolvern inte nödvändigtvis veta det i samma ögonblick.

Den nya TTL:en för A-posten du just har skapat förkortar inte i efterhand detta befintliga negativa tillstånd. För negativ cachning spelar zonens SOA-information en roll. RFC2308 beskriver startvärdet som det mindre av SOA-TTL och SOA.MINIMUM. Den tid som faktiskt återstår för ett lagrat svar är återigen något annat.

Vårt eget räkneexempel använder bara påhittade siffror: en negativ post kan inledningsvis vara giltig i 300 sekunder. Efter 120 sekunder skapas den riktiga DNS-posten. En resolver kan då fortfarande ha 180 sekunder kvar av sitt gamla svar. Detta illustrerar tidsförhållandet; det är ingen uppmätt varaktighet för Cloudflare eller din domän.

Två skrivskyddade förfrågningar skiljer källa och cache åt

Den första frågan är: vad säger den ansvariga auktoritativa namnservern? Den andra: vad säger den rekursiva resolver som din enhet faktiskt använder? Olika svar kan hjälpa till att ringa in felet. De bevisar inte automatiskt negativ cachning; även stavfel eller felaktig delegering måste uteslutas.

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 +authority

Ersätt platshållarna med de servrar du faktiskt har identifierat. Kommandona är skrivskyddade mallar och kördes inte här. Titta på svarskod, namn, posttyp och, där sådana finns, SOA-uppgifter tillsammans. Ett svar för en värd med liknande stavning vore ingen lämplig jämförelse.

Notera också tidpunkten och vilken resolver som användes. Annars kanske du jämför olika vägar utan att märka det. Att rensa den lokala DNS-cachen tar inte automatiskt bort det lagrade svaret hos en resolver längre upp i kedjan. Just därför kan en omstart av webbläsaren missa det tillstånd du observerar.

DNS och CDN besvarar olika frågor

DNS hjälper till att slå upp ett namn. En CDN-cache håller däremot visst HTTP-innehåll redo. Att rensa cachade bilder eller stilmallar talar inte om för en DNS-resolver att ett tidigare okänt namn nu finns. Åtgärden passar då helt enkelt inte det lager där problemet ligger.

Cloudflares kom igång-guide för Cache, senast uppdaterad den 12 oktober 2026, beskriver också skillnaden mellan proxied och DNS-only: innehåll från en DNS-only-värd passerar inte genom Cloudflares cache bara för att dess DNS hanteras där. En befintlig DNS-post är därför inget bevis för att innehåll aktivt cachas.

Från DomainStudio till det faktiska svaret

I KENJTEC DomainStudio aikan du hantera dina egna DNS-poster med typ, mål och TTL. Den implementerade lösningen använder Cloudflare för zonhanteringen. Efter en ändring bör du ändå bedöma namnuppslagningen utifrån de faktiska DNS-svaren; ”sparad” och ”redan synlig hos varje resolver” är olika påståenden.

Väntetider kan därför inte ersättas av ett generellt löfte om framgång. Kontrollera först stavningen, de ansvariga namnservrarna och det auktoritativa svaret. Först därefter är den återstående cachetiden en användbar förklaring. Så blir ”DNS tar bara tid” en spårbar diagnos där varje observation hör till rätt tekniskt lager.

Källor och status

Research och dokumentation per den 25 oktober 2026. Allmänna DNS-problem · Kom igång med Cache · RFC2308 — Negativ cachning av DNS-förfrågningar.