"Propagering": hvorfor noen ser endringen med en gang og andre ikke

Modul 6: Tid, cache og flytting · Lesetid: 8 minutter

Læringsmål: Etter denne leksjonen kan du forklare hvorfor en DNS-endring ikke er synlig overalt samtidig, anslå hvor lang tid det tar, og løse problemet hvis det bare er du som fortsatt ser den gamle situasjonen.

Nøkkelbegreper: "propagering", cache, negativ cache (NXDOMAIN), SOA-minimum, delegerings-TTL, navnetjenerendring, tømme cache

En misforståelse i ett ord

Du har endret en post. Kollegaen din ser allerede den nye nettsiden, du ser fortsatt den gamle. På internett leser du da: "bare vent, DNS må fortsatt propageres." Ordet propagering (spredning) gir inntrykk av at endringen din ruller som en bølge over internett, fra server til server.

Slik fungerer det ikke. Endringen din ligger med en gang på de autoritative navnetjenerne til domenet ditt (eller innen noen minutter, hvis DNS-leverandøren din synkroniserer flere navnetjenere). Det blir ikke sendt noe rundt. Det du ser, er at cacher utløper: hver resolver gir det gamle svaret til TTL-en i cachen er brukt opp (leksjon 6.1). Siden hver resolver begynte å telle på et annet tidspunkt, ser noen endringen før andre.

"Propagering" betyr altså egentlig: å vente til alle cacher har tømt seg. Den innsikten hjelper deg, for nå vet du nøyaktig hva du venter på og hvor lenge maksimalt.

Hvor lang tid tar det?

Det avhenger av hva du endrer.

Eksisterende poster

Her er det enkelt: den gamle TTL-en er maksimum. Hadde posten TTL 3600, ser alle det nye svaret senest en time etter endringen din. Ser noen fortsatt det gamle etter mer enn en time, ligger problemet et annet sted (se nedenfor).

Nye poster og den negative cachen

En ny post fungerer ofte med en gang, unntatt hvis noen allerede spurte etter navnet mens det ennå ikke eksisterte. Resolveren fikk da svaret NXDOMAIN ("dette navnet eksisterer ikke") eller "dette navnet eksisterer, men har ingen post av denne typen". Også det "nei-et" blir husket. Det kalles den negative cachen.

Hvor lenge et "nei" blir lagret, står ikke i en post som ikke eksisterer. Det kommer fra SOA-posten til sonen: ifølge RFC 2308 er det det minste av to tall, TTL-en til selve SOA-posten og det siste feltet i SOA-posten ("minimum"). Et eksempel:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026110701 ; serienummer
                             14400      ; refresh
                             3600       ; retry
                             1209600    ; expire
                             300 )      ; minimum

Her blir et "nei" husket i maksimalt 300 sekunder (det minste av 3600 og 300). I enkelte soner er det en time eller mer.

Derfor gjelder gyllenregelen: ikke åpne et nytt underdomene i nettleseren din før du har opprettet det. Datamaskinen din og resolveren din husker da at det ikke eksisterer, og du er den eneste som må vente.

Endre navnetjenere

Ved en navnetjenerendring venter du på noe annet: NS-postene hos registry for ditt toppdomene. Disse postene forteller resolvere hvor navnetjenerne til domenet ditt befinner seg (leksjon 2.1), og også de blir husket. Hver registry velger sin egen TTL for dette. Målt i november 2026:

I tillegg kommer at en registry noen ganger ikke publiserer endringen din med en gang, og at navnetjenerne til den gamle leverandøren din i mellomtiden ofte fortsatt svarer med den gamle sonen. Regn derfor med noen timer ved et navnetjenerbytte, og ved .com maksimalt to dager. Sørg derfor for at begge leverandørene har de samme, riktige postene under byttet (leksjon 6.3).

Er du den eneste som fortsatt ser det gamle?

Ser en nettbasert kontroll allerede det nye svaret hos nesten alle resolvere, men ikke du? Da ligger det gamle svaret et sted nær deg. Gå gjennom disse trinnene, fra raskt til grundig:

1. Privat vindu eller en annen nettleser. Nettleseren din lagrer DNS-svar og sider.
2. Telefon via 4G eller 5G, med wifi avslått. Da bruker du resolveren til mobiloperatøren din i stedet for hjemmenettverket ditt.

3. Tøm cachen på datamaskinen din.

   • Windows (ledetekst): ipconfig /flushdns
   • macOS (Terminal): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux med systemd-resolved: resolvectl flush-caches
