DNS-Propagation: Wie lange dauert es wirklich?

Von CaptainDNS
Veröffentlicht am 26. März 2026

Diagramm mit den tatsächlichen DNS-Propagationszeiten je nach TTL auf verschiedenen öffentlichen Resolvern

TL;DR

Die "DNS-Propagation" existiert nicht als Mechanismus: DNS pusht nichts. Es sind die Caches der Resolver, die gemäß dem vom Zonenadministrator konfigurierten TTL (Time To Live) ablaufen.
Die tatsächliche Dauer hängt vom TTL des geänderten Eintrags ab: 1 Minute (TTL 60) bis 24 Stunden (TTL 86400). Es gibt keinen technischen Grund für eine Verzögerung von 48 Stunden.
Den TTL 48 Stunden vor einer DNS-Änderung auf 300 Sekunden senken beseitigt den Mythos der "24 bis 48 Stunden". Nach der Änderung ist der neue Eintrag überall in 5 Minuten sichtbar.
Mit einem Multi-Resolver-Tool in Echtzeit prüfen, ob die Änderung wirksam ist, Resolver für Resolver.

"Rechne mit 24 bis 48 Stunden für die DNS-Propagation." Wenn du schon einmal einen DNS-Eintrag geändert hast, kennst du diesen Satz. Auf den Hilfeseiten deines Registrars, in einem Support-Ticket oder in einem Tutorial, das du über eine Suchmaschine gefunden hast. Es ist wahrscheinlich der am häufigsten wiederholte technische Rat im Internet. Er ist auch einer der irreführendsten.

DNS "propagiert" nichts. Es gibt keinen Verbreitungsmechanismus im DNS-Protokoll, der Änderungen an die Resolver weltweit pusht. Was es gibt, ist ein verteiltes Cache-System mit einer Ablaufuhr: dem TTL. Wenn du einen Eintrag änderst, liefern die Resolver, die den alten Wert im Cache haben, diesen weiter aus, bis der TTL abläuft. Danach fragen sie den autoritativen Server ab und erhalten den neuen Wert. Das ist alles.

Die wahrgenommene Verzögerung ist vollständig kontrollierbar. Wenn der TTL bei 5 Minuten liegt, ist die Änderung überall in 5 Minuten sichtbar. Wenn er bei 24 Stunden liegt, muss man 24 Stunden warten. Die Zahl "48 Stunden" entspricht keinem Standard-TTL-Wert. Sie stammt aus einer vergangenen Ära, den Anfängen des kommerziellen DNS, als Registrare TTL-Werte von 86.400 Sekunden (24 Stunden) vorgaben und die Resolver der Internetprovider manchmal eigene Verzögerungen hinzufügten.

Dieser Artikel zerlegt den tatsächlichen Mechanismus, beziffert die exakten Zeiten für jeden TTL-Wert und gibt dir eine DNS-Migrationsmethode, die die Verzögerung vorhersehbar und kontrollierbar macht.

Prüfe deine DNS-Propagation

DNS-Propagation testen DNS Lookup starten

Der Mythos der "24 bis 48 Stunden"

Woher kommt diese Zahl?

Um den Ursprung des Mythos zu verstehen, muss man in die 2000er Jahre zurückgehen. Damals konfigurierten Registrare wie Network Solutions, GoDaddy oder Gandi standardmäßig TTL-Werte von 86.400 Sekunden (24 Stunden) auf den von ihnen verwalteten Einträgen. Einige TLD-Registries (wie VeriSign für .com und .net) aktualisierten die Zonendateien nur alle 12 Stunden. In Kombination beider Faktoren konnte eine Änderung der NS-Server tatsächlich bis zu 36 Stunden dauern, bis sie überall sichtbar war. Auf "48 Stunden" aufzurunden, sollte Grenzfälle abdecken.

Das Problem: Diese Schätzung ist in der Dokumentation eingefroren geblieben, obwohl sich die Infrastruktur verändert hat. Heute aktualisieren die großen Registries ihre Zonen innerhalb weniger Minuten. Moderne Registrare bieten standardmäßig TTL-Werte von 3.600 Sekunden (1 Stunde) an, manchmal sogar 300 Sekunden. Die technische Realität von 2026 hat nichts mehr mit der von 2002 gemein.

Das Wort "Propagation" ist irreführend

Der Begriff "Propagation" suggeriert einen aktiven Verbreitungsprozess. Als würde eine DNS-Änderung von Server zu Server gepusht, ähnlich einem Software-Update, das schrittweise ausgerollt wird. Dieses mentale Bild ist falsch.

DNS funktioniert nach dem Pull-Modell, nicht nach Push. Kein Server benachrichtigt die Resolver, dass sich "der Wert geändert hat". Jeder rekursive Resolver entscheidet selbst, wann er den autoritativen Server abfragt, basierend auf dem TTL des Eintrags, den er im Cache hat.

Das passiert tatsächlich, wenn ein Nutzer captaindns.com in seinen Browser eingibt:

Der Stub Resolver des lokalen Rechners prüft seinen Cache. Wenn er eine gültige Antwort hat (TTL nicht abgelaufen), gibt er sie sofort zurück.
Wenn er nichts im Cache hat, leitet er die Anfrage an den konfigurierten rekursiven Resolver weiter (den des Internetproviders, von Google, Cloudflare usw.).
Der rekursive Resolver prüft seinen eigenen Cache. Wenn er eine gültige Antwort hat, gibt er sie zurück.
Wenn er nichts hat oder der TTL abgelaufen ist, startet er eine vollständige Auflösung: Er fragt einen Root-Server, dann den TLD-Server (.com), dann den autoritativen Server für die Domain.
Der autoritative Server gibt die aktuelle Antwort zurück (den neuen Eintrag, wenn du ihn geändert hast) zusammen mit dem konfigurierten TTL.
Der Resolver speichert diese Antwort für die Dauer des TTL im Cache und gibt sie an den Nutzer zurück.

