# DNS propagering kontroll: så länge dröjer din ändring URL: https://notificationharbor.com/sv/tools/dns-propagering-kontroll Type: tool Locale: sv Published: 2026-10-07 Updated: 2026-10-08 --- > Uppskatta värsta fallet för väntetiden efter en DNS-ändring utifrån TTL och tiden sedan du sparade. Körs i webbläsaren och täcker poster, nya DKIM-nycklar och byte av nameservrar. ## 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. ## 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. *[Interactive widget — see the live page for the full experience]* ## 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. ## Fyra steg som förkortar väntetiden 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. **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. **Gör ändringen och anteckna tiden** — Spara ändringen, skriv ner klockslaget och ange den förflutna tiden i kalkylatorn ovan. 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. *Call to action: Se hur Notification Harbor fungerar* ## FAQ ### Ä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.