4. Start ruteren på nytt. Mange rutere fungerer som en liten resolver med sin egen cache.
5. Kontroller hosts-filen. Har du tidligere testet en ny server ved å legge inn adressen i hosts-filen din (C:\Windows\System32\drivers\etc\hosts eller /etc/hosts)? Den linjen går foran DNS. Fjern den. Dette blir ofte glemt.
6. Sjekk direkte ved kilden. Spør etter posten hos den autoritative navnetjeneren (dig A example.com @ns1.hosting.example). Står det fortsatt det gamle svaret der, er endringen ikke lagret riktig eller du har gjort den på feil sted.

Fortsatt ingenting etter ventetiden?

Hvis TTL-en for lengst har gått ut og også nettbaserte verktøy viser det gamle svaret, er det nytteløst å vente. Da er det noe annet som er galt. De tre vanligste årsakene:

• Endret på feil sted. Domenet ditt bruker navnetjenerne til en annen leverandør (for eksempel Cloudflare eller en nettstedbygger), og du endret postene hos hostingleverandøren din. Sjekk hvilke navnetjenere domenet ditt har (leksjon 2.1) og gjør endringen der.
• Skrivefeil eller manglende punktum. mail.example.com uten punktum blir i mange kontrollpaneler til mail.example.com.example.com (leksjon 2.2).
• Navnetjenerne er ikke enige med hverandre. Et domene har minst to navnetjenere. Hvis de ikke synkroniserer skikkelig, gir den ene det nye svaret og den andre det gamle. Sammenlign SOA-serienummeret hos hver navnetjener: det skal være likt.

dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.example

I praksis: slik ser det ut i et kontrollpanel

Vil du se hva resolvere på ulike steder i verden svarer, kan du bruke en nettbasert DNS-sjekker som spør en resolver per land (for eksempel dnschecker.org). I eksempelpanelet Min side sjekker kortet Domain / Email tilstanden navnetjenerne og postene til domenet ditt hos de autoritative navnetjenerne, og DNS-diagnosen sammenligner serienumrene til navnetjenerne. Andre leverandører har ofte en lignende sjekk i panelet sitt; hvis ikke, gir dig og de nettbaserte verktøyene fra leksjon 8.3 samme bilde.

Oppsummering

• Det blir ikke "spredt" noe: du venter til cacher utløper.
• En endret post er senest synlig overalt etter den gamle TTL-en; en ny post er som regel synlig med en gang, med mindre noen allerede har spurt etter navnet (negativ cache, bestemt av SOA-posten).
• Et navnetjenerbytte avhenger av TTL-en hos registry: hos .nl en time, hos .com to dager.
• Er du den eneste som fortsatt ser det gamle? Privat vindu, 4G, tøm cache, start ruteren på nytt og sjekk hosts-filen.
• Fortsatt gammelt svar hos den autoritative navnetjeneren? Da er det nytteløst å vente: finn feilen.

Quiz

Oppgave

Oppgave Z6.2: Delegerings-TTL og negativ cache. To spørsmål, begge kan besvares med dig eller et nettbasert dig-verktøy:

1. Hvor mange sekunder husker resolvere, ifølge .com-registry, navnetjenerne til google.com? Spør en .com-server: dig NS google.com @a.gtld-servers.net og se på TTL-en i AUTHORITY-delen.
2. Hvor mange sekunder husker en resolver at et navn under sidn.nl ikke eksisterer? Spør etter SOA-posten til sidn.nl (nettstedet til SIDN, registry for .nl i Nederland) hos ns1.sidn.nl og bruk regelen fra denne leksjonen (den minste av SOA-TTL-en og SOA-minimumet).

Les mer

Trinnene i disse artiklene gjelder kontrollpanelene til WebOké; i andre kontrollpaneler fungerer det på lignende måte.

• Hvor lenge tar en nameserver- eller DNS-endring, og hva om du ikke ser den?
• Nettsiden eller e-posten fungerer ikke etter en flytting eller DNS-endring: sjekk domenet ditt
• DirectAdmin-veiledning 5.11: Når gjelder en endring? Ventetid og TTL
• Opprette et underdomene, og hva du skal gjøre hvis det ikke fungerer
• Hvordan kan jeg teste domenet mitt før det er flyttet? (localhost)
• WebOké-veiledning 5.17: Domene og e-posthelse: kontroller og reparer