Die "Propagationsverzögerung" ist nichts anderes als die verbleibende Zeit bis zum Ablauf des Caches. Wenn der Resolver den alten Eintrag vor 30 Minuten mit einem TTL von 3.600 Sekunden gecacht hat, dauert es noch 30 Minuten, bis er den autoritativen Server erneut abfragt.

Diagramm der hierarchischen DNS-Auflösung: Stub Resolver, rekursiver Resolver, Root-Server, TLD, autoritativer Server

Der TTL: Die echte Uhr der Propagation

Was ist der TTL?

Der TTL (Time To Live) ist ein numerisches Feld, das jedem DNS-Eintrag zugeordnet ist und in Sekunden angegeben wird. Er teilt den Resolvern mit, wie lange sie die Antwort im Cache behalten dürfen, bevor sie den autoritativen Server erneut abfragen müssen.

Der TTL wird vom Administrator der DNS-Zone festgelegt, nicht vom Protokoll. Es ist eine betriebliche Entscheidung. Jeder Eintrag in einer Zone kann einen eigenen TTL haben. Du kannst einen TTL von 60 Sekunden auf einem A-Eintrag konfigurieren, der auf einen hochverfügbaren Dienst zeigt, und gleichzeitig einen TTL von 86.400 Sekunden auf einem MX-Eintrag belassen, der sich nie ändert.

RFC 1035 (Abschnitt 3.2.1) definiert den TTL als vorzeichenlose 32-Bit-Ganzzahl, also einen theoretischen Maximalwert von 2.147.483.647 Sekunden (etwa 68 Jahre). In der Praxis empfiehlt RFC 2181 (Abschnitt 8), jeden Wert über 2.147.483.647 als 0 zu behandeln. Übliche Werte liegen zwischen 60 und 86.400 Sekunden.

Um den aktuellen TTL eines Eintrags zu prüfen, verwende dig:

dig captaindns.com A +noall +answer

Die Ausgabe sieht so aus:

captaindns.com.    3600    IN    A    76.76.21.21

Die Zahl 3600 ist der verbleibende TTL in Sekunden. Achtung: Dieser Wert verringert sich jede Sekunde. Wenn du den Befehl 10 Sekunden später erneut ausführst, siehst du 3590. Wenn er 0 erreicht, betrachtet der Resolver den Eintrag als abgelaufen und fragt den autoritativen Server erneut ab.

Um den vom autoritativen Server festgelegten TTL zu erhalten (und nicht den verbleibenden TTL im Cache des Resolvers), frage direkt den autoritativen Server ab:

dig captaindns.com A @ns1.captaindns.com +noall +answer

Tabelle der tatsächlichen Zeiten nach gängigem TTL

Diese Tabelle zeigt die maximale Verzögerung zwischen einer DNS-Änderung und ihrer vollständigen Sichtbarkeit auf allen Resolvern, unter der Annahme, dass der Resolver den alten Eintrag kurz vor der Änderung gecacht hat (Worst Case).

TTL (Sekunden)	Lesbare Dauer	Max. Sichtbarkeitsverzögerung	Typischer Einsatz
60	1 Minute	1 Minute	Automatisches Failover, Hochverfügbarkeit, kritische Dienste
300	5 Minuten	5 Minuten	CDN, Lastverteilung, Pre-Migration
900	15 Minuten	15 Minuten	Cloud-Dienste (AWS, GCP, Azure)
1800	30 Minuten	30 Minuten	SaaS-Anwendungen
3600	1 Stunde	1 Stunde	Gängiger Standard moderner Registrare (Cloudflare, Route 53)
14400	4 Stunden	4 Stunden	Historischer Standard von OVH, Gandi, einigen cPanel-Panels
43200	12 Stunden	12 Stunden	Stabile, selten geänderte Einträge
86400	24 Stunden	24 Stunden	NS-Einträge, stabile Zoneneinträge, historischer Standard

Die "24 bis 48 Stunden" des Mythos entsprechen dem Worst Case eines TTL von 86.400 kombiniert mit einem Resolver, der den Wert eine Sekunde vor der Änderung gecacht hat. In diesem Szenario beträgt die maximale Verzögerung 24 Stunden, nicht 48. Die 48 Stunden sind ein vorsorgliches Aufrunden ohne technische Grundlage.

Warum ignorieren manche Resolver den TTL?

Das DNS-Protokoll (RFC 1035) verlangt, dass Resolver den TTL einhalten. In der Praxis gibt es einige Abweichungen.

Aufgezwungener Mindest-TTL. Google Public DNS erzwingt eine Untergrenze von 30 Sekunden. Wenn ein autoritativer Server einen TTL von 0 oder 10 Sekunden zurückgibt, behandelt Google ihn als 30 Sekunden. Dieses Verhalten ist in ihrer technischen FAQ dokumentiert. Cloudflare wendet eine ähnliche Untergrenze an. Die Auswirkungen sind für die meisten Anwendungsfälle vernachlässigbar.

Aufgezwungener Maximal-TTL. Einige ISP-Resolver wenden eine TTL-Obergrenze an, um die Last auf ihren Servern zu reduzieren. Ein ISP, der Millionen von Anfragen pro Sekunde verarbeitet, kann entscheiden, einen TTL von 60 Sekunden nicht zu respektieren und ihn als 300 Sekunden zu behandeln. Dieses Verhalten ist selten, undokumentiert und widerspricht den RFCs, existiert aber.

