Vad är DNS-propagering? Varför tar det tid för DNS-ändringar

Du uppdaterar en domäns DNS-poster, sparar ändringen och förväntar dig att den nya webbplatsen eller e-posttjänsten ska fungera omedelbart. Men en kollega ser fortfarande den gamla webbplatsen, en onlinekontroll visar en annan adress, eller e-postleveransen beter sig inkonsistent. Denna försening kallas vanligtvis DNS-propagering.

Frasen kan få det att låta som om en enda uppdatering färdas genom ett centralt internetsystem. DNS är dock distribuerat. Domäninformation lagras och cachelagras över auktoritativa nameservrar, rekursiva resolvers, routrar, operativsystem och applikationer. Varje system kan uppdatera sin information vid olika tidpunkter.

De flesta DNS-ändringar blir synliga när cacherna expirerar och resolverna hämtar nya poster. Hur lång tid detta tar beror på postens tidigare Time to Live (TTL), resolverns beteende och om den auktoritativa DNS-konfigurationen är korrekt. Det finns ingen universell tidsram som garanterar att varje användare kommer att se det nya svaret.

Den här guiden förklarar vad folk menar med DNS-propagering, varför DNS-ändringar visas vid olika tidpunkter, hur man kontrollerar en domäns aktuella svar och vad man ska göra när en uppdatering fortfarande verkar ofullständig.

Vad betyder DNS-propagering?

DNS-propagering är det vanliga begreppet för den period under vilken olika användare eller DNS-resolvarer kan få olika svar efter att DNS-poster har ändrats. En användare i ett nätverk kan redan se den nya IP-adressen, medan en annan användares resolver fortfarande returnerar en cachad äldre adress.

Den underliggande DNS-ändringen görs på de auktoritativa nameserverna för domänen. Rekursiva resolvers hämtar och cachelagrar sedan poster för sina användare. Dessa resolvers behöver inte nödvändigtvis fråga de auktoritativa serverna igen varje gång någon besöker domänen. De kan återanvända ett cachelagrat svar så länge det är giltigt.

Det är därför som ”propagering” bättre förstås som cacheutgång och uppdateringDet finns ingen central kopia som måste uppdateras på alla internetanslutna enheter samtidigt. Den auktoritativa registreringen kan redan vara korrekt även om vissa resolver fortfarande levererar äldre cachade data.

Hur DNS-cache fungerar

När en webbläsare behöver hitta en domäns IP-adress ber den operativsystemet att lösa namnet. Operativsystemet kan ha ett svar i sitt cache. Om det inte har det, frågar det en konfigurerad rekursiv resolver, till exempel en som drivs av en internetleverantör, ett företag eller en offentlig DNS-tjänst.

Den rekursiva resolvern kan också ha ett svar i sitt cache. Om det svaret fortfarande är inom dess cachetid kan den returnera det utan att kontakta de auktoritativa namnservrarna. När den cachade posten har gått ut kan resolvern fråga det auktoritativa DNS-systemet och lagra det uppdaterade svaret.

Caching minskar söktiden och belastningen på DNS-infrastrukturen. Det innebär också att ändringar av poster inte nödvändigtvis blir synliga för alla resolvers samtidigt. Det gamla svaret kan fortfarande användas av en resolver tills dess cache går ut eller om resolvorn annars uppdaterar den.

Olika användare kan använda olika rekursiva lösare. Även personer i samma hushåll kan se olika svar om deras enheter använder olika DNS-tjänster, VPN:er, mobilnät eller lokala cacheminnen.

Vad är TTL i DNS?

TTL står för LivetidDet är ett värde, vanligtvis mätt i sekunder, som anger för rekursiva resolver hur länge de får cacha en DNS-post innan de kontrollerar ett uppdaterat svar.

Till exempel en TTL på 3600 betyr en timme. Om en resolver hämtar en post med den TTL:en kan den generellt sett fortsätta använda svaret i upp till en timme innan den behöver uppdatera det. En TTL på 300 betyder fem minuter.

