DNS-propagering er tiden, fra du ændrer en DNS-record, til alle ser den nye værdi. Intet bliver faktisk sendt ud: resolvere rundt om på internettet bliver ved med at levere den kopi, de har cachet, indtil dens TTL (time to live) udløber, og spørger så igen. De fleste ændringer af records ses overalt inden for den gamle records TTL, ofte fra nogle minutter til en time. Ændringer af navneservere hos registratoren kan tage op til to døgn. Vil du se, hvor langt en ændring er nået, så spørg domænets egne navneservere, hvad de udgiver, og spørg derefter et par offentlige resolvere, hvad de stadig har i cachen.
Hvad sker der, når du ændrer en record
En besøgendes browser spørger ikke din DNS-udbyder direkte. Forespørgslen går gennem flere caches, og hver af dem kan svare ud fra hukommelsen:
Browseren gemmer de seneste svar i kort tid.
Styresystemet har sin egen resolver-cache.
En rekursiv resolver hos internetudbyderen, i virksomhedens netværk eller hos en offentlig tjeneste som 1.1.1.1 eller 8.8.8.8 cacher hvert svar, så længe dets TTL tillader det.
De autoritative navneservere for dit domæne har de rigtige records. Til at begynde med er det kun dem, der kender til din ændring.
Når du gemmer en ændring hos din DNS-udbyder, leverer de autoritative navneservere den som regel inden for sekunder eller minutter. Alle caches længere nede beholder det gamle svar, indtil deres kopi udløber. To besøgende på forskellige netværk kan derfor se forskellige servere i et stykke tid, og det er normalt, ikke en fejl. TTL sætter du selv pr. record, i sekunder; ordbogens opslag om DNS-propagering har den korte version.
Hvor lang tid tager DNS-propagering
Almindelige records: den gamle TTL
For en A-, AAAA-, CNAME-, MX- eller TXT-record er den længste ventetid den TTL, den gamle record havde, da resolverne cachede den. En record med en TTL på 3600 kan blive leveret fra cachen i op til en time, efter du har ændret den. Det hjælper ikke at sænke TTL samtidig med ændringen, for resolvere, der allerede har den gamle kopi, beholder den i den gamle TTL.
Ændring af navneservere: forældrezonen
Flytter du et domæne til en anden DNS-udbyder, skal du ændre dets NS-records hos registratoren. De udgives i forældrezonen, for eksempel .com, og det er forældrezonen, ikke dig, der sætter deres TTL. Du kan selv se det ved at spørge en .com-server direkte:
dig +norecurse @a.gtld-servers.net example.com NS
Svaret viser navneserverne med en TTL på 172800 sekunder, altså 48 timer. Det er derfra, rådet om “op til 48 timer” kommer. I den periode spørger nogle resolvere den gamle udbyder og andre den nye, så begge skal levere de samme records, indtil ændringen er faldet på plads.
Nye navne: negativ caching
Hvis nogen slog et navn op, før det fandtes, for eksempel et nyt subdomæne, du testede for tidligt, kan resolverne også cache svaret “navnet findes ikke”. RFC 2308 fastlægger hvor længe: den laveste af SOA-recordens minimum-felt og SOA-recordens egen TTL. Derfor kan et helt nyt subdomæne vise DNS_PROBE_FINISHED_NXDOMAIN et stykke tid på ét netværk og virke på et andet.
Applikationer, der holder fast i adresser
Et program, der kører længe, for eksempel en applikationsserver eller en proxy, kan slå et værtsnavn op én gang ved opstart og beholde adressen, indtil det genstartes, uanset hvad TTL siger. Hvis én tjeneste stadig taler med den gamle server, efter at alle andre er flyttet, så genstart den, før du mistænker DNS.
Sådan tjekker du DNS-propagering
Arbejd dig udad fra kilden. Bekræft først, at ændringen er udgivet, og se derefter, hvilke caches der stadig har det gamle svar.
1. Find de autoritative navneservere
dig NS example.com +short
Hvis det ikke er navneserverne hos den udbyder, hvor du lavede ændringen, har du redigeret den forkerte zone. Det er en almindelig grund til, at en ændring “aldrig propagerer”.
2. Spørg hver navneserver direkte
dig @ns1.example-dns.com example.com A +short
dig @ns1.example-dns.com example.com SOA +short
Gentag for hver navneserver på listen. De skal alle returnere den nye værdi og det samme SOA-serienummer, det tredje felt i SOA-svaret. En server med et ældre serienummer har ikke fået opdateringen endnu; det er propagering inde hos din udbyder, og den falder som regel på plads inden for minutter.
3. Spørg offentlige resolvere
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
Uden +short viser dig TTL i hvert svar. Fra en resolver er tallet den tid, der er tilbage af dens cachede kopi: en gammel værdi med 1200 sekunder tilbage bliver erstattet inden for 20 minutter. På Windows spørger nslookup -type=A example.com 1.1.1.1 en bestemt resolver, men uden TTL. Vores gratis DNS-opslag viser svar og TTL for enhver record-type fra vores servers resolver i Stockholm, uden at du skal installere noget.
4. Følg delegeringen efter et skift af navneservere
dig +trace example.com
+trace starter ved roden og følger henvisningerne ned til dine navneservere uden om alle caches på vejen. Ender sporet hos den nye udbyder, er ændringen hos registratoren slået igennem, og det eneste, der mangler, er, at cachene indhenter den.
Planlæg en ændring, så propageringen ikke gør ondt
Du kan ikke sætte fart på propageringen efter en ændring, men du kan gøre den kort, før du går i gang. Ved flytning til en ny server:
HvornårTrinMindst én gammel TTL førSænk recordens TTL, for eksempel fra 3600 til 300 sekunder.Før ændringenSæt den nye server op, og test den, for eksempel med en linje i hosts-filen eller curl –resolve.Selve ændringenPeg recorden på den nye server, og tjek det autoritative svar.Under propageringenLad den gamle server køre og levere det samme indhold. Nogle besøgende rammer den stadig.Et døgns tid senereHæv TTL igen, og sluk den gamle server.
Ved skift af navneservere skal du først kopiere alle records til den nye udbyder og sammenligne de to zoner record for record, også MX og TXT. En glemt TXT-record ødelægger e-mailgodkendelsen; SPF-, DKIM- og DMARC-tjekkeren viser, om den stadig består. Bruger domænet DNSSEC, så følg den nye udbyders vejledning for DS-recorden hos registratoren, for en DS-record, der ikke passer til de nye navneservere, får validerende resolvere til at svare SERVFAIL.
Ryd de caches, du selv styrer
Du kan rydde dine egne caches for at se den nye værdi hurtigere, og det hjælper, når du tester. For dine besøgende ændrer det intet.
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows: ipconfig /flushdns
Chrome: åbn chrome://net-internals/#dns, og ryd host-cachen.
Offentlige resolvere: Cloudflare og Google lader dig fjerne et enkelt navn fra deres caches, på 1.1.1.1’s purge-side og Google Public DNS’ flush-side.
Din internetudbyders resolver og dine besøgendes resolvere kan ikke ryddes udefra. De udløber i deres eget tempo.
Når det ikke er propagering
Returnerer de autoritative navneservere stadig den gamle værdi, hjælper det ikke at vente. Se i stedet efter en af disse:
Forkert zone eller udbyder. Recorden blev ændret hos en udbyder, domænet ikke længere bruger.
Forkert navn. Roddomænet (example.com) og www.example.com er to forskellige records.
En proxy foran. Er et CDN eller en proxy slået til for recorden, returnerer offentlig DNS proxyens adresser, ikke din servers, og det er med vilje.
En record, der aldrig blev gemt, eller en tastefejl i værdien. Sammenlign det, du ser i udbyderens panel, med svaret fra dig.
Opslaget om DNS-record-typer forklarer, hvad hver record gør, og tjeklisten til et nede website dækker trinene efter DNS.
Få besked, når en record ændres, med Uptimecheck
Propagering er den planlagte slags DNS-ændring. Den uplanlagte slags, en tastefejl under en migrering eller en kapret konto hos registratoren, er den, der fortjener en alarm. Uptimechecks DNS-overvågning holder øje med A-, AAAA-, CNAME-, MX-, NS-, SOA-, TXT- og CAA-records:
Den spørger domænets autoritative navneservere direkte, så en ændring viser sig ved næste tjek, uden nogen resolver-cache imellem. Giver navneserverne forskellige svar, står det på monitorens side.
Et nyt sæt records udløser en alarm, når to tjek i træk har set det, med de gamle og nye værdier, og gemmes i recordens historik.
Angiv de værdier, du forventer, så fejler tjekket, hver gang de udgivne records ikke matcher dem. Det bekræfter også, at en planlagt ændring er gået live.
Tjek kører helt ned til hvert minut. Start indeholder 10 DNS-monitorer, Professional 25 og Business 150.
Kombinér det med oppetidstjek af selve websitet og overvågning af domænets udløb. Se sådan sætter du DNS-overvågning op, og læs sådan opdager du kaprede DNS-records for at kende faresignalerne.
Få besked, i samme øjeblik dine records ændres. Prøv Uptimecheck gratis i 14 dage, uden kreditkort.