Negativer Cache. Der TTL gilt auch für NXDOMAIN-Antworten (Domain existiert nicht) über das SOA-Minimum-TTL-Feld (RFC 2308). Wenn du einen neuen Eintrag für einen Namen erstellst, der zuvor nicht existierte, kann der Resolver die Antwort "existiert nicht" mit dem negativen TTL der SOA-Zone gecacht haben. Diese Verzögerung wird bei Migrationen oft vergessen.

Um den negativen TTL deiner Zone zu prüfen:

dig captaindns.com SOA +noall +answer

captaindns.com.    3600    IN    SOA    ns1.captaindns.com. admin.captaindns.com. 2026032601 7200 900 1209600 300

Das letzte Feld (300) ist der negative TTL. NXDOMAIN-Antworten werden 300 Sekunden (5 Minuten) lang gecacht.

Die DNS-Resolver: Alle unterschiedlich beim Caching

Der hierarchische Cache

Die DNS-Auflösung durchläuft mehrere Cache-Ebenen, bevor sie den autoritativen Server erreicht. Jede Ebene kann eine Antwort zurückgeben, ohne weiterzugehen:

Ebene 1: Der Anwendungs-Cache. Browser und Anwendungen pflegen ihren eigenen DNS-Cache. Chrome beispielsweise speichert Auflösungen standardmäßig 60 Sekunden lang. Dieser Cache ist unabhängig vom Betriebssystem.

Ebene 2: Der Stub Resolver (OS-Cache). Das Betriebssystem pflegt einen lokalen DNS-Cache. Unter Windows verwaltet der Dienst "DNS-Client" diesen Cache. Unter macOS ist es mDNSResponder. Unter Linux mit systemd ist es systemd-resolved. Dieser Cache respektiert in der Regel den vom rekursiven Resolver zurückgegebenen TTL.

Ebene 3: Der rekursive Resolver. Das ist der DNS-Server, der in deiner Netzwerkverbindung konfiguriert ist (der des Internetproviders, Google 8.8.8.8, Cloudflare 1.1.1.1 usw.). Er führt die vollständige Auflösung durch, indem er die DNS-Hierarchie abfragt, und pflegt den umfangreichsten Cache. Der TTL auf dieser Ebene bestimmt die wahrgenommene "Propagationsverzögerung".

Ebene 4: DNS-Relays im Unternehmen. In Unternehmensnetzwerken kann ein interner DNS-Server (Active Directory, Pi-hole, dnsmasq) als Relay zum rekursiven Resolver dienen. Dieses Relay fügt eine zusätzliche Cache-Ebene mit eigenen Aufbewahrungsregeln hinzu.

Eine DNS-Änderung ist für einen Nutzer erst dann vollständig sichtbar, wenn alle Cache-Ebenen, die er durchläuft, abgelaufen sind. Im Worst Case (alle Caches wurden gerade gefüllt) entspricht die Verzögerung dem höchsten TTL in der Kette. In der Praxis haben Anwendungs- und OS-Caches kurze TTLs (60 Sekunden oder weniger), daher ist der Flaschenhals fast immer der rekursive Resolver.

Warum variieren die Ergebnisse je nach Resolver?

Wenn du die DNS-Propagation testest, kannst du je nach abgefragtem Resolver unterschiedliche Ergebnisse erhalten. Das ist normal, und es gibt drei Gründe dafür.

Grund 1: Der Zeitpunkt des Cachings unterscheidet sich. Google DNS hat den alten Eintrag vielleicht vor 2 Minuten gecacht, während Cloudflare es vor 55 Minuten getan hat. Bei einem TTL von 3.600 Sekunden liefert Google den alten Wert noch 58 Minuten lang aus, während Cloudflare ihn nur noch 5 Minuten lang ausliefert. Gleicher TTL, aber zeitliche Verschiebung.

Grund 2: Die Cache-Infrastruktur ist verteilt. Google DNS ist nicht ein einzelner Server. Es ist ein Netzwerk von Anycast-Servern, verteilt über Hunderte von Rechenzentren. Jede Instanz pflegt ihren eigenen Cache. Eine Anfrage aus Paris trifft einen anderen Google-Server als eine aus Tokio. Beide können unterschiedliche Cache-Werte haben. Deshalb können zwei Nutzer, die "8.8.8.8" zum gleichen Zeitpunkt abfragen, unterschiedliche Antworten erhalten.

Grund 3: EDNS Client Subnet (ECS). Einige Domains verwenden geolokalisierte Antworten über EDNS Client Subnet. Der autoritative Server gibt je nach Standort des Clients unterschiedliche IP-Adressen zurück. Ein Nutzer in Frankreich erhält die IP des europäischen Rechenzentrums, ein Nutzer in Japan die IP des asiatischen Rechenzentrums. Das ist kein Propagationsproblem: Es ist das erwartete Verhalten eines CDN. Aber es erschwert die Diagnose, weil die Resolver legitimerweise unterschiedliche Antworten im Cache haben.

Timeline der Cache-Ablaufzeiten auf verschiedenen öffentlichen Resolvern: Google DNS, Cloudflare und Quad9 lassen den Cache zu unterschiedlichen Zeitpunkten ablaufen

Um zu prüfen, was jeder Resolver im Cache hat, frage sie direkt ab:

dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer

Wenn alle drei dieselbe IP mit unterschiedlichen verbleibenden TTL-Werten zurückgeben, ist das der Beweis, dass die Änderung im Gange ist und die Caches zu unterschiedlichen Zeitpunkten ablaufen.

Praxisleitfaden: DNS-Migration ohne Überraschungen

Die folgende Methode beseitigt die Unsicherheit einer DNS-Migration. Sie basiert auf einem einfachen Prinzip: den TTL vor der Änderung senken, damit der Cache nach der Änderung schnell abläuft. Das ist die Standardtechnik, die SRE (Site Reliability Engineers) bei Infrastrukturmigrationen verwenden.

