DNS-propagering er tiden fra du endrer en DNS-post til alle ser den nye verdien. Ingenting blir egentlig sendt ut: resolvere rundt om på internett fortsetter å svare med kopien de har i cache til TTL-en (time to live) går ut, og spør så på nytt. De fleste endringer av poster er synlige overalt innen den gamle postens TTL, ofte fra noen minutter til en time. Bytte av navnetjenere hos registraren kan ta opptil to døgn. For å se hvor langt en endring har kommet spør du først domenets egne navnetjenere hva de publiserer, og deretter noen offentlige resolvere hva de fortsatt har i cache.
Hva skjer når du endrer en post
En besøkendes nettleser spør ikke DNS-leverandøren din direkte. Spørsmålet går gjennom flere cacher, og hver av dem kan svare fra minnet:
Nettleseren husker nylige svar en kort stund.
Operativsystemet har sin egen resolver-cache.
En rekursiv resolver hos internettleverandøren, i bedriftsnettverket eller hos en offentlig tjeneste som 1.1.1.1 eller 8.8.8.8 lagrer hvert svar så lenge TTL-en tillater.
De autoritative navnetjenerne for domenet ditt har de faktiske postene. I starten er det bare de som vet om endringen.
Når du lagrer en endring hos DNS-leverandøren, svarer de autoritative navnetjenerne som regel med den nye verdien i løpet av sekunder eller minutter. Alle cacher lenger ned i kjeden beholder det gamle svaret til kopien deres utløper. To besøkende på ulike nettverk kan derfor se ulike servere en stund, og det er normalt, ikke en feil. TTL-en angir du selv per post, i sekunder; ordlisteoppslaget om DNS-propagering har kortversjonen.
Hvor lang tid tar DNS-propagering
Vanlige poster: den gamle TTL-en
For en A-, AAAA-, CNAME-, MX- eller TXT-post er den lengste ventetiden TTL-en den gamle posten hadde da resolverne lagret den. En post med TTL 3600 kan serveres fra cache i opptil en time etter at du har endret den. Det hjelper ikke å senke TTL-en samtidig med endringen, for resolvere som allerede har den gamle kopien, beholder den i henhold til den gamle TTL-en.
Bytte av navnetjenere: foreldresonen
Å flytte et domene til en annen DNS-leverandør betyr å endre NS-postene hos registraren. De publiseres i foreldresonen, for eksempel .com, og det er foreldresonen som bestemmer TTL-en deres, ikke du. Du kan se det selv ved å spørre en .com-server direkte:
dig +norecurse @a.gtld-servers.net example.com NS
Svaret viser navnetjenerne med en TTL på 172800 sekunder, altså 48 timer. Det er derfor rådet om «opptil 48 timer» finnes. I den perioden spør noen resolvere den gamle leverandøren og noen den nye, så begge må servere de samme postene til endringen har satt seg.
Nye navn: negativ caching
Hvis noen slo opp et navn før det fantes, for eksempel et nytt underdomene du testet for tidlig, kan resolverne også ha lagret svaret «navnet finnes ikke». RFC 2308 bestemmer hvor lenge: den laveste av minimumsfeltet i SOA-posten og SOA-postens egen TTL. Derfor kan et helt nytt underdomene vise DNS_PROBE_FINISHED_NXDOMAIN en stund på ett nettverk og fungere på et annet.
Applikasjoner som holder på adresser
Et program som kjører lenge, for eksempel en applikasjonsserver eller en proxy, kan slå opp et vertsnavn én gang ved oppstart og beholde adressen til det startes på nytt, uansett hva TTL-en sier. Hvis én tjeneste fortsatt snakker med den gamle serveren etter at alle andre har flyttet, start den på nytt før du mistenker DNS.
Slik sjekker du DNS-propagering
Jobb deg utover fra kilden. Bekreft først at endringen er publisert, og se deretter hvilke cacher som fortsatt har det gamle svaret.
1. Finn de autoritative navnetjenerne
dig NS example.com +short
Hvis dette ikke er navnetjenerne til leverandøren der du gjorde endringen, har du redigert feil sone. Det er en vanlig grunn til at en endring «aldri propagerer».
2. Spør hver navnetjener direkte
dig @ns1.example-dns.com example.com A +short
dig @ns1.example-dns.com example.com SOA +short
Gjenta for alle navnetjenerne i listen. Alle skal returnere den nye verdien og det samme SOA-serienummeret, det tredje feltet i SOA-svaret. En server med et eldre serienummer har ikke fått oppdateringen ennå; det er propagering internt hos leverandøren din, og den går som regel seg til i løpet av minutter.
3. Spør offentlige resolvere
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
Uten +short viser dig TTL-en i hvert svar. Fra en resolver er tallet tiden som er igjen av kopien i cachen: en gammel verdi med 1200 sekunder igjen blir byttet ut innen 20 minutter. På Windows spør nslookup -type=A example.com 1.1.1.1 en bestemt resolver, men uten TTL. Vårt gratis verktøy for DNS-oppslag viser svarene og TTL-ene for alle posttyper fra serverens resolver i Stockholm, uten at du trenger å installere noe.
4. Følg delegeringen etter bytte av navnetjenere
dig +trace example.com
+trace starter ved roten og følger henvisningene ned til navnetjenerne dine, uten å bruke cacher underveis. Hvis sporingen ender hos den nye leverandøren, er endringen hos registraren aktiv, og det som gjenstår, er at cachene tar igjen.
Planlegg endringen så propageringen ikke gjør vondt
Du kan ikke gjøre propageringen raskere etter en endring, men du kan gjøre den kort før du starter. Ved flytting til en ny server:
NårStegMinst én gammel TTL førSenk postens TTL, for eksempel fra 3600 til 300 sekunder.Før endringenSett opp den nye serveren og test den, for eksempel med en linje i hosts-filen eller curl –resolve.Selve endringenPek posten mot den nye serveren og sjekk det autoritative svaret.Under propageringenLa den gamle serveren kjøre og servere det samme innholdet. Noen besøkende når den fortsatt.Et døgn eller så senereØk TTL-en igjen og slå av den gamle serveren.
Ved bytte av navnetjenere kopierer du først alle postene til den nye leverandøren og sammenligner de to sonene post for post, MX og TXT inkludert. En glemt TXT-post ødelegger e-postautentiseringen; SPF-, DKIM- og DMARC-sjekkeren viser om den fortsatt godkjennes. Hvis domenet bruker DNSSEC, følg den nye leverandørens fremgangsmåte for DS-posten hos registraren, for en DS-post som ikke passer med de nye navnetjenerne, får validerende resolvere til å svare SERVFAIL.
Tøm cacher du selv styrer
Du kan tømme dine egne cacher for å se den nye verdien raskere, noe som er nyttig når du tester. For de besøkende endrer det ingenting.
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows: ipconfig /flushdns
Chrome: åpne chrome://net-internals/#dns og tøm vertscachen.
Offentlige resolvere: Cloudflare og Google lar deg fjerne ett navn fra cachene sine, på 1.1.1.1s side for å tømme cache og Google Public DNS’ side for å tømme cache.
Resolveren til internettleverandøren din og de besøkendes resolvere kan ikke tømmes utenfra. De utløper i sitt eget tempo.
Når det ikke er propagering
Hvis de autoritative navnetjenerne fortsatt returnerer den gamle verdien, hjelper det ikke å vente. Se heller etter ett av disse:
Feil sone eller leverandør. Posten ble endret hos en leverandør domenet ikke lenger bruker.
Feil navn. Rotdomenet (example.com) og www.example.com er separate poster.
En proxy foran. Når CDN eller proxy er slått på for posten, returnerer offentlig DNS proxyens adresser, ikke serverens, og det er meningen.
En post som aldri ble lagret, eller en skrivefeil i verdien. Sammenlign det du ser i leverandørens kontrollpanel med svaret fra dig.
Oppslaget om DNS-posttyper forklarer hva hver post gjør, og sjekklisten for når nettstedet er nede tar for seg stegene etter DNS.
Få vite når en post endres med Uptimecheck
Propagering er den planlagte typen DNS-endring. Den uplanlagte typen, en skrivefeil under en migrering eller en kapret konto hos registraren, er den som fortjener et varsel. DNS-overvåking i Uptimecheck følger med på A-, AAAA-, CNAME-, MX-, NS-, SOA-, TXT- og CAA-poster:
Den spør domenets autoritative navnetjenere direkte, så en endring vises ved neste sjekk, uten resolver-cache imellom. Når navnetjenerne gir ulike svar, står det på monitorsiden.
Et nytt sett med poster varsles når to sjekker på rad har sett det, med gamle og nye verdier, og lagres i postens historikk.
Legg inn verdiene du forventer, så feiler sjekken hver gang de publiserte postene ikke stemmer med dem, noe som også bekrefter at en planlagt endring er gått live.
Sjekkene kan kjøre så ofte som hvert minutt. Start inkluderer 10 DNS-monitorer, Professional 25 og Business 150.
Kombiner den med oppetidssjekker av selve nettstedet og overvåking av domeneutløp. For å sette opp en, se hvordan du setter opp DNS-overvåking, og les hvordan du oppdager kaprede DNS-poster for å kjenne varselsignalene.
Få vite i det øyeblikket postene dine endres. Prøv Uptimecheck gratis i 14 dager, uten kredittkort.