Du har opdateret din A-record, gemt ændringen i dit DNS-panel og ventet. En time går. To timer. Din hjemmeside peger stadig det forkerte sted hen - og din kollega i et andet postnummer siger, at det virker fint for ham. Det er ikke et tegn på, at noget er galt. Det er DNS propagation i aktion, og det er fuldt normalt.
Forvirringen opstår, fordi de fleste forestiller sig DNS som et enkelt opslag: du ændrer en record, og alle ser det med det samme. Virkeligheden er en distribueret infrastruktur med millioner af caches spredt over hele verden - og de opdateres ikke på kommando.
Hvad DNS propagation egentlig betyder
DNS-systemet er ikke centraliseret. Når en bruger besøger dit domæne, spørger deres computer ikke direkte din autoritative navneserver - den spørger en rekursiv resolver, typisk drevet af deres ISP eller en offentlig resolver som Googles 8.8.8.8. Denne resolver har sandsynligvis allerede cachet svaret fra et tidligere opslag.
Propagation er den tid, det tager for den gamle, cachede information at udløbe og blive erstattet af den nye. Det sker ikke som en aktiv udsendelse - din navneserver råber ikke til verden, at noget har ændret sig. I stedet venter hver cache, til dens kopi af recorden er for gammel til at bruge, og henter så en frisk version. Det er en passiv, decentral proces, og det er præcis derfor, folk oplever forsinkelsen forskelligt.
TTL er den primære årsag til forsinkelse
TTL - Time To Live - er det tal, der i praksis bestemmer, hvor hurtigt din ændring spreder sig. Værdien er angivet i sekunder direkte i din DNS-record og fortæller resolvere, hvor længe de må beholde en cachet kopi af svaret.
En TTL på 86400 betyder, at en resolver juridisk set må cache svaret i op til 24 timer. Selv hvis du ændrer din record med det samme, kan brugere, der allerede har cachet det gamle svar, se den gamle version i op til et døgn. En TTL på 300 giver kun fem minutters cache - ændringen slår hurtigere igennem, men til gengæld genererer dit domæne langt flere opslag mod navneserveren.
De fleste DNS-udbydere sætter en standard-TTL på 3600 sekunder (en time) eller 86400 sekunder (et døgn). Mange glemmer at tjekke værdien, inden de foretager en ændring - og betaler prisen bagefter.
Du kan læse mere om den underliggende mekanisme i artiklen om hvordan DNS cache fungerer.
Typiske propagationstider
Udtrykket "op til 48 timer" er teknisk korrekt, men i praksis er propagation langt hurtigere for de fleste brugere - forudsat at din TTL er fornuftig. Her er, hvad der er realistisk at forvente:
TTL på 300 sekunder (5 min): De fleste brugere ser ændringen inden for 5-15 minutter. Globalt spredt inden for en time.
TTL på 3600 sekunder (1 time): Størstedelen af verden ser ændringen inden for 1-2 timer. Langsomme ISP-caches kan tage op til 4-6 timer.
TTL på 86400 sekunder (24 timer): Teoretisk set kan det tage op til 48 timer. Mange resolvere respekterer ikke altid den fulde TTL, men du bør forvente op til et døgn.
Faktoren, der forlænger propagation udover TTL, er ikke-compliant resolvere - servere der ignorerer TTL og cacher svaret i længere tid end tilladt. Det sker, men er relativt sjældent hos store udbydere.
Hvorfor du og din kollega ser forskellige ting
Det er en af de mest forvirrende oplevelser ved DNS-ændringer: to personer på samme tidspunkt ser to forskellige svar for det samme domæne. Årsagen er simpel - de bruger forskellige resolvere, og de resolvers caches er opdateret på forskellige tidspunkter.
Din kollega i en anden by bruger sin ISPs resolver. Du bruger din. Begge har cachet svaret på forskelligt tidspunkt, og deres caches udløber uafhængigt af hinanden. Derudover kan din egen computer have cachet svaret lokalt - operativsystemets DNS-cache er et lag oven på resolverens cache.
Geografisk placering spiller også en rolle. Navneservere i Europa er fysisk tættere på europæiske resolvere og opdateres hyppigere. En resolver i Sydøstasien kan have en ældre kopi, fordi den sjældnere forespørger dit domæne.
Minimer nedetid ved planlagte ændringer
Den mest effektive strategi er at sænke TTL før du foretager ændringen. Hvis din record i dag har en TTL på 86400, skal du sænke den til 300 eller 600 mindst 24-48 timer inden ændringen - det er den tid, det tager for den lave TTL selv at propagere ud. Herefter kan du lave din ændring med tillid til, at caches udløber hurtigt.
En struktureret tilgang til planlagte ændringer ser typisk sådan ud:
48 timer før: Sænk TTL på de records, du skal ændre, til 300-600 sekunder. Vent til den nye TTL er propageret ud.
På ændringstidspunktet: Foretag ændringen. Med den lave TTL slår den igennem hurtigt for de fleste brugere.
Efter ændringen er bekræftet: Sæt TTL tilbage til en normal værdi (1800-3600 sekunder) for at reducere unødvendige opslag.
Denne teknik bruges konsekvent ved større migrationer - fx når et domæne skifter hosting eller en MX-record ændres til en ny mailserver. Det er forskellen på en migration med nedetid og en uden.
Ryd din lokale DNS-cache
Selvom propagation er komplet globalt, kan din egen computer stadig vise det gamle svar. Operativsystemet cacher DNS-svar lokalt, og den cache opdateres ikke automatisk, bare fordi du genstarter browseren. Du skal rydde den manuelt.
Windows:
ipconfig /flushdnsmacOS (Ventura og nyere):
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderLinux (systemd-resolved):
sudo systemd-resolve --flush-cachesHusk også, at din browser kan have sin egen DNS-cache. I Chrome og Edge kan du rydde den via chrome://net-internals/#dns.
Tjek om din ændring er slået igennem globalt
Når du har foretaget en ændring, er det naturligt at ville bekræfte, at den er synlig fra andre steder end din egen computer. DNSinfos DNS opslag forespørger din records aktuelle svar direkte fra navneserveren - uden at gå igennem en lokal cache. Det giver dig et hurtigt billede af, hvad verden ser.
Vær opmærksom på, at et positivt svar fra ét opslag ikke garanterer global propagation. Resolvere i andre regioner kan stadig have cachet det gamle svar. Ønsker du at verificere status på dine navneservere specifikt, kan navneserver-statusværktøjet give et hurtigt overblik over, om dine NS-records svarer korrekt.
Hvornår er det ikke propagation, der er problemet?
Propagation er den hyppigste forklaring på forsinkede DNS-ændringer - men ikke den eneste. Hvis din ændring ikke slår igennem, selv efter TTL er udløbet, bør du undersøge disse alternativer:
Fejl i selve recorden: En forkert IP-adresse, et manglende punktum i et CNAME-felt eller en syntaksfejl i en TXT-record giver et svar, der er teknisk gyldigt men funktionelt forkert. Tjek recordens indhold nøje - ikke blot om den eksisterer.
Forkert zone eller forkert domæne: Det sker hyppigere end man tror: ændringen er lavet i den forkerte DNS-zone, på et subdomain frem for roddomænet, eller hos en DNS-udbyder, der ikke længere er autoritativ for domænet.
Cached fejlsvar (NXDOMAIN): Hvis din record midlertidigt ikke-eksisterede og en resolver cachede et NXDOMAIN-svar, kan det også have en TTL. Resolveren svarer "domænet findes ikke" i den cachede periode, selvom recorden nu er oprettet.
Forkerte navneservere på domænet: Hvis domænets registrering peger på en anden navneserver end den, du redigerer i, har dine ændringer ingen effekt. Verificer hvilke navneservere der er registreret via et Whois opslag.
En grundig gennemgang af de mest almindelige DNS-recordtyper kan hjælpe dig med at identificere, om problemet ligger i recordens format frem for i propagation.
Forberedelse er den eneste kontrol du har
DNS propagation er ikke en fejl - det er en konsekvens af det distribuerede caching-system, der gør DNS hurtigt og skalerbart for milliarder af brugere. Du kan ikke fremskynde andres caches. Men du kan sikre, at din TTL er lav nok til, at ændringen spreder sig hurtigt, og at du har verificeret recordens korrekthed, inden du foretager ændringen.
Med en TTL sænket til 300 sekunder i forvejen, en korrekt record og en ryddet lokal cache er der ingen grund til at sidde og vente i blinde. DNS-ændringer behøver ikke koste nedetid - de kræver blot en smule planlægning.