Vor der Änderung: T-48

Schritt 1: Den aktuellen TTL prüfen.

Frage den autoritativen Server ab, um den festgelegten TTL zu erfahren (nicht den verbleibenden TTL in einem Cache):

dig captaindns.com A @ns1.captaindns.com +noall +answer

Wenn der TTL 86.400 Sekunden (24 Stunden) beträgt, musst du ihn senken und warten, bis der alte Cache abläuft.

Schritt 2: Den TTL auf 300 Sekunden (5 Minuten) senken.

In der Oberfläche deines Registrars oder deines DNS-Zonenmanagers änderst du den TTL des Eintrags, den du ändern willst. Ändere noch nicht den Wert des Eintrags. Nur der TTL wird angepasst.

captaindns.com.    300    IN    A    76.76.21.21

Schritt 3: Warten, bis der alte TTL überall abgelaufen ist.

Das ist der entscheidende Schritt. Nachdem du den TTL auf 300 gesenkt hast, musst du warten, bis der alte TTL überall abgelaufen ist. Wenn der alte TTL 86.400 Sekunden betrug, warte 24 Stunden. Wenn es 3.600 Sekunden waren, warte 1 Stunde.

Warum? Weil die Resolver, die den Eintrag mit dem alten TTL von 86.400 im Cache haben, deine TTL-Änderung nicht sehen, bis ihr Cache abgelaufen ist. Sobald der alte TTL abgelaufen ist, fragen alle Resolver den autoritativen Server erneut ab und erhalten den Eintrag mit dem neuen TTL von 300 Sekunden.

Deshalb solltest du 48 Stunden vorher beginnen: Im Worst Case (anfänglicher TTL von 86.400) brauchst du 24 Stunden für die Propagation des neuen TTL, plus einen Sicherheitspuffer.

Prüfe den Fortschritt, indem du mehrere Resolver abfragst:

dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer

Wenn alle drei einen verbleibenden TTL von 300 oder weniger zurückgeben, ist der neue TTL aktiv.

Am Tag der Änderung: T

Schritt 4: Die DNS-Änderung durchführen.

Ändere den Wert des Eintrags bei deinem Registrar oder DNS-Anbieter. Zum Beispiel bei einer Servermigration:

captaindns.com.    300    IN    A    185.199.108.153

Der TTL bleibt bei 300 Sekunden. Die Änderung wird auf allen Resolvern in maximal 5 Minuten sichtbar sein.

Schritt 5: Die Propagation prüfen.

Frage die wichtigsten öffentlichen Resolver ab, um zu bestätigen, dass die Änderung wirksam ist:

dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer
dig captaindns.com A @208.67.222.222 +noall +answer

Das Propagationstest-Tool von CaptainDNS führt diese Prüfung automatisch durch, indem es Resolver auf mehreren Kontinenten abfragt.

Schritt 6: Den Dienst validieren.

Stelle sicher, dass der Dienst auf der neuen Adresse korrekt funktioniert. Teste HTTP/HTTPS-Zugriffe, E-Mail-Versand, API-Verbindungen. Gehe nicht zum nächsten Schritt über, solange nicht alles bestätigt ist.

Nach der Änderung: T+1

Schritt 7: Den TTL wieder hochsetzen.

Sobald die Änderung bestätigt und der Dienst validiert ist, setze den TTL auf einen Standardwert zurück. Ein TTL von 3.600 Sekunden (1 Stunde) ist ein guter Kompromiss zwischen Reaktionsfähigkeit und Reduzierung der DNS-Last:

captaindns.com.    3600    IN    A    185.199.108.153

Ein dauerhaft niedriger TTL (60 Sekunden) überlastet die autoritativen Server. Ein zu hoher TTL (86.400 Sekunden) macht zukünftige Migrationen langwieriger. Für Einträge, die sich selten ändern (NS, MX), ist ein TTL von 3.600 bis 14.400 angemessen.

Schritt 8: 24 bis 48 Stunden überwachen.

Überwache die Service-Metriken (Antwortzeiten, Fehlerquote, E-Mail-Zustellbarkeit) in den Stunden nach der Migration. Resolver mit nicht standardkonformem Verhalten können ihren Cache verzögert aktualisieren. Ein Tool für resilientes DNS-Monitoring hilft, solche Anomalien zu erkennen.

Wie lässt sich die "Propagation" beschleunigen?

Wenn die Änderung durchgeführt ist und einige Resolver noch den alten Wert ausliefern, gibt es einige konkrete Maßnahmen, um die Verzögerung zu reduzieren. Keine davon ersetzt die oben beschriebene TTL-Reduktionsmethode, aber sie sind als Ergänzung nützlich.

Lokalen DNS-Cache leeren

Der Cache deines lokalen Rechners kann den alten Wert enthalten. Ihn zu leeren zwingt dein System, den rekursiven Resolver erneut abzufragen.

Windows (PowerShell als Administrator):

ipconfig /flushdns

macOS (Terminal):

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Chrome (Adressleiste):

chrome://net-internals/#dns

Klicke auf "Clear host cache". Chrome pflegt seinen eigenen DNS-Cache unabhängig vom Betriebssystem.

Purge bei öffentlichen Resolvern anfordern

Einige öffentliche Resolver bieten eine Oberfläche, um einen bestimmten Eintrag aus ihrem Cache zu entfernen. Das ist keine Garantie (der Eintrag wird bei der nächsten Anfrage erneut gecacht), aber es erzwingt eine sofortige Neuauflösung.

Google Public DNS: Gehe auf die Seite Google Public DNS Flush Cache und gib die Domain und den Eintragstyp ein, der geleert werden soll.

Cloudflare: Gehe auf die Seite Cloudflare Purge Cache und gib die Domain ein.

