Samenvatting

Deze DNS propagatie checker schat hoe lang een DNS-wijziging voor sommige resolvers onzichtbaar kan blijven. Propagatie is cache-expiratie: een resolver houdt het oude antwoord vast tot zijn TTL afloopt, dus het worst case is gelijk aan de oude TTL. Nieuwe records kunnen als afwezig worden gecachet voor de negatieve SOA-TTL, en nameserverwissels volgen de NS-TTL van de registry. Vul het soort wijziging, de TTL en de tijd sinds je bewerking in om de resterende wachttijd te zien. Hij draait in je browser en bevraagt geen live DNS.

DNS propagatie checker: hoe lang duurt het voordat je wijziging live is

Vul de TTL en de tijd sinds je bewerking in. Deze DNS propagatie checker toont de worst-case wachttijd voor een recordwijziging, een nieuwe DKIM-sleutel of een nameserverwissel.

Bekijk je wachtvenster

DNS propagatie checker

Kies het soort wijziging, vul de TTL in die van toepassing is en de tijd sinds je hem opsloeg. Het resultaat past zich aan terwijl je typt, en er wordt niets naar een server gestuurd.

De TTL die het record had voordat je het aanpaste, niet de nieuwe.

Hoe het werkt

Wat de calculator precies meet

Propagatie is cache-expiratie

DNS duwt wijzigingen nergens naartoe. Elke resolver bewaart het antwoord dat hij ophaalde tot de TTL verloopt en vraagt dan opnieuw. De traagste resolver is degene die het oude antwoord vlak voor je bewerking ophaalde, dus het worst case is gelijk aan de oude TTL.

Nieuwe records hebben hun eigen klok

Een record dat nog niet bestond, kan toch als afwezig gecachet worden. Dat negatieve antwoord geldt voor het kleinste van de SOA-TTL en het SOA-minimumveld. Als niemand de naam vroeg opvroeg, is het nieuwe record meteen zichtbaar.

Nameserverwijzigingen volgen de registry

Het wisselen van nameservers verandert de NS-records bij de bovenliggende zone, en die TTL stel je niet zelf in. De calculator neemt die als invoer, met twee dagen als typische waarde voor grote toplevel-domeinen zoals .com.

Voor een DNS-wijziging voor e-mail

Vier stappen die de wachttijd verkorten

Dit is de volgorde die we aanhouden voor SPF-, DKIM-, DMARC- en MX-bewerkingen op een verzenddomein.

  1. 1

    Lees de huidige TTL

    Voer dig uit op het record en lees het getal in het antwoordgedeelte. Dat is de TTL waar je wijziging overheen moet komen.

  2. 2

    Verlaag hem vooraf

    Zet de TTL op 300 seconden en wacht minstens zo lang als de oude TTL voordat je het record bewerkt. Resolvers moeten eerst de langlevende kopie laten verlopen.

  3. 3

    Maak de wijziging en noteer het tijdstip

    Sla de bewerking op, noteer de kloktijd en vul de verstreken tijd in de calculator hierboven in.

  4. 4

    Controleer bij de bron, daarna bij een resolver

    Vraag eerst je autoritatieve nameserver op, daarna een publieke resolver. Zet de TTL weer omhoog zodra beide hetzelfde antwoord geven en het venster voorbij is.

Veelgestelde vragen

Is deze DNS propagatie checker gratis?
Ja. Geen aanmelding, geen limiet op het aantal aanvragen. De berekening is rekenwerk met drie getallen die je invult, dus die draait in je browser en er wordt niets naar onze servers gestuurd.
Vraagt hij live DNS-servers op?
Nee. Hij zoekt je record niet op bij resolvers wereldwijd. Hij berekent de langst mogelijke tijd dat een gecacht antwoord kan blijven bestaan, op basis van de TTL die je invoert. Wil je zien wat een specifieke resolver nu teruggeeft, voer dan dig uit tegen die resolver en vergelijk het resultaat met het venster hier.
Waarom gebruikt de schatting de oude TTL en niet de nieuwe?
Resolvers cachen het antwoord dat ze ophaalden voordat je wijzigde, samen met de TTL die erbij hoorde. Een lagere TTL in dezelfde bewerking helpt niets voor resolvers die het oude antwoord al hebben. De nieuwe TTL geldt alleen voor antwoorden die na de wijziging worden opgehaald.
Wat is de negatieve cache-TTL en wanneer geldt die?
Als een resolver een naam opvraagt die geen record heeft, kan hij het antwoord “bestaat niet” cachen (RFC 2308). Dat geldt voor het kleinste van de eigen TTL van het SOA-record en zijn minimumveld. Het raakt alleen resolvers die de naam al opvroegen voordat je het record aanmaakte, bijvoorbeeld een DKIM-selector die iemand te vroeg testte.
Waarom duurt een nameserverwissel zo lang?
De NS-records die naar je nameservers wijzen staan bij de registry, met een TTL die jij niet beheerst. Voor grote toplevel-domeinen zoals .com is die TTL meestal twee dagen. Tot die verloopt, blijven sommige resolvers je oude nameservers bevragen.
Ik zit voorbij het venster en zie nog steeds de oude waarde. Wat nu?
Stop met de cache de schuld geven. Vraag je autoritatieve nameserver rechtstreeks op en controleer of die de nieuwe waarde levert. Doet hij dat niet, dan is de wijziging in de verkeerde zone of op de verkeerde hostnaam terechtgekomen, of nooit opgeslagen. Doet hij dat wel, test dan vanaf een resolver die je nog niet eerder gebruikte, en controleer of er een lokale cache zit op je eigen machine of netwerk.
Geldt dit ook voor SPF-, DKIM- en DMARC-records?
Ja. Het zijn TXT-records en ze worden net zo gecachet als andere records. Een ontvangende server die je oude SPF-record cachte, blijft die evalueren tot de TTL verloopt, dus een verzending direct na een bewerking kan tegen het oude beleid worden beoordeeld.

Volg de infrastructuur achter je eigen verzendingen

Deze tool schat een wachttijd. Notification Harbor dekt de verzendingen die je zelf beheert: opwarming van het domein, observability op traceniveau, en SPF, DKIM en DMARC correct ingesteld vóór de eerste productieverzending.

Bekijk hoe Notification Harbor werkt
notificationharbor
Gratis starten