Den TTL som är avgörande efter en ändring är vanligtvis den TTL för den gamla posten som resolvers redan har cachelagrat. Att sänka TTL:t omedelbart innan man ändrar en post kan inte förkorta väntetiden för de resolvers som har cachelagrat den tidigare, högre TTL:n. Dessa resolvers kan fortsätta att använda det gamla svaret tills den ursprungliga cachetiden löper ut.

Vid planerade migrationer minskar administratörer ofta TTL:en i förväg, väntar tillräckligt länge tills den tidigare TTL:en har löpt ut och gör sedan DNS-ändringen. När ändringen är stabil kan de öka TTL:en igen för att minska antalet upprepade frågor. De lämpliga värdena beror på tjänsten och operatörens förändringsprocess.

Varför tar DNS-ändringar olika lång tid?

Den vanligaste orsaken är att resolver har olika cachade kopior. Vissa kan redan ha uppdaterat posten, medan andra fortfarande använder ett svar som inte har gått ut. En resolver kan också tillämpa sitt eget uppdateringsbeteende eller cachelagra negativa svar, vilket är svar som indikerar att en post inte finns.

Lokalt cachning kan lägga till ett extra lager. En dator, router, webbläsare eller säkerhetsapplikation kan tillfälligt behålla DNS-information. Att starta om en webbläsare eller rensa operativsystemets DNS-cache kan hjälpa i vissa fall, men det kommer inte att ändra vad en rekursiv resolver fortfarande har cachelagrat.

Ändringar av DNS-leverantör kan introducera ytterligare timingfaktorer. Om du ändrar domänens auktoritativa namnservrar hos registranten måste resolvers kanske uppdatera delegeringsinformation samt de poster som levereras av dessa namnservrar. Detta är en annan typ av ändring jämfört med att redigera en A- eller AAAA-post inom samma DNS-hostingtjänst.

Slutligen kan en uppdatering vara felaktig vid den auktoritativa källan. Om fel post redigerades, om ändringen inte sparades, om domänen använder olika auktoritativa namnservrar eller om posten innehåller ett syntaxfel kommer vänta inte att åtgärda underliggande konfiguration.

DNS-propagering vs. uppdateringar av auktoritativa DNS

En auktoritativ DNS-server tillhandahåller de officiella posterna för ett domännamn eller en zon. När du redigerar en post i din DNS-leverantörs kontrollpanel bör leverantören uppdatera den auktoritativa data som den serverar.

En rekursiv resolver levererar DNS-svar till klientenheter. Den kan ha cachad data från innan ändringen. Därför kan den auktoritativa servern returnera den nya adressen medan en rekursiv resolver fortfarande returnerar en äldre.

Denna distinktion är användbar vid felsökning. Kontrollera först vad de auktoritativa namnservrarna returnerar. Om de redan har den förväntade posten har ändringen publicerats i källan, och återstående skillnader beror sannolikt på cachning eller resolverbeteende. Om auktoritativa servrar fortfarande returnerar det gamla värdet eller inget värde, undersök DNS-leverantörens konfiguration och posterna själva.

Att ändra namnservrar lägger till ett extra lager. Föräldradomänens DNS-zon måste peka på de avsedda auktoritativa namnservrarna, och dessa servrar måste leverera den korrekta zonen. En korrekt post hos en DNS-leverantör är inte användbar om domänen är delegerad till en annan leverantörs namnservrar.

Vanliga DNS-ändringar och deras effekter

Att ändra en En inspelning changes the IPv4 address returned for a hostname. Changing an AAAA-post ändrar sin IPv6-adress. Om båda finns tillgängliga kan klienter använda antingen adressfamilj beroende på deras nätverks- och anslutningsbeteende.

Att ändra en CNAME-post Ändrar värdnamnet som en alias pekar på. Resolvere kan då behöva söka upp målnamnet och dess adress. En ändring av målets poster kan påverka det slutgiltiga resultatet även om CNAME:n själv förblir oförändrad.