Diese Tools leeren den Cache eines einzigen Knotens (desjenigen, der deine Anfrage bearbeitet). Resolver wie Google und Cloudflare verwenden Anycast: Der Cache ist auf Hunderte von Servern verteilt. Eine Purge-Anfrage aus Paris leert nicht den Cache des Servers, der Nutzer in São Paulo bedient.

Was NICHT funktioniert

Einige "Lösungen" kursieren in Foren und auf Support-Seiten. Sie sind wirkungslos oder sogar kontraproduktiv.

Den Router neu starten. Der DNS-Cache eines Heimrouters ist oft auf wenige Dutzend Einträge beschränkt und läuft schnell ab. Selbst wenn der Neustart diesen Cache leert, behält der rekursive Resolver des Internetproviders (der echte Flaschenhals) den alten Wert.

Den DNS-Resolver auf dem Client wechseln. Von Google (8.8.8.8) auf Cloudflare (1.1.1.1) zu wechseln, kann den Eindruck erwecken, dass die Änderung propagiert ist, weil Cloudflare möglicherweise nicht denselben Eintrag im Cache hat wie Google. Aber das löst nichts für andere Nutzer. Es ist ein Beobachtungsfehler, keine Lösung.

"Noch etwas" warten. Wenn die Änderung nach der dem TTL entsprechenden Zeit nicht sichtbar ist, hilft weiteres Warten nicht. Das Problem liegt woanders: negativer TTL im Cache, Fehler in der DNS-Zone, falsch konfigurierter autoritativer Server oder ein Resolver, der den TTL nicht respektiert. Du musst diagnostizieren, nicht abwarten.

Spezifische Anwendungsfälle

Hostingwechsel (A / AAAA)

Das ist der häufigste Fall: Du migrierst eine Website auf einen neuen Server. Der A-Eintrag (IPv4) oder AAAA-Eintrag (IPv6) bekommt eine neue IP-Adresse.

Der Standardplan funktioniert hier perfekt. Senke den TTL 48 Stunden vorher, ändere die IP, prüfe. Die Besonderheit: Wenn dein alter und neuer Server so konfiguriert sind, dass sie auf denselben Domainnamen antworten, sehen Nutzer, die die alte IP erhalten, den alten Server, und Nutzer mit der neuen IP sehen den neuen. Während der Übergangszeit müssen beide Server parallel laufen.

Bei Migrationen mit gleichzeitiger Änderung der IPv4- und IPv6-Adresse vergiss nicht, beide Einträge zu ändern. Ein vergessener AAAA-Eintrag lässt IPv6-Clients weiter auf den alten Server zeigen.

CNAME und Aliase

CNAME-Einträge haben ihren eigenen TTL, aber der Resolver muss auch das Ziel des CNAME auflösen. Die Gesamtverzögerung ist das Maximum aus dem TTL des CNAME und dem TTL des Zieleintrags. Wenn dein CNAME einen TTL von 300 hat, aber auf einen A-Eintrag mit einem TTL von 86.400 zeigt, dauert die Änderung des A-Werts bis zu 24 Stunden, auch wenn der CNAME selbst in 5 Minuten aufgelöst wird.

E-Mail: MX, SPF, DKIM, DMARC

E-Mail-bezogene Einträge verdienen besondere Aufmerksamkeit, weil die Folgen eines Fehlers gravierender sind als bei einer Website. Eine 10 Minuten lang unerreichbare Website ist ärgerlich. E-Mails, die 10 Minuten lang verloren gehen, können ernsthafte berufliche Konsequenzen haben.

MX (Mail Exchanger). MX-Einträge haben oft einen hohen TTL (3.600 bis 86.400). Bei einer Migration des E-Mail-Anbieters ist die TTL-Reduktion obligatorisch. Während der Übergangszeit müssen beide MX-Server E-Mails für deine Domain akzeptieren. Konfiguriere den alten Anbieter, Nachrichten an den neuen weiterzuleiten, wenn möglich.

SPF (TXT-Eintrag). Die Änderung eines SPF-Eintrags wird wirksam, sobald der TTL des TXT abläuft. Das Risiko: Wenn du einen neuen Versandanbieter hinzufügst (z.B. ein Marketing-Tool), ohne den SPF zu aktualisieren, werden seine E-Mails von Servern abgelehnt, die den alten SPF im Cache haben. Lösung: Füge den SPF-Mechanismus hinzu, bevor du über den neuen Anbieter versendest, und warte auf den TTL-Ablauf.

DKIM (TXT-Eintrag unter _domainkey). Die Veröffentlichung eines neuen öffentlichen DKIM-Schlüssels folgt denselben TTL-Regeln. Achtung bei einer Schlüsselrotation: Der alte Schlüssel muss im DNS veröffentlicht bleiben, solange E-Mails, die damit signiert sind, noch unterwegs sind (E-Mail-Warteschlangen können Nachrichten mehrere Tage lang aufbewahren).

DMARC (TXT-Eintrag unter _dmarc). Eine Änderung der DMARC-Policy (z.B. Wechsel von p=none zu p=quarantine) wird schrittweise wirksam, im Takt des Cache-Ablaufs. Es wird empfohlen, über den Modus p=quarantine zu gehen, bevor man p=reject aktiviert, um Fehlalarme während der Übergangszeit zu begrenzen.

DNSSEC

Die Aktivierung oder Änderung von DNSSEC fügt eine zusätzliche Komplexitätsebene hinzu. Zwei Arten von Einträgen sind betroffen: die DNSKEY in der DNS-Zone und der DS-Eintrag (Delegation Signer) beim Registrar.

Der DS-Eintrag wird in der Zone des übergeordneten TLD veröffentlicht (z.B. in der .com-Zone für eine .com-Domain). Seine Aktualisierung hängt vom Registrar und der TLD-Registry ab. Die Verzögerung ist oft länger als bei einem Standardeintrag, weil sie eine Kommunikation zwischen Registrar und Registry erfordert.

