DNS-utbredning

Protokoll och standarder
Tiden det tar för DNS-ändringar att slå igenom på alla DNS-servrar världen över.
← Tillbaka till Ordlistan

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ärdePropagationstidAnvändningsområde
60s1-2 minuterAktiva flyttar, lastbalansering
300s (5 min)5-10 minuterProduktionsändringar, rimligt standardvärde
3600s (1 timme)1-2 timmarStabil infrastruktur
86400s (24 timmar)24-48 timmarPoster 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 Problematiska resolvers: Vissa internetleverantörer

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:

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-ändringen
example.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 klar

Vanliga 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 timmar

Byta namnservrar

Förväntad tid: 24-48 timmar
Why 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 cachelagring
If 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 namnservern
dig @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 cacher

Propagation 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

BegreppVad det ärVaraktighet
TTLHur länge en post får cachelagrasAnges av domänägaren
PropagationTid tills alla cacher har löpt utCirka 2 × TTL
TTL för namnserverHur länge NS-poster cachelagrasOfta 24-48 timmar (registret)
Negativ cacheHur länge NXDOMAIN cachelagrasSOA: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.

Använd Denna Kunskap

Använd DomScans API för att kontrollera domäntillgänglighet, hälsa och mer.