DNS-propagering är tiden från att du ändrar en DNS-post till att alla ser det nya värdet. Ingenting skickas egentligen ut: resolvrar runt om på internet fortsätter att svara med den kopia de har cachat tills dess TTL (time to live) har gått ut, och frågar sedan igen. De flesta ändringar av poster syns överallt inom den gamla postens TTL, ofta inom några minuter till en timme. Byte av namnservrar hos registraren kan ta upp till två dygn. För att se hur långt en ändring har kommit frågar du först domänens egna namnservrar vad de publicerar, och sedan några publika resolvrar vad de fortfarande har i cachen.
Vad som händer när du ändrar en post
En besökares webbläsare frågar inte din DNS-leverantör direkt. Frågan passerar flera cachar, och var och en kan svara ur minnet:
Webbläsaren sparar nyliga svar en kort stund.
Operativsystemet har en egen resolvercache.
En rekursiv resolver hos internetleverantören, i företagets nätverk eller en publik tjänst som 1.1.1.1 eller 8.8.8.8 cachar varje svar så länge dess TTL tillåter.
De auktoritativa namnservrarna för din domän har de riktiga posterna. Till en början är det bara de som känner till din ändring.
När du sparar en ändring hos din DNS-leverantör börjar de auktoritativa namnservrarna oftast svara med den inom några sekunder eller minuter. Varje cache längre ned behåller det gamla svaret tills dess kopia går ut. Två besökare i olika nätverk kan därför se olika servrar ett tag, och det är normalt, inte ett fel. TTL sätter du själv per post, i sekunder. Ordlistans artikel om DNS-propagering har den korta versionen.
Hur lång tid DNS-propagering tar
Vanliga poster: den gamla TTL:en
För en A-, AAAA-, CNAME-, MX- eller TXT-post är den längsta väntetiden den TTL som den gamla posten hade när resolvrarna cachade den. En post med TTL 3600 kan serveras från cache i upp till en timme efter att du ändrat den. Att sänka TTL:en i samma ögonblick som du gör ändringen hjälper inte, eftersom resolvrar som redan har den gamla kopian behåller den under den gamla TTL:en.
Byte av namnservrar: föräldrazonen
Att flytta en domän till en annan DNS-leverantör innebär att du ändrar dess NS-poster hos registraren. De publiceras i föräldrazonen, till exempel .com, och det är föräldrazonen som sätter deras TTL, inte du. Du kan se det själv genom att fråga en .com-server direkt:
dig +norecurse @a.gtld-servers.net example.com NS
Svaret listar namnservrarna med en TTL på 172800 sekunder, alltså 48 timmar. Det är därifrån rådet om ”upp till 48 timmar” kommer. Under den tiden frågar vissa resolvrar den gamla leverantören och andra den nya, så båda måste servera samma poster tills ändringen har satt sig.
Nya namn: negativ cachning
Om någon slog upp ett namn innan det fanns, till exempel en ny subdomän som du testade för tidigt, kan resolvrarna cacha även svaret ”namnet finns inte”. RFC 2308 anger hur länge: det lägsta av SOA-postens minimum-fält och SOA-postens egen TTL. Därför kan en helt ny subdomän visa DNS_PROBE_FINISHED_NXDOMAIN ett tag i ett nätverk men fungera i ett annat.
Program som håller fast vid adresser
Ett program som körs länge, till exempel en applikationsserver eller en proxy, kan slå upp ett värdnamn en gång när det startar och behålla adressen tills det startas om, oavsett vad TTL:en säger. Om en tjänst fortfarande pratar med den gamla servern när allt annat har flyttat, starta om den innan du misstänker DNS.
Så kontrollerar du DNS-propagering
Arbeta från källan och utåt. Bekräfta först att ändringen är publicerad och se sedan vilka cachar som fortfarande har det gamla svaret.
1. Hitta de auktoritativa namnservrarna
dig NS example.com +short
Om det inte är namnservrarna hos leverantören där du gjorde ändringen har du redigerat fel zon. Det är en vanlig anledning till att en ändring ”aldrig propagerar”.
2. Fråga varje namnserver direkt
dig @ns1.example-dns.com example.com A +short
dig @ns1.example-dns.com example.com SOA +short
Upprepa för varje namnserver i listan. Alla ska svara med det nya värdet och samma SOA-serienummer, det tredje fältet i SOA-svaret. En server med ett äldre serienummer har inte fått uppdateringen ännu. Det är propagering inom din leverantör, och den brukar vara klar inom några minuter.
3. Fråga publika resolvrar
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
Utan +short visar kommandot dig TTL:en i varje svar. Från en resolver är den siffran den tid som återstår för den cachade kopian: ett gammalt värde med 1200 sekunder kvar ersätts inom 20 minuter. I Windows frågar nslookup -type=A example.com 1.1.1.1 en specifik resolver, men utan TTL. Vår kostnadsfria DNS-uppslagning visar svaren och TTL:erna för alla posttyper från vår servers resolver i Stockholm, utan att du behöver installera något.
4. Följ delegeringen efter ett byte av namnservrar
dig +trace example.com
+trace börjar i rotzonen och följer hänvisningarna ned till dina namnservrar, utan att använda några cachar på vägen. Om spårningen slutar hos den nya leverantören är ändringen hos registraren aktiv, och det som återstår är att cacharna hinner ikapp.
Planera en ändring så att propageringen inte märks
Du kan inte snabba på propageringen efter en ändring, men du kan göra den kort innan du börjar. Vid en flytt till en ny server:
NärStegMinst en gammal TTL föreSänk postens TTL, till exempel från 3600 till 300 sekunder.Före ändringenSätt upp den nya servern och testa den, till exempel med en rad i hosts-filen eller curl –resolve.ÄndringenPeka posten mot den nya servern och kontrollera det auktoritativa svaret.Under propageringenLåt den gamla servern vara igång och servera samma innehåll. En del besökare når den fortfarande.Ungefär ett dygn senareHöj TTL:en igen och stäng av den gamla servern.
Vid ett byte av namnservrar kopierar du först alla poster till den nya leverantören och jämför de två zonerna post för post, MX och TXT inräknade. En bortglömd TXT-post förstör e-postautentiseringen. SPF-, DKIM- och DMARC-kontrollen visar om den fortfarande godkänns. Om domänen använder DNSSEC följer du den nya leverantörens instruktioner för DS-posten hos registraren, eftersom en DS-post som inte matchar de nya namnservrarna får validerande resolvrar att svara SERVFAIL.
Rensa cachar som du styr över
Du kan rensa dina egna cachar för att se det nya värdet snabbare, vilket hjälper när du testar. För dina besökare ändrar det ingenting.
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows: ipconfig /flushdns
Chrome: öppna chrome://net-internals/#dns och rensa värdcachen.
Publika resolvrar: Cloudflare och Google låter dig rensa ett enskilt namn ur sina cachar, på 1.1.1.1:s sida för cacherensning och Google Public DNS sida för cacherensning.
Din internetleverantörs resolver och dina besökares resolvrar går inte att rensa utifrån. De löper ut i sin egen takt.
När det inte är propagering
Om de auktoritativa namnservrarna fortfarande svarar med det gamla värdet hjälper det inte att vänta. Leta i stället efter något av följande:
Fel zon eller leverantör. Posten ändrades hos en leverantör som domänen inte längre använder.
Fel namn. Apex-domänen (example.com) och www.example.com är separata poster.
En proxy framför. När ett CDN eller en proxy är aktiverad för posten svarar publik DNS med proxyns adresser, inte din servers, och det är meningen.
En post som aldrig sparades, eller ett stavfel i värdet. Jämför det du ser i leverantörens panel med svaret från kommandot dig.
Artikeln om DNS-posttyper förklarar vad varje post gör, och checklistan för när webbplatsen ligger nere går igenom stegen efter DNS.
Få veta när en post ändras med Uptimecheck
Propagering är den planerade sortens DNS-ändring. Den oplanerade sorten, ett stavfel under en migrering eller ett kapat konto hos registraren, är den som är värd ett larm. DNS-övervakning i Uptimecheck bevakar A-, AAAA-, CNAME-, MX-, NS-, SOA-, TXT- och CAA-poster:
Den frågar domänens auktoritativa namnservrar direkt, så en ändring syns vid nästa kontroll utan någon resolvercache emellan. När namnservrarna ger olika svar står det på monitorns sida.
En ny uppsättning poster larmas när två kontroller i rad har sett den, med de gamla och nya värdena, och sparas i postens historik.
Ange de värden du förväntar dig, så misslyckas kontrollen så fort de publicerade posterna inte matchar dem. Det bekräftar också att en planerad ändring har gått igenom.
Kontrollerna kan köras så ofta som varje minut. I Start ingår 10 DNS-monitorer, i Professional 25 och i Business 150.
Kombinera den med upptidskontroller av själva webbplatsen och bevakning av domänens utgångsdatum. Läs så konfigurerar du DNS-övervakning för att komma igång, och så upptäcker du kapade DNS-poster för varningssignalerna.
Få veta direkt när dina poster ändras. Testa Uptimecheck gratis i 14 dagar, inget kreditkort krävs.