Die Regel bei der Aktivierung von DNSSEC: Zuerst die DNSKEY veröffentlichen, die vollständige Propagation abwarten (mindestens das 2-fache des TTL), dann den DS-Eintrag hinzufügen. Wenn der DS hinzugefügt wird, bevor die DNSKEY überall sichtbar sind, geben validierende Resolver SERVFAIL zurück, was deine Domain unerreichbar macht.

Änderung der NS-Server (Delegation)

Die Änderung der autoritativen Server (NS-Einträge) ist der heikelste Fall. NS-Einträge auf TLD-Ebene haben ihren eigenen TTL (oft 48 Stunden für .com). Der Resolver muss diesen TTL einhalten, bevor er die TLD-Registry erneut abfragt.

Die empfohlene Vorgehensweise:

Die vollständige DNS-Zone auf den neuen NS-Servern replizieren
Den TTL aller wichtigen Einträge auf 300 Sekunden senken
Den Ablauf des alten TTL abwarten
Die NS-Delegation beim Registrar ändern
Die alten NS-Server 48 bis 72 Stunden lang aktiv halten (damit die NS-Caches ablaufen können)
Sicherstellen, dass beide NS-Server-Sets während der gesamten Übergangszeit dieselben Antworten liefern

Diagnose: Warum funktioniert meine DNS-Änderung nicht?

Wenn die Änderung nach der erwarteten Verzögerung immer noch nicht sichtbar ist, muss man diagnostizieren. Hier die häufigsten Ursachen, sortiert nach Wahrscheinlichkeit.

Ursache 1: Die Änderung wurde nicht gespeichert

Das ist die häufigste Ursache. Die Registrar-Oberfläche hat "gespeichert" angezeigt, aber der autoritative Server hat den neuen Wert noch nicht. Prüfe direkt:

dig captaindns.com A @ns1.captaindns.com +noall +answer

Wenn der alte Eintrag erscheint, liegt das Problem beim DNS-Anbieter, nicht bei der Propagation.

Ursache 2: Der negative Cache

Wenn du einen neuen Eintrag erstellt hast (der zuvor nicht existierte), kann der Resolver eine NXDOMAIN-Antwort im Cache haben. Prüfe den negativen TTL im SOA:

dig captaindns.com SOA +noall +answer

Das letzte Feld des SOA ist der negative TTL. Warte diese Zeit ab.

Ursache 3: Der falsche Eintragstyp

Du hast den A-Eintrag geändert, aber das DNS gibt einen CNAME zurück, der auf den alten Eintrag zeigt. Oder du hast einen TXT geändert, aber es gibt zwei TXT-Einträge und du hast den falschen bearbeitet. Prüfe, indem du alle Typen abfragst:

dig captaindns.com ANY @ns1.captaindns.com

Ursache 4: Defekte DNSSEC-Kette

Wenn DNSSEC aktiv ist und die Vertrauenskette unterbrochen ist (DS-Eintrag passt nicht mehr zum DNSKEY), geben validierende Resolver SERVFAIL statt der Antwort zurück. Teste mit und ohne DNSSEC-Validierung:

dig captaindns.com A @8.8.8.8 +dnssec
dig captaindns.com A @8.8.8.8 +cd

Das Flag +cd (Checking Disabled) deaktiviert die DNSSEC-Validierung. Wenn die Anfrage mit +cd funktioniert, aber ohne nicht, ist das Problem DNSSEC.

Ursache 5: DNS-Relay im Unternehmen mit aggressivem Cache

In einem Unternehmensnetzwerk kann ein interner DNS-Server (Active Directory, Pi-hole) Antworten mit einem höheren TTL als dem vom rekursiven Resolver zurückgegebenen cachen. Kontaktiere deinen Netzwerkadministrator, um den Cache des internen DNS-Servers zu leeren.

Die Rolle des SOA-Eintrags verstehen

Der SOA-Eintrag (Start of Authority) enthält Parameter, die die "Propagation" indirekt beeinflussen. Seine Felder werden bei der Planung einer Migration oft übersehen.

dig captaindns.com SOA +noall +answer

captaindns.com. 3600 IN SOA ns1.captaindns.com. admin.captaindns.com. (
    2026032601 ; Serial
    7200       ; Refresh (2 Stunden)
    900        ; Retry (15 Minuten)
    1209600    ; Expire (14 Tage)
    300        ; Minimum / negativer TTL (5 Minuten)
)

Serial: Versionsnummer der Zone. Sekundäre Server vergleichen diese Nummer, um Änderungen zu erkennen. Eine nicht inkrementierte Serial nach einer Änderung verhindert die Synchronisation auf sekundäre Server.

Refresh: Intervall, in dem sekundäre Server prüfen, ob sich die Zone geändert hat. Ein Refresh von 7.200 Sekunden (2 Stunden) bedeutet, dass der sekundäre Server eine veraltete Zone bis zu 2 Stunden lang ausliefern kann. Dieser Parameter betrifft die Konsistenz zwischen autoritativen Servern, nicht den Cache rekursiver Resolver.

Minimum (negativer TTL): Der TTL, der auf NXDOMAIN-Antworten angewendet wird. Wenn du einen neuen Eintrag erstellst, müssen die Resolver, die eine NXDOMAIN-Antwort im Cache haben, diese Zeit abwarten. Empfohlener Wert: 300 Sekunden (5 Minuten).

Öffentliche Resolver und ihre Besonderheiten

Jeder öffentliche Resolver hat spezifische Verhaltensweisen, die die Wahrnehmung der Propagation beeinflussen. Diese Besonderheiten zu kennen hilft bei der Diagnose. Ein Vergleich öffentlicher DNS-Resolver bietet weiterführende Informationen zu diesem Thema.