Att ändra en MX-post påverkar vilka mailserver som tar emot e-post för ett domännamn. E-postsystem kan cacha dessa poster, och e-postruttering kan ta tid att återspegla uppdateringar. När man byter e-postleverantör bör administratörer verifiera MX-poster samt eventuella relaterade e-postautentiseringsposter, såsom SPF, DKIM eller DMARC, separat.

Ändras namnservrar ändrar vilken DNS-leverantör som är auktoritativ för domänen. Detta kräver korrekt delegering hos registraren och korrekt zonkonfiguration hos den nya leverantören. En nameserver-migrering bör planeras noggrant eftersom saknade poster hos den nya leverantören kan göra webbplatser, e-post eller andra tjänster otillgängliga.

Hur du kontrollerar om en DNS-ändring har trätt i kraft

Börja med att fråga domänen från den dator du använder. På Windows, macOS och Linux, nslookup är allmänt tillgänglig:

nslookup example.com

För att kontrollera en IPv4-adresspost, använd:

nslookup -type=A example.com

För IPv6:

nslookup -type=AAAA example.com

För postserverposter:

nslookup -type=MX example.com

På macOS och Linux, gräva ger mer detaljerad utdata:

dig example.com A

För att endast visa svarsavsnittet:

dig example.com A +noall +answer

Du kan fråga en specifik rekursiv resolver för att jämföra svar. Till exempel:

dig @1.1.1.1 example.com A

På Windows kan du ange en DNS-server med:

nslookup example.com 1.1.1.1

Ersätt example.com med ditt domännamn. Resolveradressen i dessa exempel är bara en möjlig offentlig resolver; du kan också fråga efter DNS-tjänsten som används av din organisation eller leverantör.

Registrera den resolver du frågade, svaret och tiden. Att jämföra resultat från flera resolvers hjälper till att avgöra om skillnaden är lokal för en resolver eller om den syns mer generellt.

Hur man frågar en auktoritativ namnservrar

För att hitta de auktoritativa namnservrarna för en domän, använd:

dig example.com NS

Fråga sedan en av dessa namnservrar direkt efter den post du ändrade:

dig @ns1.example-dns.com example.com A

Ersätt ns1.example-dns.com med en auktoritativ server som är listad för ditt domännamn. Om den direkta frågan returnerar den förväntade adressen men en rekursiv resolver returnerar den gamla, har de auktoritativa datan uppdaterats och resolvern kan fortfarande använda ett cachelagrat svar.

Du kan också fråga gräva för att spåra delegeringsprocessen:

dig +trace example.com

Detta följer DNS-hierarkin från roten mot domänens auktoritativa servrar. Det kan hjälpa till att identifiera delegeringsproblem, även om dess utdata är mer detaljerad än vad de flesta grundläggande kontroller kräver.

Om du använder en DNS-leverantörs kontrollpanel, bekräfta att domänen faktiskt är delegerad till de namnservrar som visas där. En A-post kan vara korrekt i en leverantörs dashboard medan den offentliga domänen pekar mot en annan leverantör.

Vad händer om vissa användare ser den gamla webbplatsen?

Bekräfta först att den auktoritativa A- eller AAAA-posten har det avsedda värdet. Fråga sedan efter flera rekursiva resolvers och kontrollera om de returnerar samma svar. Om den auktoritativa data är korrekt men vissa resolvers returnerar en äldre adress, är cachning en sannolik förklaring.

Kontrollera därefter användarens lokala konfiguration. En VPN, företags DNS-resolutor, säkerhetsprodukt, webbläsarcache eller den lokala hosts-filen kan påverka vilken adress som returneras. Jämför resultatet från ett annat nätverk, till exempel en mobilanslutning, för att se om beteendet ändras.

