# DNS Propagation Checker: Wartezeit nach einer DNS-Änderung URL: https://notificationharbor.com/de/tools/dns-propagation-checker Type: tool Locale: de Published: 2026-10-07 Updated: 2026-10-08 --- > Schätzen Sie die längste Wartezeit nach einer DNS-Änderung anhand von TTL und verstrichener Zeit. Läuft im Browser, für Records, neue DKIM-Keys und Nameserver-Wechsel. ## 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. ## 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. *[Interactive widget — see the live page for the full experience]* ## 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. ## Vier Schritte, die die Wartezeit verkürzen 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. **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. **Ä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. **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. *Call to action: So funktioniert Notification Harbor* ## FAQ ### 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.