"Spridning": varför vissa redan ser den och andra inte

Modul 6: Tid, cache och flytt · Lästid: 8 minuter

Lärandemål: Efter den här lektionen kan du förklara varför en DNS-ändring inte syns överallt samtidigt, uppskatta hur lång tid det tar och lösa problemet om det bara är du som fortfarande ser den gamla situationen.

Nyckelbegrepp: "spridning" (propagering), cache, negativ cache (NXDOMAIN), SOA-minimum, delegerings-TTL, namnserverbyte, rensa cache

Ett missförstånd i ett ord

Du har ändrat en post. Din kollega ser redan den nya webbplatsen, du ser fortfarande den gamla. På internet läser du då: "vänta bara, DNS:en måste spridas." Ordet spridning (propagering) ger intrycket att din ändring rullar som en våg över internet, från server till server.

Så fungerar det inte. Din ändring finns direkt på domänens auktoritativa namnservrar (eller inom några minuter, om din DNS-leverantör synkroniserar flera namnservrar). Inget skickas runt. Det du ser är cacheminnen som håller på att gå ut: varje resolver ger det gamla svaret tills TTL:en i dess cache tar slut (lektion 6.1). Eftersom varje resolver började räkna vid olika tidpunkter ser vissa ändringen tidigare än andra.

"Spridning" betyder alltså egentligen: att vänta tills alla cacheminnen har tömts. Den insikten hjälper dig, för nu vet du precis vad du väntar på och hur länge som mest.

Hur lång tid tar det?

Det beror på vad du ändrar.

Befintliga poster

Här är det enkelt: den gamla TTL:en är maximum. Hade posten TTL 3600, ser alla det nya svaret senast en timme efter din ändring. Ser någon fortfarande det gamla efter mer än en timme, ligger problemet någon annanstans (se nedan).

Nya poster och den negativa cachen

En ny post fungerar oftast direkt, förutom om någon redan efterfrågade namnet innan det fanns. Resolvern fick då svaret NXDOMAIN ("det här namnet finns inte") eller "det här namnet finns, men har ingen post av den här typen". Även det "nej" kommas ihåg. Det kallas den negativa cachen.

Hur länge ett "nej" sparas står inte i en post som inte finns. Det kommer från zonens SOA-post: enligt RFC 2308 är det det minsta av två tal, TTL:en för själva SOA-posten och det sista fältet i SOA-posten (det så kallade "minimumet"). Ett exempel:

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

Här kommas ett "nej" ihåg i högst 300 sekunder (det minsta av 3600 och 300). För vissa zoner är det en timme eller mer.

Därför den gyllene regeln: öppna inte en ny subdomän i din webbläsare innan du har skapat den. Din dator och din resolver kommer då ihåg att den inte finns, och du är den enda som behöver vänta.

Byta namnservrar

Vid ett namnserverbyte väntar du på något annat: NS-posterna hos registryn för din toppdomän. De posterna talar om för resolvers var namnservrarna för din domän finns (lektion 2.1), och även de kommas ihåg. Varje registry väljer en egen TTL för det. Uppmätt i november 2026:

Dessutom publicerar en registry ibland inte din ändring direkt, och under tiden svarar namnservrarna hos din gamla leverantör ofta fortfarande med den gamla zonen. Räkna därför med några timmar vid ett namnserverbyte, och vid .com med upp till två dagar. Se därför till att båda parter har samma, korrekta poster under bytet (lektion 6.3).

Är du den enda som fortfarande ser det gamla?

Visar en onlinekontroll redan det nya svaret hos nästan alla resolvers, men inte hos dig? Då finns det gamla svaret i din närhet. Gå igenom de här stegen, från snabbt till grundligt:

1. Privat fönster eller en annan webbläsare. Din webbläsare sparar DNS-svar och sidor.
2. Telefon via 4G eller 5G, med wifi avstängt. Då använder du din mobiloperatörs resolver i stället för hemnätverkets.

3. Rensa cachen på din dator.

   • Windows (Kommandotolken): ipconfig /flushdns
   • macOS (Terminal): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux med systemd-resolved: resolvectl flush-caches
