Vad är DNS-propagation?
DNS-propagation syftar på den tid det tar innan ändringar i DNS-poster känns igen över hela internet. När du uppdaterar DNS-poster, till exempel genom att byta namnservrar, uppdatera A-poster eller ändra MX-poster, börjar ändringarna inte gälla direkt. De måste slå igenom i det hierarkiska DNS-systemet när cacheposter löper ut och hämtas på nytt.
Förstå "propagation"
Begreppet "propagation" är något missvisande, eftersom DNS-ändringar inte aktivt sprids. I stället:
1. Du uppdaterar posterna hos din auktoritativa namnserver
2. Cachade kopior löper ut utifrån TTL (Time To Live)
3. Nya frågor hämtar uppdaterade poster från auktoritativa servrar
4. Gamla cachade kopior fortsätter att användas tills TTL löper ut
Det är mer korrekt att säga "DNS-cacheutgång" än "propagation", men begreppet propagation används allmänt.
Så fungerar DNS-ändringar
Uppdateringsprocessen
Step 1: Update DNS records
example.com A record: 203.0.113.50 → 203.0.113.51
Step 2: Authoritative nameserver immediately serves new record
Step 3: Existing cached copies remain valid until TTL expires
Step 4: New queries after TTL expiration receive updated record
Step 5: All caches eventually expire and refresh
→ "Propagation complete"
Exempel på tidslinje
Time: 10:00 - DNS updated (TTL: 300s / 5 minutes)
Resolver A (cached at 09:58):
09:58 - Cached old IP, expires 10:03
10:03 - Cache expires, queries again, gets new IP
Resolver B (cached at 10:01):
10:01 - Cached old IP, expires 10:06
10:06 - Cache expires, queries again, gets new IP
Resolver C (queries at 10:05):
10:05 - No cache, queries immediately, gets new IP
All resolvers have new IP by: 10:06
Propagation time: 6 minutes (worst case based on TTL)
Faktorer som påverkar propagationstiden
TTL (livslängd)
Den enskilt viktigaste faktorn:
| TTL-värde | Propagationstid | Användningsområde |
|---|---|---|
| 60s | 1-2 minuter | Aktiva flyttar, lastbalansering |
| 300s (5 min) | 5-10 minuter | Produktionsändringar, rimligt standardvärde |
| 3600s (1 timme) | 1-2 timmar | Stabil infrastruktur |
| 86400s (24 timmar) | 24-48 timmar | Poster som sällan ändras |
Ändringar av namnservrar
Att byta namnservrar tar längre tid än andra DNS-ändringar:
Registry Level: 24-48 hours (TLD nameserver cache)
Resolver Level: Based on NS record TTL
Total Time: Up to 48 hours worst case
ISP:ers och resolvers beteende
Alla DNS-resolvers respekterar inte TTL-värden:
Respektfulla resolvers: Google (8.8.8.8), Cloudflare (1.1.1.1), OpenDNS- Respekterar TTL strikt
- Snabb propagation
- Kan ignorera låga TTL-värden
- Cachelagrar längre än angivet
- Kan fördröja propagation med flera timmar
Geografisk spridning
Olika regioner uppdateras vid olika tidpunkter beroende på lokal resolver-cache:
North America: 10:05 - Updated
Europe: 10:08 - Updated
Asia: 10:12 - Updated
Cachelagring på klientsidan
Även efter att DNS-servrarna har uppdaterats kan lokala cacher behålla gamla värden:
- Webbläsarcache: Vanligtvis 60 sekunder
- Operativsystemets cache: Från minuter till timmar
- Applikationscache: Varierar mellan applikationer
Kontrollera DNS-propagation
Onlineverktyg för propagation
whatsmydns.net: Visar DNS-upplösning från över 20 platser världen över dnschecker.org: Kontrollerar A-, AAAA-, CNAME-, MX- och TXT-poster globalt DomScans hälsokontroll:curl "https://domscan.net/v1/health?domain=example.com"
# Shows current DNS configuration
Kontroller från kommandoraden
Kontrollera flera resolvers:# Google DNS
dig @8.8.8.8 example.com
# Cloudflare DNS
dig @1.1.1.1 example.com
# Your ISP (no @ server specified)
dig example.com
# Compare results
Fråga den auktoritativa namnservern direkt:
# Find nameservers
dig example.com NS
# Query authoritative NS directly
dig @ns1.example.com example.com
Detta visar "sanningen" omedelbart, utan cache.
Kontrollera från flera platser
# Using curl with DNS over HTTPS
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
Minimera propagationstiden
Innan du gör ändringar
Steg 1: Sänk TTL (24-48 timmar före ändringen)Old: example.com. 3600 IN A 203.0.113.50
New: example.com. 300 IN A 203.0.113.50
^^^
Reduced to 5 minutes
Steg 2: Vänta tills den gamla TTL:en löper ut
Vänta hela den gamla TTL:ens varaktighet (3600 sekunder = 1 timme)
Steg 3: Gör DNS-ändringenexample.com. 300 IN A 203.0.113.51
Steg 4: Övervaka propagation
Kontrollera resolvers globalt
Steg 5: Återställ TTL (efter att du bekräftat att allt fungerar)example.com. 3600 IN A 203.0.113.51
Under ändringar
Använd Anycast DNS: Leverantörer som Cloudflare använder anycast-nätverk som uppdateras nästan omedelbart i hela sitt globala nätverk Övervaka kontinuerligt: Följ propagation i viktiga regioner och hos viktiga resolvers Ha en återställningsplan: Håll den gamla infrastrukturen igång tills propagation är klarVanliga propagationsscenarier
Ändra en A-post
Förväntad tid: 5-30 minuter (utifrån TTL)# Before
example.com → 203.0.113.50
# After
example.com → 203.0.113.51
# Propagation: 1x TTL duration
Ändra en MX-post
Förväntad tid: 5-30 minuter (utifrån TTL) Risk: E-post kan levereras till den gamla servern under propagation Åtgärd: Håll den gamla e-postservern aktiv i 24-48 timmarByta namnservrar
Förväntad tid: 24-48 timmarWhy so long?
- TLD registry caches NS records
- Registry TTL often 24-48 hours
- No control over registry cache
Bästa praxis: Konfigurera alla poster på de nya namnservrarna innan du byter
Lägga till en ny underdomän
Förväntad tid: Omedelbart till 1 timme Fallgrop: Negativ cachelagringIf subdomain was queried and didn't exist:
→ NXDOMAIN cached (SOA minimum TTL)
→ New subdomain won't resolve until cache expires
Åtgärd: Sänk SOA:s minsta TTL innan du lägger till nya poster
Felsöka propagationsproblem
Ändringen slår inte igenom
Kontroll 1: Verifiera den auktoritativa namnserverndig @ns1.example.com example.com
# Should show new value
Kontroll 2: Verifiera TTL
dig example.com | grep -i ttl
Kontroll 3: Kontrollera SOA för negativ cache
dig example.com SOA
# Look at minimum TTL field
Kontroll 4: Töm den lokala cachen
Rensa webbläsarens, operativsystemets och applikationernas cacher
Partiell propagation
Symtom: Vissa användare ser nya poster, andra ser gamla Orsak: Olika resolvers cachelagrade posterna vid olika tidpunkter Lösning: Vänta så länge som den maximala TTL:en anger och töm sedan klienternas cacherPropagation har fastnat
Symtom: Vissa resolvers visar gamla poster även efter flera dagar Orsak: En ISP-resolver ignorerar TTL eller är felkonfigurerad Lösning:1. Verifiera att den auktoritativa namnservern är korrekt
2. Kontakta internetleverantören om problemet kvarstår
3. Användare kan byta till offentlig DNS (8.8.8.8, 1.1.1.1)
DNS-propagation jämfört med cache-TTL
| Begrepp | Vad det är | Varaktighet |
|---|---|---|
| TTL | Hur länge en post får cachelagras | Anges av domänägaren |
| Propagation | Tid tills alla cacher har löpt ut | Cirka 2 × TTL |
| TTL för namnserver | Hur länge NS-poster cachelagras | Ofta 24-48 timmar (registret) |
| Negativ cache | Hur länge NXDOMAIN cachelagras | SOA:s minsta TTL |
Bästa praxis
1. Sänk TTL före ändringar: Minska TTL 24-48 timmar före DNS-uppdateringar
2. Använd lämpliga TTL-värden: Balansera prestanda (hög TTL) mot flexibilitet (låg TTL)
3. Övervaka globalt: Kontrollera DNS från flera geografiska regioner
4. Håll gamla tjänster igång: Behåll tidigare servrar tills propagation är klar
5. Dokumentera ändringar: Notera vad som ändrades och när för felsökning
6. Testa noggrant: Verifiera att nya DNS-poster fungerar före bytet
7. Informera användare: Varna för möjliga korta avbrott
8. Använd hanterad DNS: Leverantörer med anycast-nätverk minimerar propagationstiden
9. Automatisera övervakningen: Skapa aviseringar för DNS-ändringar och propagation
10. Ha en återställningsplan: Veta hur ändringar återställs om problem uppstår
Checklista för propagation
☐ Lower TTL 24-48 hours before change
☐ Wait for old TTL to expire
☐ Make DNS change
☐ Verify on authoritative nameservers
☐ Check multiple public resolvers
☐ Test from multiple geographic locations
☐ Monitor for 2x TTL duration
☐ Verify no errors reported
☐ Restore higher TTL if desired
☐ Document change completion
DNS-propagation är en naturlig följd av DNS-cachelagring. Genom att förstå TTL-beteende och planera ändringar därefter kan du få smidiga och förutsägbara uppdateringar med minimala störningar.