Google Public DNS (8.8.8.8 / 8.8.4.4)

Mindest-TTL: 30 Sekunden
Purge-Oberfläche verfügbar
Massive Anycast-Infrastruktur (Hunderte von PoP)
Unterstützt EDNS Client Subnet für geolokalisierte Antworten

Cloudflare (1.1.1.1 / 1.0.0.1)

Mindest-TTL: 30 Sekunden
Purge-Oberfläche verfügbar
Anycast-Architektur in über 310 Rechenzentren
Übermittelt standardmäßig kein Client-Subnetz (besserer Datenschutz)

Quad9 (9.9.9.9 / 149.112.112.112)

Integrierter Malware-Filter (kann bestimmte Domains blockieren)
Mindest-TTL nicht öffentlich dokumentiert
Keine öffentliche Purge-Oberfläche
DNSSEC-Validierung standardmäßig aktiviert

OpenDNS (208.67.222.222 / 208.67.220.220)

Konfigurierbarer Filter (Inhaltskategorien)
Cache kann in manchen Fällen hartnäckiger als der TTL sein
Purge-Oberfläche über das Dashboard

ISP-Resolver

Variables und oft undokumentiertes Verhalten
Einige erzwingen Mindest- oder Maximal-TTLs
Cache manchmal zwischen Millionen von Abonnenten geteilt (Mutualisierungseffekt)
Selten eine Purge-Oberfläche

Empfohlener Aktionsplan

Hier die vollständige Vorgehensweise in 5 Schritten zusammengefasst. Drucke sie aus oder speichere sie für deine nächste DNS-Migration.

Aktuellen TTL prüfen: Frage den autoritativen Server mit dig ab oder nutze das CaptainDNS-Tool, um den TTL jedes Eintrags deiner Zone zu erhalten.
TTL 48 Stunden vorher senken: Reduziere auf 300 Sekunden für alle Einträge, die du ändern willst. Vergiss nicht die zugehörigen Einträge (AAAA wenn du A änderst, TXT wenn du E-Mail migrierst).
Änderung durchführen: Ändere die DNS-Einträge bei deinem Registrar oder Anbieter. Prüfe sofort, ob der autoritative Server den neuen Wert zurückgibt.
Propagation prüfen: Teste über mehrere öffentliche Resolver (Google, Cloudflare, Quad9, OpenDNS). Nutze ein Propagationstest-Tool für einen globalen Überblick über alle Kontinente.
TTL wieder hochsetzen: Sobald die Änderung bestätigt und der Dienst validiert ist, stelle einen Standard-TTL wieder her (3.600 Sekunden). Behalte die Überwachung 24 Stunden lang bei.

FAQ

Wie lange dauert die DNS-Propagation?

Die Dauer hängt ausschließlich vom TTL (Time To Live) des geänderten Eintrags ab. Bei einem TTL von 300 Sekunden ist die Änderung überall in 5 Minuten sichtbar. Bei einem TTL von 3.600 Sekunden dauert es maximal 1 Stunde. Bei einem TTL von 86.400 Sekunden beträgt die maximale Verzögerung 24 Stunden. Es gibt keinen technischen Grund für eine Verzögerung von 48 Stunden. Der Mythos der "24 bis 48 Stunden" stammt aus einer Zeit, als Standard-TTLs bei 86.400 Sekunden lagen und TLD-Registries ihre Zonen nur alle 12 Stunden aktualisierten.

Wie kann man die DNS-Propagation beschleunigen?

Die effektivste Methode ist, den TTL mindestens 48 Stunden vor der geplanten Änderung auf 300 Sekunden (5 Minuten) zu senken. Sobald der reduzierte TTL propagiert ist, wird jede nachfolgende Änderung in 5 Minuten sichtbar. Ergänzend kannst du den Cache deines lokalen Rechners leeren (ipconfig /flushdns unter Windows, sudo dscacheutil -flushcache unter macOS) und die Purge-Oberflächen von Google Public DNS und Cloudflare nutzen, um eine Neuauflösung auf diesen spezifischen Resolvern zu erzwingen.

Warum funktioniert meine DNS-Änderung nicht?

Die häufigsten Ursachen sind, nach Wahrscheinlichkeit sortiert: (1) die Änderung wurde beim DNS-Anbieter nicht korrekt gespeichert, (2) der negative Cache (NXDOMAIN) hält eine alte Antwort "existiert nicht" fest, (3) der falsche Eintragstyp wurde geändert, (4) die DNSSEC-Kette ist defekt (DS-Eintrag passt nicht mehr zum DNSKEY), (5) ein DNS-Relay im Unternehmen wendet aggressives Caching an. Diagnostiziere, indem du den autoritativen Server direkt mit dig captaindns.com A @ns1.captaindns.com abfragst, um zu prüfen, ob die Änderung quellseitig vorhanden ist.

Was ist der DNS-TTL?

Der TTL (Time To Live) ist ein numerisches Feld, das jedem DNS-Eintrag zugeordnet ist und in Sekunden angegeben wird. Er teilt rekursiven Resolvern mit, wie lange sie eine Antwort im Cache behalten dürfen, bevor sie den autoritativen Server erneut abfragen müssen. Ein TTL von 3.600 bedeutet zum Beispiel, dass der Resolver die gecachte Antwort 1 Stunde lang verwendet. Der TTL wird vom Administrator der DNS-Zone festgelegt, nicht vom Protokoll. Jeder Eintrag kann seinen eigenen TTL haben.

Muss man nach einer DNS-Änderung 24 bis 48 Stunden warten?