4. Starta om routern. Många routrar fungerar som en liten resolver med en egen cache.
5. Kontrollera hosts-filen. Har du tidigare testat en ny server genom att lägga in adressen i din hosts-fil (C:\Windows\System32\drivers\etc\hosts eller /etc/hosts)? Den raden går före DNS:en. Ta bort den. Det här glöms ofta bort.
6. Kolla direkt vid källan. Fråga efter posten hos den auktoritativa namnservern (dig A example.com @ns1.hosting.example). Står det fortfarande det gamla svaret där, är ändringen inte sparad korrekt eller har du gjort den på fel ställe.

Fortfarande inget efter väntetiden?

Om TTL:en för länge sedan löpt ut och även onlineverktyg visar det gamla svaret, är det meningslöst att vänta. Då är det något annat som är fel. De tre vanligaste orsakerna:

• Ändrat på fel ställe. Din domän använder namnservrarna hos en annan leverantör (till exempel Cloudflare eller en webbplatsbyggare), och du ändrade posterna hos din hostingleverantör. Kolla vilka namnservrar din domän har (lektion 2.1) och gör ändringen där.
• Felstavning eller saknad punkt. mail.example.com utan punkt blir i många paneler mail.example.com.example.com (lektion 2.2).
• Namnservrarna är inte överens sinsemellan. En domän har minst två namnservrar. Om de inte synkroniserar ordentligt, ger den ena det nya och den andra det gamla svaret. Jämför SOA-serienumret hos varje namnserver: det måste vara likadant.

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

I praktiken: så här ser det ut i en panel

Vill du se vad resolvers på olika platser i världen svarar, använd en onlinebaserad DNS-kontroll som frågar en resolver per land (till exempel dnschecker.org). I exempelpanelen Mitt WebOké kontrollerar kortet Domän / E-post hälsa domänens namnservrar och poster hos de auktoritativa namnservrarna, och DNS-diagnosen jämför namnservrarnas serienummer. Andra leverantörer har ofta en liknande kontroll i sin panel; om inte, ger dig och onlineverktygen från lektion 8.3 samma bild.

Sammanfattning

• Inget "sprids": du väntar tills cacheminnen går ut.
• En ändrad post syns överallt senast efter den gamla TTL:en; en ny post oftast direkt, om inte någon redan frågat efter namnet tidigare (negativ cache, bestäms av SOA-posten).
• Ett namnserverbyte beror på TTL:en hos registryn: hos .nl en timme, hos .com två dagar.
• Är du den enda som fortfarande ser det gamla? Privat fönster, 4G, rensa cache, starta om routern och kontrollera hosts-filen.
• Fortfarande gammalt hos den auktoritativa namnservern? Då är det meningslöst att vänta: leta upp felet.

Quiz

Uppgift

Uppgift Z6.2: Delegerings-TTL och negativ cache. Två frågor, båda kan besvaras med dig eller ett online dig-verktyg:

1. Hur många sekunder kommer resolvers enligt .com-registryn ihåg namnservrarna för google.com? Fråga en .com-server: dig NS google.com @a.gtld-servers.net och titta på TTL:en i AUTHORITY-delen.
2. Hur många sekunder kommer en resolver ihåg att ett namn under sidn.nl inte finns? Fråga efter SOA-posten för sidn.nl hos ns1.sidn.nl och tillämpa regeln från den här lektionen (det minsta av SOA-TTL:en och SOA-minimumet).

Läs mer

Stegen i de här artiklarna handlar om panelerna hos WebOké; i andra paneler fungerar det på ett liknande sätt.

• Hur lång tid tar en ändring av nameserver eller DNS, och vad gör du om du inte ser den?
• Webbplatsen eller e-posten fungerar inte efter en flytt eller DNS-ändring: kontrollera din domän
• DirectAdmin-guide 5.11: När börjar en ändring gälla? Väntetid och TTL
• Skapa ett underdomän, och vad du ska göra om det inte fungerar
• Hur kan jag testa min domän innan den har flyttats? (localhost)
• WebOké manual 5.17: Domän och e-posthälsa: kontrollera och åtgärda