DNS-propagering forklart – TTL, cache og ventetid

Du endrer en DNS-post, men får fortsatt den gamle nettsiden. En kollega ser den nye, mens du ikke gjør det. Eller domenet virker på mobilnett, men ikke fra kontoret. Dette kalles ofte DNS-propagering, men navnet gir et litt feil bilde av hva som skjer.

DNS-endringen blir ikke sendt fra server til server over hele verden. Den lagres én gang hos domenets autoritative navnetjenere. Deretter henter ulike DNS-resolvere det nye svaret når deres lagrede kopi utløper. Forskjellen mellom gammel og ny cache forklarer det meste av ventetiden.

Kort svar: Hvor lang tid tar DNS-propagering?

En vanlig DNS-post kan bli synlig med en gang for noen og først etter gammel TTL for andre. Har den gamle posten en TTL på 3600 sekunder, kan en resolver som nettopp hentet den gamle verdien normalt bruke den i opptil én time. Et navnetjenerbytte følger flere cacheledd og kan ta lengre tid.

Det finnes derfor ingen universell regel om at alle DNS-endringer tar 24 eller 48 timer.

Den riktige ventetiden kan være fem minutter, én time eller lenger. Den kan også være null: Hvis en autoritativ navnetjener svarer feil, blir ikke feilen riktig av å vente.

Hva betyr DNS-propagering egentlig?

Når du besøker et domene, spør enheten din vanligvis en rekursiv DNS-resolver om adressen. Resolveren kan drives av internettleverandøren, arbeidsgiveren eller en offentlig tjeneste som Cloudflare eller Google.

Har resolveren et gyldig svar i cache, bruker den dette uten å spørre domenets navnetjenere på nytt. Hvis svaret mangler eller har utløpt, følger resolveren DNS-hierarkiet frem til domenets autoritative navnetjener og lagrer svaret for en begrenset periode.

En DNS-endring skjer altså i to deler:

1. Den nye verdien må være riktig på alle autoritative navnetjenere.
2. Resolvere som har lagret den gamle verdien, må hente på nytt når cachen utløper.

Det første er publisering. Det andre er cache. Når de blandes sammen, er det lett å vente på en feil som egentlig burde vært rettet.

TTL bestemmer hvor lenge et svar kan lagres

TTL betyr Time to Live og oppgis i sekunder. TTL følger DNS-svaret og forteller hvor lenge en resolver kan bruke den lagrede kopien før den normalt må spørre kilden på nytt. Dette er definert i DNS-standarden for caching av utløpte svar .

Eksempel:

• A-posten har TTL 3600 sekunder.
• En resolver henter gammel IP-adresse klokken 10.40.
• Du endrer posten klokken 11.00.
• Den resolveren kan normalt fortsette å svare med gammel IP-adresse frem til klokken 11.40.
• En annen resolver uten cache kan hente den nye adressen allerede klokken 11.00.

Det er gammel TTL som er viktig. Senker du TTL fra 3600 til 300 samtidig som du endrer IP-adressen, kan resolverne allerede ha lagret den gamle posten med én times levetid. Den nye, korte TTL-en gjelder først når de henter den nye versjonen.

TTL-en du ser i et oppslag er ofte gjenværende tid i den aktuelle resolverens cache. Tallet teller ned. Når den henter svaret på nytt, starter TTL-en igjen fra verdien den autoritative navnetjeneren oppgir.

En ny post kan også bli forsinket av negativ cache

DNS cacher ikke bare eksisterende poster. Et svar om at et navn eller en bestemt posttype ikke finnes, kan også lagres. Dette kalles negativ caching og er definert i RFC 2308 .

Tenk deg at noen spør etter butikk.eksempel.no før du har opprettet posten. Resolveren får NXDOMAIN og cacher svaret. Du oppretter posten to minutter senere, men den samme resolveren kan fortsatt svare at navnet ikke finnes frem til den negative cachen utløper.

To vanlige negative svar er:

• NXDOMAIN: navnet finnes ikke.
• NODATA: navnet finnes, men ikke med den etterspurte posttypen.

Levetiden på slike svar bestemmes av SOA-posten i sonen, ikke TTL-en på den nye posten du nettopp opprettet. Også midlertidige oppslagsfeil kan caches kort for å unngå at resolverne overbelaster DNS-systemet med nye forsøk, slik RFC 9520 beskriver.

