Zusammenfassung

Dieser DNS Propagation Checker schätzt, wie lange eine DNS-Änderung für manche Resolver unsichtbar bleiben kann. Propagation ist Cache-Ablauf: Ein Resolver behält die alte Antwort bis zum Ablauf der TTL, daher entspricht der Worst Case der alten TTL. Neue Records können für die negative SOA-TTL als nicht vorhanden gecacht werden, Nameserver-Wechsel folgen der NS-TTL der Registry. Geben Sie die Art der Änderung, die TTL und die Zeit seit Ihrer Änderung ein, um die Restzeit zu sehen. Die Berechnung läuft im Browser und fragt keine Live-DNS-Daten ab.

DNS Propagation Checker: Wie lange bis Ihre Änderung live ist

Geben Sie die TTL und die Zeit seit Ihrer Änderung ein. Dieser DNS Propagation Checker zeigt die Restzeit im Worst Case für eine Record-Änderung, einen neuen DKIM-Key oder einen Nameserver-Wechsel.

Wartefenster prüfen

DNS Propagation Checker

Wählen Sie die Art der Änderung, geben Sie die zutreffende TTL und die Zeit seit dem Speichern ein. Das Ergebnis aktualisiert sich beim Tippen, und nichts verlässt Ihren Browser.

Die TTL, die der Record vor Ihrer Änderung hatte, nicht die neue.

So funktioniert es

Was der Rechner tatsächlich misst

Propagation ist Cache-Ablauf

DNS verschickt Änderungen nicht aktiv. Jeder Resolver behält die Antwort, die er geholt hat, bis die TTL abläuft, und fragt dann erneut nach. Der langsamste Resolver ist der, der die alte Antwort kurz vor Ihrer Änderung geholt hat. Der Worst Case entspricht daher der alten TTL.

Neue Records haben eine eigene Uhr

Ein Record, den es noch nicht gab, kann trotzdem als nicht vorhanden gecacht sein. Diese negative Antwort gilt für den kleineren Wert aus SOA-TTL und SOA-Minimum. Hat niemand den Namen vorab abgefragt, ist der neue Record sofort sichtbar.

Nameserver-Wechsel folgen der Registry

Ein Nameserver-Wechsel ändert die NS-Records in der übergeordneten Zone, und diese TTL legen Sie nicht selbst fest. Der Rechner nimmt sie als Eingabe, mit zwei Tagen als üblichem Wert für große TLDs wie .com.

Vor einer DNS-Änderung für E-Mail

Vier Schritte, die die Wartezeit verkürzen

So gehen wir bei SPF-, DKIM-, DMARC- und MX-Änderungen auf einer Versanddomain vor.

  1. 1

    Aktuelle TTL ablesen

    Führen Sie dig auf dem Record aus und lesen Sie die Zahl im Answer-Abschnitt ab. Das ist die TTL, die Ihre Änderung überdauern muss.

  2. 2

    Vorab senken

    Setzen Sie die TTL auf 300 Sekunden und warten Sie mindestens so lange, wie die alte TTL war, bevor Sie den Record ändern. Resolver müssen die langlebige Kopie zuerst ablaufen lassen.

  3. 3

    Änderung vornehmen und Zeit notieren

    Speichern Sie die Änderung, notieren Sie die Uhrzeit und tragen Sie die verstrichene Zeit in den Rechner oben ein.

  4. 4

    Am Ursprung prüfen, dann an einem Resolver

    Fragen Sie zuerst Ihren autoritativen Nameserver ab, danach einen öffentlichen Resolver. Stellen Sie die TTL wieder hoch, sobald beide übereinstimmen und das Fenster vorbei ist.

Häufige Fragen

Ist dieser DNS Propagation Checker kostenlos?
Ja. Keine Anmeldung, kein Limit für Anfragen. Die Berechnung ist reine Arithmetik mit drei Zahlen, die Sie eingeben. Sie läuft im Browser, und nichts wird an unsere Server gesendet.
Fragt er Live-DNS-Server ab?
Nein. Er schlägt Ihren Record nicht bei Resolvern weltweit nach. Er berechnet aus der eingegebenen TTL, wie lange eine gecachte Antwort höchstens überleben kann. Um zu sehen, was ein bestimmter Resolver jetzt liefert, fragen Sie diesen mit dig ab und vergleichen Sie das Ergebnis mit dem hier angezeigten Fenster.
Warum rechnet die Schätzung mit der alten und nicht mit der neuen TTL?
Resolver cachen die Antwort, die sie vor Ihrer Änderung geholt haben, zusammen mit der dazugehörigen TTL. Wenn Sie die TTL in derselben Änderung senken, bringt das Resolvern nichts, die die alte Antwort bereits haben. Die neue TTL gilt erst für Antworten, die nach der Änderung geholt werden.
Was ist die negative Caching-TTL, und wann greift sie?
Fragt ein Resolver nach einem Namen ohne Record, kann er die Antwort „existiert nicht“ cachen (RFC 2308). Sie gilt für den kleineren Wert aus der eigenen TTL des SOA-Records und seinem Minimum-Feld. Betroffen sind nur Resolver, die den Namen abgefragt haben, bevor Sie den Record angelegt haben, etwa ein DKIM-Selector, den jemand zu früh getestet hat.
Warum dauert ein Nameserver-Wechsel so lange?
Die NS-Records, die auf Ihre Nameserver zeigen, liegen bei der Registry, mit einer TTL, die Sie nicht kontrollieren. Bei großen TLDs wie .com beträgt diese TTL meist zwei Tage. Bis sie abläuft, fragen manche Resolver weiterhin Ihre alten Nameserver ab.
Das Fenster ist vorbei, und ich sehe immer noch den alten Wert. Was nun?
Hören Sie auf, die Caches verantwortlich zu machen. Fragen Sie Ihren autoritativen Nameserver direkt ab und prüfen Sie, ob er den neuen Wert liefert. Wenn nicht, ging die Änderung in die falsche Zone, auf den falschen Host-Namen oder wurde nie gespeichert. Wenn doch, testen Sie von einem Resolver, den Sie bisher nicht genutzt haben, und prüfen Sie einen lokalen Cache auf Ihrem Rechner oder im Netzwerk.
Gilt das auch für SPF-, DKIM- und DMARC-Records?
Ja. Es sind TXT-Records, und sie werden wie alle anderen gecacht. Ein empfangender Server, der Ihren alten SPF-Record gecacht hat, wertet ihn weiter aus, bis die TTL abläuft. Ein Versand direkt nach einer Änderung kann daher gegen die alte Richtlinie geprüft werden.

Die Infrastruktur hinter Ihren eigenen Versänden im Blick behalten

Dieses Tool schätzt eine Wartezeit. Notification Harbor deckt die Versände ab, die Sie selbst steuern: Domain-Warmup, Observability auf Trace-Ebene sowie SPF, DKIM und DMARC, korrekt eingerichtet bevor der erste produktive Versand läuft.

So funktioniert Notification Harbor
notificationharbor
Kostenlos starten