Nein. Diese Verzögerung gilt nur, wenn der TTL des geänderten Eintrags 86.400 Sekunden (24 Stunden) beträgt, was dem historischen Standard einiger Registrare entspricht. Bei einem TTL von 3.600 Sekunden (1 Stunde, gängiger Standard 2026) beträgt die maximale Verzögerung 1 Stunde. Durch Vorbereitung der Migration (TTL-Reduktion auf 300 Sekunden 48 Stunden vorher) ist die Änderung in 5 Minuten sichtbar. Die Empfehlung "24 bis 48 Stunden" ist ein vorsorgliches Aufrunden aus den 2000er Jahren, das die aktuelle technische Realität nicht mehr widerspiegelt.

Wie leert man den DNS-Cache?

Der DNS-Cache existiert auf mehreren Ebenen. Um den Cache deines Rechners zu leeren: Unter Windows führe ipconfig /flushdns in PowerShell aus; unter macOS führe sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder im Terminal aus; unter Linux mit systemd führe sudo systemd-resolve --flush-caches aus. Für Chrome gehe auf chrome://net-internals/#dns und klicke "Clear host cache". Um den Cache öffentlicher Resolver zu leeren, nutze die Purge-Oberflächen von Google Public DNS und Cloudflare 1.1.1.1. Der Cache des Resolvers deines Internetproviders kann nicht manuell geleert werden.

Warum liefern DNS-Resolver unterschiedliche Ergebnisse?

Drei Gründe erklären dieses Verhalten. Erstens hat jeder Resolver den Eintrag zu einem anderen Zeitpunkt gecacht, sodass der TTL zu unterschiedlichen Zeitpunkten abläuft. Zweitens nutzen die großen Resolver (Google, Cloudflare) Anycast-Netzwerke mit Hunderten unabhängiger Server; der Server, der Paris bedient, hat nicht denselben Cache wie der, der Tokio bedient. Drittens verwenden einige Domains EDNS Client Subnet (ECS), um geolokalisierte IP-Adressen zurückzugeben, was je nach Standort des Clients legitimerweise unterschiedliche Antworten erzeugt.

Beschleunigt ein Wechsel des DNS-Resolvers die Propagation?

Nein, nicht zuverlässig. Den Resolver auf deinem Rechner zu wechseln (z.B. von 8.8.8.8 auf 1.1.1.1) kann den Eindruck erwecken, die Änderung sei propagiert, wenn der neue Resolver den alten Eintrag nicht im Cache hat. Aber das beschleunigt nichts für andere Nutzer. Die "Propagationsverzögerung" hängt vom TTL des Caches jedes Resolvers ab, und du kannst den Cache des Resolvers, den deine Besucher nutzen, nicht kontrollieren. Die einzige zuverlässige Methode zur Beschleunigung der Propagation ist die TTL-Reduktion vor der Änderung.

Wie prüft man, ob die DNS-Propagation abgeschlossen ist?

Frage mindestens vier große öffentliche Resolver mit dig ab: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) und OpenDNS (208.67.222.222). Wenn alle den neuen Wert zurückgeben, ist die Propagation für die große Mehrheit der Nutzer abgeschlossen. Für eine umfassende Prüfung nutze ein Multi-Resolver-Propagationstest-Tool, das Server auf mehreren Kontinenten abfragt und die Ergebnisse in Echtzeit anzeigt. Solange mindestens ein Resolver den alten Wert zurückgibt, ist die Propagation nicht abgeschlossen.

Glossar

TTL (Time To Live): Dauer in Sekunden, die ein DNS-Resolver einen Eintrag im Cache behalten darf, bevor er ihn erneut beim autoritativen Server abfragen muss. Wird vom Zonenadministrator festgelegt.
Rekursiver Resolver: DNS-Server, der Anfragen von Clients empfängt und die vollständige Auflösung durchführt, indem er die DNS-Hierarchie abfragt (Root, TLD, autoritativ). Beispiele: Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1).
Autoritativer Server: DNS-Server, der die Originaleinträge einer DNS-Zone besitzt. Er ist die Quelle der Wahrheit für die Einträge einer Domain.
DNS-Cache: Temporärer Speicher, in dem ein Resolver bereits erhaltene DNS-Antworten aufbewahrt. Der Cache reduziert die Last auf autoritative Server und beschleunigt die Antworten.
DNS-Zone: Gesamtheit der DNS-Einträge für eine Domain und ihre Subdomains, gehostet auf einem oder mehreren autoritativen Servern.
NS-Eintrag (Name Server): Eintrag, der die autoritativen Server für eine DNS-Zone benennt. Wird sowohl in der übergeordneten Zone (Delegation) als auch in der Zone selbst veröffentlicht.
Stub Resolver: Komponente des Betriebssystems, die DNS-Anfragen an den konfigurierten rekursiven Resolver weiterleitet. Er pflegt einen minimalen lokalen Cache.
SOA (Start of Authority): Pflicht-Eintrag in jeder DNS-Zone, der die Metadaten der Zone enthält (Serial, Refresh, Retry, Expire, negativer TTL).
NXDOMAIN: DNS-Antwort, die anzeigt, dass der angefragte Domainname nicht existiert. Diese Antwort wird gemäß dem im SOA definierten negativen TTL gecacht.
Anycast: Netzwerk-Routing-Technik, bei der dieselbe IP-Adresse von mehreren geografischen Standorten aus angekündigt wird. Öffentliche Resolver nutzen Anycast, um Anfragen an den nächstgelegenen Server zu leiten.

Das Propagationstest-Tool von CaptainDNS fragt Resolver ab, die über alle Kontinente verteilt sind, und zeigt in Echtzeit den Cache-Status für jeden Eintrag an. Nutze es, um zu bestätigen, dass eine DNS-Änderung überall sichtbar ist, bevor du die Migration als abgeschlossen betrachtest.