Dette forklarer hvorfor «det finnes ingen post» kan henge igjen selv om den autoritative DNS-sonen nå er riktig.

Navnetjenerbytte er ikke det samme som å endre en DNS-post

Når du endrer en A-post hos samme DNS-leverandør, er det postens TTL som normalt styrer cachetiden. Ved et navnetjenerbytte endrer du i stedet domenets delegering i den overordnede sonen, for eksempel .no.

Da må du skille mellom:

• navnetjenerne som står registrert for domenet
• NS-delegeringen som resolverne har cachet
• DNS-postene som gamle og nye navnetjenere svarer med
• eventuelle DS-poster som knytter domenet til DNSSEC

En lav TTL på A-posten gjør ikke nødvendigvis en cachet NS-delegering kortere. Derfor bør gamle og nye navnetjenere gi samme svar i en overgangsperiode. Se den komplette planen for å endre navnetjenere uten unødvendig nedetid .

Har domenet DNSSEC, kan en DS-post som ikke passer med DNSKEY hos de nye navnetjenerne gi SERVFAIL. Dette er en valideringsfeil, ikke vanlig propagering. Les hvordan DNSSEC aktiveres og testes før et leverandørbytte.

Slik undersøker du om du skal vente eller rette en feil

Ikke start med en global DNS-sjekker. Finn først ut hvilket lag som viser feil.

1. Finn navnetjenerne som faktisk er delegert

dig eksempel.no NS
dig +trace eksempel.no NS

Det første oppslaget kan bruke resolverens cache. +trace følger delegeringen fra rotsonen og nedover og er nyttig når du må kontrollere hva overordnet sone peker til. Sammenlign resultatet med navnetjenerne du forventer.

2. Spør hver autoritative navnetjener direkte

dig @ns1.leverandor.no eksempel.no A
dig @ns2.leverandor.no eksempel.no A
dig @ns1.leverandor.no eksempel.no MX

Bytt ut navnene med domenets faktiske navnetjenere. Se etter svaret i ANSWER SECTION, og kontroller at kommandolinjen viser aa blant flaggene. aa betyr at svaret er autoritativt.

Hvis navnetjenerne gir ulike svar, er sonen ikke konsekvent publisert. Da hjelper det ikke å vente på resolvernes cache før den autoritative feilen er rettet.

3. Sammenlign rekursive resolvere

dig @1.1.1.1 eksempel.no A
dig @8.8.8.8 eksempel.no A
dig @9.9.9.9 eksempel.no A

Hvis alle autoritative navnetjenere viser den nye verdien, mens rekursive resolvere viser en blanding av gammel og ny verdi, er normal cache en sannsynlig forklaring. Noter TTL-en i svarene og test igjen etter at den gjenværende tiden har gått.

Hvis alle resolverne viser samme feil, må du kontrollere den autoritative sonen, delegeringen og DNSSEC i stedet for å anta propagering. Bruk gjerne den mer detaljerte guiden for å bekrefte navnetjenerendringer .

4. Test tjenesten, ikke bare DNS-posten

Et riktig DNS-svar beviser bare at oppslaget virker. Kontroller også at:

• webserveren svarer på riktig vertsnavn og har gyldig TLS-sertifikat
• både domenet med og uten www går til forventet sted
• MX-postene peker riktig og e-postleverandøren kjenner domenet
• SPF, DKIM og DMARC er med etter en e-postflytting
• gamle og nye miljøer kan håndtere trafikk i overgangsperioden

En nettsidefeil etter et vellykket DNS-oppslag er ofte en server-, sertifikat- eller konfigurasjonsfeil. Det er ikke DNS-propagering.

Hvorfor globale DNS-sjekkere viser forskjellige prikker

Nettbaserte DNS-sjekkere spør et utvalg resolvere fra forskjellige steder. Grønne og røde prikker kan være nyttige, men de viser ikke «hele internett» og er ikke et bevis på at en endring sprer seg geografisk.

Ulike svar kan skyldes at resolverne:

• hentet den gamle posten på forskjellige tidspunkter
• har ulik negativ cache
• bruker forskjellige veier til autoritative navnetjenere
• fortsatt har en gammel delegering lagret
• håndterer et midlertidig autoritativt problem forskjellig