Överväg också om både den gamla och den nya servern svarar. En migration kan se inkonsekvent ut om värden fortfarande levererar en cachad kopia eller omdirigerar på annat sätt. DNS-posten kan vara korrekt medan den gamla servern fortfarande är tillgänglig för användare vars resolver inte har uppdaterats.

Om problemet endast påverkar IPv4 eller endast IPv6, jämför A- och AAAA-poster separat. En enhet kan ansluta via IPv6 medan en annan använder IPv4. En adressfamilj kan peka mot den nya servern medan den andra fortfarande pekar mot den gamla.

Vad händer om en webbplats inte är tillgänglig efter en DNS-ändring?

Kontrollera att domänens auktoritativa namnservrar är korrekta och nåbara. Verifiera sedan att de relevanta posterna finns på dessa servrar. Om du nyligen har ändrat namnservrar, se till att den nya DNS-leverantören har alla nödvändiga poster, inklusive webbplatser, e-post, verifiering och tjänster.

Bekräfta att destinationsservern är redo att ta emot anslutningar för domänen. Att uppdatera DNS ändrar endast var klienter dirigeras. Det konfigurerar inte webbservern, installerar ett certifikat, öppnar en brandport eller kopierar webbplatsfiler.

Om DNS returnerar den förväntade IP-adressen men webbplatsen fortfarande misslyckas, testa servern och applikationen separat. Problemet kan ligga hos webbservern, brandväggen, TLS-certifikatet, värdkonfigurationen eller applikationen. En DNS-sökning bekräftar namnupplösning; den bekräftar inte att tjänsten är frisk.

För en allmän sökning av rutt mellan din enhet och en destination, se vår guide till använda traceroute för att diagnostisera nätverksanslutningsproblemTraceroute och DNS-sökningar testar olika delar av anslutningen, så de är användbara tillsammans när man försöker lokalisera ett problem.

Negativ cachning och resultatet “Posten hittades inte”

Resolvers kan cacha att en post inte finns. Detta kallas negativ cachning. Om en resolver frågar efter ett namn innan posten skapas, kan den tillfälligt fortsätta returnera ett ”inte hittat”-svar även efter att posten har lagts till.

Negativ cachning har också en TTL, baserad på information i zonens SOA-post och resolverregler. Det exakta beteendet kan variera. Om en ny skapad subdomän inte löses omedelbart, kontrollera först den auktoritativa namnservern. Om den returnerar den nya posten, vänta tills de negativa cacheposterna expirerar och jämför med andra resolvers.

Ett svar som anger att en post inte hittades kan också indikera att posten har lagts till i fel zon, att värdnamnet angavs felaktigt eller att domänen använder andra auktoritativa namnservrar. Kontrollera det fullständiga värdnamnet, posttypen och DNS-leverantören innan du antar att problemet endast beror på spridningsfördröjning.

Hur man planerar en DNS-migration

Innan du ändrar poster för en produktions tjänst, lista alla värdnamn och registrera de tjänster som de är beroende av. En webbplats kan använda A- och AAAA-poster, medan e-post är beroende av MX-, SPF-, DKIM- och DMARC-poster. Applikationer kan också vara beroende av verifieringsposter eller tjänsteupptäcktsposter.

Om ändringen är planerad, minska den relevanta TTL:en i förväg och vänta minst den tidigare TTL-perioden innan du byter destination. Förbered den nya servern eller leverantören innan du uppdaterar DNS. Testa direkt där det är möjligt och bekräfta att certifikat, brandregler, applikationsinställningar och e-posttjänster är redo.

Efter ändringen, kontrollera auktoritativa svar och flera rekursiva upplösare. Övervaka webbplatsens tillgänglighet, e-postleverans och applikationsfel. Behåll den gamla tjänsten tillgänglig under övergångsperioden när det är praktiskt möjligt, eftersom vissa användare kan fortsätta att nå den medan cachade svar löper ut.

