Negativ caching: Hvorfor feilen henger igjen

En DNS-feil som «henger igjen» etter at du har rettet den, skyldes ofte negativ caching. Du har fikset posten hos navneserveren din, men oppløsere rundt om i verden fortsetter å servere det gamle feilsvaret fra cachen sin. Her er hvordan det virker, og hvordan du planlegger endringer så rettelsen din faktisk når fram.

TL;DR: DNS (Domain Name System) oversetter domenenavn til IP-adresser, og en oppløser er serveren som gjør oppslaget for deg. Negativ caching betyr at oppløseren lagrer feilsvar midlertidig og svarer fra cachen til TTL-en (Time to Live, altså levetiden til et cachet svar) er utløpt. Senk TTL-en i forkant av endringer, så forplanter rettelsene seg raskt.

Hva er negativ caching?

Negativ caching er lagring av DNS-svar som forteller at et oppslag ikke ga noe gyldig svar. Reglene er definert i RFC 2308, publisert i 1998, og formålet er å spare båndbredde og skåne navneservere for unødvendige oppslag. Uten negativ caching ville hvert eneste oppslag av et navn som ikke finnes, ha nådd helt fram til den autoritative navneserveren.

Kort definisjon: negativ caching er at en DNS-oppløser midlertidig lagrer et negativt svar, for eksempel at domenenavnet ikke finnes. Svaret blir stående i cachen i et tidsrom som bestemmes av TTL-en, og nye oppslag besvares fra cachen uten at oppløseren spør autoritative navneservere på nytt. Hos Feno kan du se og endre TTL-en på hver enkelt post i kontrollpanelet.

NXDOMAIN og SERVFAIL

Det finnes to vanlige typer negative svar. NXDOMAIN (Nonexistent Domain) betyr at domenenavnet ikke finnes, for eksempel fordi en peker i oppsettet ditt refererer til et navn som aldri ble opprettet. SERVFAIL (Server Failure) betyr at navneserveren ikke klarte å svare, for eksempel fordi DNSSEC-valideringen (kryptografisk verifisering av DNS-svar) mislyktes.

Begge typene blir lagret i cachen som negative svar. Derfor kan en skrivefeil i en peker, eller et kortvarig problem hos navneserveren din, bli servert videre til besøkende lenge etter at selve problemet er borte.

Hvorfor feilen henger igjen

En cache har ingen måte å vite at et svar er utdatert eller feil. Når du retter en DNS-post hos deg, fortsetter oppløsere som allerede har lagret det negative svaret, å levere det til TTL-en utløper. Derfor kan du selv se riktig svar, mens en besøkende hos en annen internettleverandør fortsatt får feilmelding.

TTL og SOA MINIMUM

For vanlige svar bestemmer TTL-en hvor lenge oppløseren beholder svaret. For negative svar er regelen litt annerledes: TTL-en settes ut fra SOA-posten (Start of Authority), posten som beskriver hvilken server som er autoritativ kilde for sonen. RFC 2308 sier at den negative TTL-en er den laveste av SOA-postenes TTL og MINIMUM-feltet.

Sonen din ligger alltid hos domeneregistraren din, uansett hvem du bruker, og SOA-posten er en del av denne sonen. Det betyr at du kan påvirke hvor lenge negative svar varer ved å justere verdiene i SOA-posten.

Oppløsere setter et tak

Store oppløsere kapper negative svar uansett hva sonen din sier. Mange bruker et tak på 3600 sekunder, altså én time. Den praktiske konsekvensen er at selv om du setter MINIMUM-feltet til 300 sekunder, kan en oppløser likevel beholde svaret i opptil én time. Du bør aldri regne med at en rettet feil forsvinner umiddelbart.

Hvordan unngå at feilen henger igjen

Hemmeligheten er å senke TTL-en i god tid før du gjør endringer. Da er det lite igjen i cachene når den nye informasjonen kommer. Framgangsmåten ser slik ut:

1. Senk TTL-en på postene du skal endre, gjerne til 300 sekunder, minst 24 timer før du rører selve innholdet.
2. Vent ut den gamle TTL-en, slik at gamle svar rekker å utløpe hos oppløserne.
3. Gjør selve endringen, for eksempel oppdaterer en A-post, som er adresseposten som peker på IP-adressen til serveren din.
4. Verifiser mot den autoritative navneserveren direkte med dig eller nslookup, så du ikke tester mot en cache.
5. Sett TTL-en tilbake til et normalt nivå når alt fungerer som det skal.

Noen ekstra tips når du mistenker at en feil bare er cachet:

• Sammenlign svaret fra en vanlig oppløser med svaret fra den autoritative navneserveren. Er de forskjellige, er svaret cachet.
• Tøm cachen lokalt med ipconfig /flushdns på Windows eller sudo dscacheutil -flushcache på macOS.
• Husk at du aldri kan tømme cachen hos andre. Lave TTL-er i forkant og tålmodighet er det eneste som hjelper.

Vanlige spørsmål og svar

Hvorfor ser jeg fortsatt feilen etter at jeg har rettet DNS-en?

Fordi oppløseren svarer fra cachen sin. Det negative svaret står der til TTL-en er utløpt, og først da spør oppløseren den autoritative navneserveren på nytt.

Hvor lenge varer negativ caching?

Vanligvis mellom noen minutter og én time. Den negative TTL-en bestemmes av SOA-posten i sonen, men mange oppløsere kapper svaret på 3600 sekunder.

Kan jeg tømme negativ cache hos andre?

Nei. Du har bare kontroll over cachen på din egen maskin og dine egne servere. For besøkende hos andre internettleverandører er det lave TTL-er i forkant av endringen som gjør at feilen forsvinner raskest.

Konklusjon

Negativ caching er både en styrke og en fallgruve i DNS. Det gjør oppslag raske og skåner infrastrukturen, men det betyr også at en rettet feil kan leve videre i cacher i opptil en time eller mer. Forstår du hvordan TTL-en og SOA-posten virker sammen, kan du planlegge endringer uten overraskelser.

Har du kontroll på DNS-oppsettet ditt? Registrer ditt .no-domene hos Feno og få oversikt over poster, TTL-er og DNSSEC i ett moderne kontrollpanel. Norske domener fortjener norsk eierskap.