Test derfor den autoritative kilden først. Deretter kan en global sjekk vise hvorvidt cachede svar fortsatt varierer.

TTL-utløp garanterer ikke alltid et nytt svar

Normalt henter en resolver et nytt svar etter TTL. Noen resolvere kan likevel servere et utløpt, kjent svar midlertidig hvis de autoritative navnetjenerne ikke kan nås. Dette kalles serve stale og brukes for å holde tjenester tilgjengelige under korte DNS-problemer.

Det betyr at en gammel verdi etter TTL ikke automatisk beviser at resolveren ignorerer standarden. Kontroller om de autoritative navnetjenerne svarer stabilt. Hvis de er utilgjengelige, er riktig tiltak å rette tilgjengeligheten, ikke å fortsette å vente.

Når bør du vente?

Det er rimelig å vente når:

• alle autoritative navnetjenere svarer med samme nye verdi
• delegeringen peker til de navnetjenerne du forventer
• DNSSEC validerer uten feil
• noen rekursive resolvere viser nytt svar og andre viser gammelt
• gammel verdi har en gjenværende TTL som teller ned
• både gammelt og nytt tjenestemiljø fungerer i overgangsperioden

Da kan du følge med til den tidligere TTL-en og eventuell negativ cache er utløpt.

Når bør du rette feilen med en gang?

Ikke bruk «vent opptil 48 timer» som standardsvar hvis:

• autoritative navnetjenere gir forskjellige svar
• overordnet sone peker til feil navnetjenere
• oppslag gir SERVFAIL eller DNSSEC-validering feiler
• den nye DNS-sonen mangler MX- eller andre nødvendige poster
• en CNAME kolliderer med andre poster på samme navn
• du har gjort endringen hos en leverandør som ikke er autoritativ
• alle testede resolvere konsekvent henter samme gale verdi

Gå systematisk gjennom vanlige DNS-feil og hvordan de rettes i stedet for å la en reell konfigurasjonsfeil stå urørt.

Planlegg DNS-endringen før du flytter

Ved en planlagt flytting kan du redusere tiden resolverne beholder den gamle posten:

1. Finn TTL-en som gjelder nå.
2. Senk TTL, for eksempel til 300 sekunder, minst én gammel TTL-periode før endringen.
3. Vent til tidligere cache kan være utløpt.
4. Kontroller at det nye miljøet er klart før du endrer posten.
5. La gammelt og nytt miljø fungere parallelt mens cachede svar varierer.
6. Test autoritative servere, rekursive resolvere og selve tjenesten.
7. Øk TTL igjen når endringen er stabil.

Cloudflare beskriver hvordan lavere TTL kan hjelpe ved planlagte DNS-endringer , og Google anbefaler samme prinsipp før bytte av hosting uten URL-endringer .

Lav TTL er likevel ikke en universell hurtigknapp. Den må settes før den gamle cachen oppstår, og postens TTL styrer ikke nødvendigvis delegering, negativ cache eller DNSSEC. Se hvordan dere velger og endrer TTL for et mer varig oppsett.

Hjelper det å tømme lokal DNS-cache?

Å tømme cache på egen enhet kan hjelpe hvis operativsystemet eller nettleseren sitter på et gammelt svar. Det påvirker ikke cachen hos internettleverandøren, en offentlig resolver eller andre brukere.

Test først på mobilnett eller mot en bestemt resolver. Får du riktig svar der, men ikke lokalt, kan du følge guiden for å tømme DNS-cache på enheten . Får også eksterne resolvere feil svar, må du lete lenger opp i DNS-kjeden.

En bedre regel enn «vent 48 timer»

DNS-propagering er ikke en diffus prosess du bare må håpe blir ferdig. Still tre konkrete spørsmål:

1. Er delegeringen riktig? Overordnet sone må vise de forventede navnetjenerne.
2. Er kilden riktig? Alle autoritative navnetjenere må svare likt.
3. Er forskjellen bare cache? Rekursive svar kan variere frem til gammel TTL eller negativ cache utløper.

Hvis svaret er ja på alle tre, er venting normalt. Hvis ett av dem er nei, har du funnet stedet som må undersøkes. Det gjør DNS-endringer langt mer forutsigbare enn å følge en generell klokke.