När den nya konfigurationen är stabil, återställ en lämplig TTL. Att behålla en mycket låg TTL under en längre period kan öka volymen av DNS-frågor utan att ge nämnvärd fördel för en tjänst som sällan ändras.

Vanliga missförstånd om DNS-propagering

En vanlig missuppfattning är att varje DNS-ändring tar exakt 24 eller 48 timmar. Det finns ingen fast, universell varaktighet. Den effektiva fördröjningen beror på tidigare TTL-värden, resolverns cachning, delegation ändringar och korrektheten i den auktoritativa konfigurationen.

Ett annat missförstånd är att rensa webbläsarens cache uppdaterar DNS överallt. Det kan rensa information som lagrats på den enheten, men det kan inte rensa en fjärrresolvers cacheminne. På samma sätt kan omstart av en router rensa dess lokala cache, men ändrar inte de auktoritativa posterna.

Ett tredje missförstånd är att en DNS-kontroll som visar olika svar bevisar att domänen är trasig. Olika svar kan förekomma under en planerad migration, särskilt när resolvers har cachad data vid olika tidpunkter. Den viktiga frågan är om de auktoritativa posterna är korrekta och om de återstående skillnaderna är förenliga med den tidigare TTL:n.

Slutligen konfigurerar DNS-propagering inte destinationstjänsten. En korrekt IP-adress kan fortfarande leda till en otillgänglig webbplats om servern, brandväggen, TLS-certifikatet eller applikationen inte är redo.

Vanliga frågor om DNS-propagering

Hur lång tid tar DNS-propagering?

Det finns ingen garanterad tid för hur långt det tar. Vissa ändringar syns snabbt, medan andra kan vara inkonsekventa tills cachade poster har löpt ut. Den tidigare TTL:n, resolverns beteende och om nameserverna har ändrats påverkar alla tiden.

Gör en sänkning av TTL-en förändring omedelbar?

Nej. Att sänka ett TTL påverkar framtida cachning efter att resolvers har hämtat det nya TTL-värdet. Resolvers som redan har cachelagrat den gamla posten kan fortsätta att använda den tills dess tidigare TTL löper ut.

Varför visar DNS-kontroller olika resultat?

De kan fråga olika rekursiva resolverer från olika platser. Dessa resolverer kan ha olika svar i sitt cache, uppdateras vid olika tidpunkter eller få olika svar på grund av geografiska DNS-policyer.

Ska jag rensa min dators DNS-cache?

Det kan hjälpa när din egen enhet har cachelagrat ett gammalt svar. Det rensar inte cachar som hålls av din internetleverantör, företagsresolver eller offentlig DNS-tjänst.

Varför löser min webbplats men misslyckas ändå med att ladda?

DNS kan returnera rätt adress medan destinationsservern eller applikationen har ett problem. Kontrollera webbservern, brandväggen, TLS-certifikatet och hostingkonfigurationen separat.

Kan ändringar av nameserver ta längre tid än ändringar av poster?

De kan innehålla ytterligare delegeringsinformation hos registraren och i föräldradomenens DNS-zon. Den nya leverantören måste också hantera en komplett och korrekt zon. Verifiera både delegeringen och posterna på de nya auktoritativa servrarna.

DNS-ändringar kan synas vid olika tidpunkter eftersom auktoritativa namnservrar och rekursiva resolvers har separata roller, och resolvers cachar svar enligt TTL-värden. En användare kan se en gammal adress medan en annan redan får den nya.

För att undersöka detta, kontrollera först de auktoritativa namnservrarna och jämför sedan svaren från flera rekursiva resolver. Bekräfta posttypen, värdnamnet, TTL och delegation av namnservrar. Om DNS returnerar den förväntade adressen men tjänsten fortfarande inte är tillgänglig, kontrollera destinationservern och applikationen som separata delar av problemet.

Att förstå cachning gör det enklare att planera och felsöka DNS-ändringar. För mer grundläggande nätverksteknik, fortsätt med våra guider till IP-adresser, standardgateway, och traceroute.