Summary

Den här DNS-propageringskontrollen uppskattar hur länge en DNS-ändring kan vara osynlig för vissa resolvers. Propagering är utgång av cache: en resolver behåller det gamla svaret tills TTL:en går ut, så värsta fallet är lika med den gamla TTL:en. Nya poster kan cachas som obefintliga under SOA:ns negativa TTL, och byte av nameservrar följer registrets NS-TTL. Ange typ av ändring, TTL och tiden sedan du sparade för att se väntetiden kvar. Verktyget körs i din webbläsare och frågar inte live-DNS.

DNS propagering kontroll: hur länge tills din ändring syns

Ange TTL och tiden sedan du sparade ändringen. Kalkylatorn visar längsta möjliga väntetid kvar för en ändrad post, en ny DKIM-nyckel eller ett byte av nameservrar.

Kontrollera din väntetid

Kontroll av DNS-propagering

Välj typ av ändring, ange TTL som gäller och tiden sedan du sparade. Resultatet uppdateras medan du skriver, och inget lämnar din webbläsare.

TTL:en posten hade innan du ändrade den, inte den nya.

Så fungerar det

Vad kalkylatorn faktiskt mäter

Propagering är utgång av cache

DNS skickar inga ändringar någonstans. Varje resolver behåller svaret den hämtat tills TTL:en går ut och frågar sedan igen. Den långsammaste resolvern är den som hämtade det gamla svaret precis före din ändring, så värsta fallet är lika med den gamla TTL:en.

Nya poster har en egen klocka

En post som inte fanns kan ändå cachas som obefintlig. Det negativa svaret gäller under det lägre av SOA-TTL:en och SOA-minimumfältet. Om ingen frågade efter namnet i förväg syns den nya posten direkt.

Byte av nameservrar följer registret

Att byta nameservrar ändrar NS-posterna i föräldrazonen, och den TTL:en sätter du inte själv. Kalkylatorn tar den som indata, med två dygn som typiskt värde för stora toppdomäner som .com.

Före en DNS-ändring för e-post

Fyra steg som förkortar väntetiden

Så här går vi tillväga vid ändringar av SPF, DKIM, DMARC och MX på en avsändardomän.

  1. 1

    Läs av nuvarande TTL

    Kör dig mot posten och läs siffran i svarsdelen. Det är TTL:en din ändring måste överleva.

  2. 2

    Sänk den i förväg

    Sätt TTL till 300 sekunder och vänta minst lika länge som den gamla TTL:en innan du ändrar posten. Resolvers måste låta den långlivade kopian gå ut först.

  3. 3

    Gör ändringen och anteckna tiden

    Spara ändringen, skriv ner klockslaget och ange den förflutna tiden i kalkylatorn ovan.

  4. 4

    Verifiera hos källan, sedan hos en resolver

    Fråga först din auktoritativa nameserver, sedan en publik resolver. Höj TTL:en igen när båda visar samma värde och fönstret har passerat.

Vanliga frågor

Är den här DNS-propageringskontrollen gratis?
Ja. Ingen registrering och ingen gräns för antal förfrågningar. Beräkningen är aritmetik på tre tal som du skriver in, så den körs i din webbläsare och inget skickas till våra servrar.
Frågar verktyget live-DNS-servrar?
Nej. Det slår inte upp din post hos resolvers runt om i världen. Det beräknar längsta tid ett cachat svar kan överleva, utifrån TTL:en du anger. För att se vad en specifik resolver returnerar just nu kör du dig mot den resolvern och jämför med fönstret som visas här.
Varför använder uppskattningen den gamla TTL:en och inte den nya?
Resolvers cachar svaret de hämtade före din ändring, tillsammans med TTL:en som följde med. Att sänka TTL:en i samma ändring hjälper inte resolvers som redan har det gamla svaret. Den nya TTL:en gäller först för svar som hämtas efter ändringen.
Vad är negativ caching-TTL och när gäller den?
När en resolver frågar efter ett namn som saknar post kan den cacha svaret ”finns inte” (RFC 2308). Det gäller under det lägre av SOA-postens egen TTL och dess minimumfält. Det påverkar bara resolvers som frågat efter namnet innan du skapade posten, till exempel en DKIM-selector som någon testade för tidigt.
Varför tar en byte av nameservrar så lång tid?
NS-posterna som pekar på dina nameservrar ligger hos registret, med en TTL som du inte styr. För stora toppdomäner som .com är den TTL:en normalt två dygn. Tills den går ut fortsätter vissa resolvers att fråga dina gamla nameservrar.
Jag är förbi fönstret men ser fortfarande det gamla värdet. Vad gör jag nu?
Sluta skylla på cacheminnet. Fråga din auktoritativa nameserver direkt och bekräfta att den servar det nya värdet. Om den inte gör det gick ändringen till fel zon, fel värdnamn, eller så sparades den aldrig. Om den gör det, testa från en resolver du inte använt förut, och kontrollera om det finns en lokal cache på din egen maskin eller i ditt nätverk.
Gäller detta för SPF-, DKIM- och DMARC-poster?
Ja. De är TXT-poster och cachas precis som andra. En mottagande server som cachat din gamla SPF-post fortsätter att utvärdera den tills TTL:en går ut, så ett utskick direkt efter en ändring kan bedömas mot den gamla policyn.

Övervaka infrastrukturen bakom dina egna utskick

Det här verktyget uppskattar en väntetid. Notification Harbor täcker de utskick du själv styr: domain warmup, observabilitet per utskick och SPF, DKIM och DMARC uppsatta rätt före första produktionsutskicket.

Se hur Notification Harbor fungerar
notificationharbor
Kom igång gratis