// KOSTENLOSES TOOL · DNS TTL RECHNER
DNS TTL Rechner und Umrechner
Trag eine TTL ein und du bekommst nicht nur die Zeit, für die sie steht, sondern den Zeitplan, auf den es ankommt: Vor einem Nameserver- oder Hosterwechsel senkst du die TTL der Records auf 300 Sekunden, und zwar mindestens eine volle alte TTL vorher — bei 3600 also eine Stunde vorher, bei 86400 einen Tag. Danach stellst du um, wartest eine niedrige TTL lang, bis alle Caches nachgezogen sind, und setzt den alten Wert wieder ein, sobald es stabil läuft. Der Rechner macht zusätzlich die Negative-Cache-Rechnung nach RFC 2308: so lange antwortet eine reparierte Domain noch mit NXDOMAIN. Kostenlos, sofort, ohne Anmeldung, alles im Browser.
Sekunden oder eine Dauer: 3600, 1h, 90min, 1d 12h, 04:00:00. Alles über einer Woche wird abgelehnt.
Häufige Werte — klick einen an:
Die TTL, die während der Umstellung läuft. 300 Sekunden sind der übliche Wert; unter 60 kaufst du dir nichts außer Anfragen.
Beide stehen im SOA in der Authority Section einer NXDOMAIN-Antwort: dig SOA beispiel.de. RFC 2308 nimmt den kleineren der beiden Werte. Voreingestellt sind die Werte der de.-Zone (7200 und 7200) — bei com. wären es 900.
So benutzt du den TTL-Rechner
Drei Felder, kein Konto, und gerechnet wird lokal — nichts von dem, was du eintippst, verlässt den Browser.
- Trag die aktuelle TTL ein. Die TTL, die auf den Records steht, die du gleich änderst — in Sekunden oder als Dauer wie 1h. Der Umrechner zeigt dir, wofür sie steht, und ob es ein Umschalt-, ein ausgewogener oder ein stabiler Wert ist.
- Lies den Zeitplan für den Wechsel ab. Er nennt die niedrige TTL für die Umstellung, wie lange vorher du sie veröffentlichen musst, wie lange die Caches nach dem Umstellen brauchen, und den Wert, auf den du danach zurückgehst.
- Ergänz die SOA-Zahlen, wenn die Domain NXDOMAIN liefert. Ruf dig SOA beispiel.de auf, nimm das Minimum-Feld und die TTL des SOA-Records selbst, und der Rechner gibt dir das Negative-Cache-Fenster nach RFC 2308 — also wie lange die Fehlermeldung die Reparatur überlebt.
Nameserver wechseln: wann senken, wann umstellen
Eine TTL nachzuschlagen ist selten Neugier auf Sekunden. Meistens steht ein Umzug an und er soll kurz werden. Die Regel dafür hat eine Hälfte, die nicht offensichtlich ist:
Eine niedrigere TTL hilft nur, wenn du sie vor der Änderung veröffentlichst — mindestens eine volle alte TTL vorher. Eine 24-Stunden-TTL zehn Minuten vor der Umstellung auf 300 Sekunden zu setzen bringt exakt nichts, weil jeder Resolver, der die gestrige Kopie hält, den neuen kleineren Wert erst morgen zu sehen bekommt. Die alte TTL muss zuerst von selbst ablaufen. Daraus wird der ganze Zeitplan:
- TTL auf 300 Sekunden senken, eine alte TTL im Voraus — zwei, wenn du Puffer willst, denn manche Resolver frischen früher auf und manche nicht.
- Umstellen: Nameserver wechseln oder die Records umbiegen.
- Eine niedrige TTL warten — fünf Minuten — und jeder Cache, der sich an die Regeln hält, hat die neue Antwort.
- Die alte TTL zurücksetzen, sobald es stabil läuft, damit du nicht bei jedem Besuch eine Auflösung bezahlst.
Was du nicht senken kannst, ist die TTL auf der Delegierung selbst. Die NS-Records, die auf deine Nameserver zeigen, liegen in der übergeordneten Zone und werden von der Registry veröffentlicht — bei .de sind das 86400 Sekunden, bei .com sogar 172800. Deshalb hat ein Nameserver-Wechsel einen langen Nachlauf, auch wenn deine eigenen Records längst auf 300 stehen, und deshalb sagt dir die Delegierung aus zwei Resolvern zu lesen mehr als jede Uhr.
Was bei .de anders rechnet: 24-Stunden-Delegierung und zwei Stunden Negative Cache
Dass die DENIC ihre Zone nicht laufend, sondern in Intervallen veröffentlicht, steht bereits auf der Seite Nameserver-Änderung nicht aktiv — dort geht es um die Frage, ab wann Warten überhaupt ein Befund ist. Hier kommt die andere Hälfte: die Zahlen, die im TTL-Feld stehen und die du nicht beeinflussen kannst. Alle folgenden Werte sind am 4. September 2026 direkt an den autoritativen Servern gemessen, du kannst sie in einer Minute nachrechnen.
Die Delegierung einer .de-Domain hat eine TTL von 86400 Sekunden — 24 Stunden. Das ist der Wert, mit dem die DENIC-Zone die NS-Records deiner Domain ausliefert:
dig +norecurse NS deine-domain.de @f.nic.de
deine-domain.de. 86400 IN NS ns1.dein-hoster.de.Diese 24 Stunden addieren sich auf das Veröffentlichungsintervall der DENIC — sie ersetzen es nicht. Erst schreibt die Registry deine Änderung in die nächste Zonen-Generation, und danach beginnt bei jedem Resolver, der inzwischen gefragt hat, eine eigene Uhr von bis zu einem Tag. Keine dieser beiden Uhren wird kürzer, wenn du die TTL deiner A- oder MX-Records senkst; die kaufen dir ausschließlich die zweite Hälfte, nämlich den Wechsel innerhalb derselben Nameserver. Zum Vergleich: bei .com stehen auf der Delegierung 172800 Sekunden, also 48 Stunden — .de ist an dieser Stelle doppelt so schnell, aber immer noch einen ganzen Tag langsam.
Und beim Negative Caching ist .de ausgerechnet die langsame TLD. Eine NXDOMAIN-Antwort aus der de.-Zone bringt den SOA mit TTL 7200 und einem Minimum von 7200 mit; nach RFC 2308 gilt der kleinere Wert, hier also 7200 Sekunden = zwei Stunden. Bei com. sind es 900 Sekunden. Praktisch heißt das: eine .de-Domain, die einmal ohne Delegierung dastand, antwortet nach der Reparatur bis zu acht Mal länger weiter mit NXDOMAIN als eine .com im selben Zustand. Wer in diesem Fenster zum zweiten Mal am Kundencenter dreht, repariert nicht, sondern verwechselt eine wartende Erinnerung mit einem offenen Fehler.
| Zone | TTL der Delegierung (NS) | Negative Cache |
|---|---|---|
de. | 86400 s — 24 Stunden | 7200 s — 2 Stunden |
com. | 172800 s — 48 Stunden | 900 s — 15 Minuten |
fr. | 3600 s — 1 Stunde | 600 s — 10 Minuten |
Der zweite deutsche Befund betrifft nicht die Registry, sondern die Hoster — und er zeigt, warum der Rechner oben zwei SOA-Felder verlangt statt einem. Wie lange eine falsch geschriebene Subdomain als „gibt es nicht" gemerkt bleibt, ist nicht das Minimum-Feld allein, sondern min(Minimum, TTL des SOA-Records). Hier sind beide Werte, wie die Anbieter sie auf ihrer eigenen Zone ausliefern; das ist nicht zwangsläufig der Vorgabewert in deinem Kundencenter, aber die Spannweite, die dir in diesem Markt begegnet:
| Anbieter | SOA-Minimum | TTL des SOA | Negative Cache tatsächlich |
|---|---|---|---|
| Mittwald | 3600 s | 300 s | 300 s — 5 Minuten |
| IONOS | 600 s | 86400 s | 600 s — 10 Minuten |
| STRATO | 600 s | 3600 s | 600 s — 10 Minuten |
| netcup | 7200 s | 7200 s | 7200 s — 2 Stunden |
| All-Inkl | 7200 s | 7200 s | 7200 s — 2 Stunden |
| Hetzner | 7200 s | 7200 s | 7200 s — 2 Stunden |
| Alfahosting | 86400 s | 86400 s | 86400 s — 24 Stunden |
Von fünf Minuten bis zu einem ganzen Tag, im selben Markt. Wenn du also einen www-Eintrag anlegst, den vorher schon jemand vergeblich aufgerufen hat, funktioniert er bei Mittwald fünf Minuten später und bei Alfahosting erst am nächsten Tag. Das ist keine Störung, und der Browser-Cache hat damit nichts zu tun. Die beiden mittleren Spalten zeigen auch, warum das Minimum-Feld allein in die Irre führt: bei IONOS steht dort 600, obwohl der SOA selbst mit 86400 ausgeliefert wird — es gewinnt der kleinere Wert, und genau diese Rechnung macht der Rechner oben.
Negative Caching: warum ein Ausfall seine Reparatur überlebt
Resolver merken sich „diesen Namen gibt es nicht" genauso wie eine Adresse, und diese Erinnerung hat eine eigene Laufzeit. RFC 2308 setzt sie auf den kleineren Wert aus dem Minimum-Feld des SOA-Records und der TTL des SOA-Records selbst — die beiden Zahlen, die der Rechner oben entgegennimmt. Beide kommen in der Authority Section der NXDOMAIN-Antwort mit, dig SOA beispiel.de legt sie dir vor.
An dieser Zahl hängt, wie lange eine Reparatur unsichtbar bleibt. Bei unserem eigenen Delegierungsausfall im Juni 2026 (auf Englisch) stand der Eintrag bei der Registry am 30. Juni um 17:30 UTC wieder richtig, und für einen großen Teil des Netzes kamen die Domains trotzdem erst am 1. und 2. Juli zurück. Daraus folgen zwei Handgriffe: Beurteile eine reparierte Delegierung nicht, bevor dieses Fenster abgelaufen ist. Und repariere sie innerhalb des Fensters nicht ein zweites Mal — so wird aus einer richtigen Änderung eine schlechtere.
Häufige TTL-Werte und wofür jeder gedacht ist
| Sekunden | Liest sich als | Wofür |
|---|---|---|
60 | 1 Minute | Laufender Umzug oder ein Failover-Record. Jeder Besucher kostet eine Auflösung; nicht dauerhaft stehen lassen. |
300 | 5 Minuten | Die Umschalt-TTL. Vor einem Nameserver- oder Hosterwechsel veröffentlichen, danach zurücksetzen. |
600 | 10 Minuten | Der Negative-Cache-Wert bei IONOS und STRATO — dort ist ein falsch geschriebener Name schnell wieder vergessen. |
3600 | 1 Stunde | Die häufigste Antwort auf „welche TTL soll ich nehmen" — schnell genug für einen Arbeitstag, günstig genug im Betrieb. |
7200 | 2 Stunden | Das Negative-Cache-Fenster der de.-Zone — und dasselbe Fenster bei netcup, All-Inkl und Hetzner. |
10800 | 3 Stunden | Die TTL, mit der Alfahosting seine eigene Zone ausliefert. |
14400 | 4 Stunden | Der Vorgabewert aus der cPanel-Ära. Immer noch überall, und der Grund, warum viele Änderungen einen halben Tag brauchen. |
86400 | 1 Tag | MX, TXT und alles, was du seit einem Jahr nicht angefasst hast. Auch die TTL der .de-Delegierung. |
172800 | 2 Tage | Die TTL der Delegierung in com. und net. — von der Registry gesetzt, nicht von dir. |
604800 | 1 Woche | Die praktische Obergrenze. Darüber verlässt du dich auf Caches, an die du nicht mehr herankommst. |
Um die TTL zu lesen, die ein Resolver gerade wirklich hält, statt der, die du konfiguriert hast: dig beispiel.de +noall +answer gibt sie in der zweiten Spalte aus, und sie zählt herunter, während die Kopie altert. Unter Windows zeigt nslookup -debug beispiel.de dasselbe Feld. Eine TTL weit unter deinem eingestellten Wert heißt, dass jemand anderes den Record ausliefert als gedacht; eine TTL, die sich nicht bewegt, heißt, dass du gerade einen autoritativen Server statt eines Caches liest.
// FAQ
Welche TTL soll ich vor einem Nameserver-Wechsel einstellen?
300 Sekunden, veröffentlicht mindestens eine volle alte TTL vor der Umstellung. Die Reihenfolge ist der Teil, den fast alle falsch machen: eine 24-Stunden-TTL eine Stunde vor dem Wechsel zu senken ändert nichts, weil die Resolver mit der alten Kopie sie erst am nächsten Tag neu lesen. Also einen Tag vorher senken, dann umstellen, fünf Minuten warten, bis die Caches nachziehen, und danach den ursprünglichen Wert zurücksetzen. Bei einer .de-Domain kommt zusätzlich die Delegierung dazu, deren TTL bei 86400 Sekunden liegt und die du nicht senken kannst.
Wie lange ist eine TTL von 3600?
Eine Stunde. Es ist die häufigste TTL auf Web-Records: lang genug, dass die meisten Besucher aus dem Cache bedient werden, kurz genug, dass eine Änderung innerhalb einer Arbeitsstunde überall ankommt. Zwei weitere Werte begegnen dir oft: 14400, also vier Stunden, der Vorgabewert einer ganzen Generation von Hosting-Panels, und 86400, also ein Tag, der auf Records gehört, die sich nicht bewegen sollen.
Wie lange dauert eine Nameserver-Änderung bei einer .de-Domain wirklich?
Zwei Uhren nacheinander, und keine davon ist deine Record-TTL. Zuerst muss die DENIC deine Änderung in ihre nächste Zonen-Generation schreiben. Danach läuft bei jedem Resolver, der die alte Delegierung schon geholt hat, deren TTL ab — und die liegt in der de.-Zone bei 86400 Sekunden, also 24 Stunden (nachzurechnen mit dig +norecurse NS deine-domain.de @f.nic.de). Bei .com wären es 172800. Eine gesenkte TTL auf deinen A- oder MX-Records verkürzt keine dieser beiden Uhren; sie hilft beim Wechsel innerhalb derselben Nameserver.
Was ist die Negative-Cache-TTL und wie wird sie berechnet?
Sie ist die Zeit, die Resolver sich merken, dass ein Name nicht existiert. RFC 2308 definiert sie als den kleineren Wert aus dem Minimum-Feld des SOA-Records und der TTL des SOA-Records selbst; beide kommen in der Authority Section einer NXDOMAIN-Antwort mit, dig SOA beispiel.de zeigt sie. Für .de sind das 7200 Sekunden, also zwei Stunden — achtmal so lang wie die 900 Sekunden bei .com. Sie ist der Grund, warum eine Reparatur eine Weile unsichtbar bleibt.
Macht eine niedrigere TTL die DNS-Umstellung schneller?
Nur wenn du sie im Voraus senkst. Es propagiert nichts: die Registry und deine Nameserver haben die neue Antwort sofort, und was du abwartest, sind ausschließlich Resolver, deren Kopie noch nicht abgelaufen ist. Eine vor der Änderung gesenkte TTL verkürzt diese Kopien. Eine gleichzeitig mit der Änderung gesenkte TTL verkürzt gar nichts, weil die Caches, auf die es ankommt, noch den vorherigen Wert mit der vorherigen Lebensdauer halten.
Ist eine sehr niedrige TTL schädlich?
Im Dauerbetrieb ja — bei 30 Sekunden kostet fast jeder Besuch eine DNS-Auflösung, das kostet Latenz beim Nutzer und Last auf deinen Nameservern, und es nimmt dir das Polster, das deine Seite erreichbar hält, wenn dein DNS-Anbieter zehn schlechte Minuten hat. Rund um eine Änderung ist sie dagegen genau richtig. Das Muster heißt senken, umstellen, prüfen, zurücksetzen — nicht dauerhaft auf 60 Sekunden bleiben, weil ein Umzug das einmal gebraucht hat.
Es zählt die TTL in der Antwort, nicht die im Formular.
Ein Befehl liest deine Domain aus zwei öffentlichen Resolvern mit der verbleibenden TTL auf jedem Record und prüft danach die Zone, die Bindung des Hostnamens und den tatsächlich ausgelieferten Inhalt.
$ npm i -g @clize/clize && clize install $ clize domain check deine-domain.de[ Agent Domains → ]