Sie haben einen A-Datensatz aktualisiert. Ihr neuer Server läuft. Sie navigieren zu Ihrer Domain – und sehen immer noch die alte Website. Oder jemand in einem anderen Land sieht die neue Website, Sie aber nicht. Oder beides geschieht gleichzeitig für verschiedene Benutzer.

Dies ist die DNS-Weitergabe. Es ist kein Fehler und es liegt auch nicht daran, dass Ihr Registrar langsam ist. Hier erfahren Sie genau, was passiert und wie Sie damit umgehen können.

Was ist DNS-Weitergabe?

DNS (Domain Name System) ist eine weltweit verteilte Datenbank, die Domänennamen IP-Adressen zuordnet. Es handelt sich nicht um einen einzelnen Server, sondern um eine Hierarchie aus Tausenden von Resolvern, von denen jeder die Antworten für einen bestimmten Zeitraum zwischenspeichert.

Wenn Sie einen DNS-Eintrag aktualisieren, ändern Sie die Daten auf Ihrem maßgeblicher Nameserver – diejenige, die Ihr Registrar oder DNS-Anbieter kontrolliert. Der Rest des Internets fragt Ihren autorisierenden Server jedoch nicht direkt ab. Sie fragen ihre lokaler rekursiver Resolver (normalerweise von ihrem ISP oder einem öffentlichen DNS-Dienst wie betrieben). 1.1.1.1 oder 8.8.8.8), das über eine eigene zwischengespeicherte Kopie Ihres Datensatzes verfügt.

Unter Weitergabe versteht man den Vorgang, bei dem die zwischengespeicherte Kopie abläuft und durch Ihren neuen Datensatz ersetzt wird.

Die vollständige DNS-Resolver-Kette

Verständnis warum Die Verbreitung braucht Zeit und erfordert ein Verständnis dafür, wie eine DNS-Abfrage tatsächlich funktioniert:

DNS-Resolver-Kettendiagramm, das zeigt, wie eine Abfrage vom Gerät über den ISP-Resolver, Root-Server, TLD-Server zum autorisierenden Nameserver gelangt
Die vollständige DNS-Suchkette. Die Schritte 2–4 werden normalerweise übersprungen, da der rekursive Resolver bereits eine zwischengespeicherte Antwort hat – und genau aus diesem Grund dauert die Weitergabe Zeit.

Schritt 1 – Ihr Browser überprüft seinen lokalen Cache. Moderne Browser speichern DNS-Ergebnisse unabhängig vom Betriebssystem zwischen. Chrome-Cache für 60 Sekunden; Firefox bis zum TTL-Wert. chrome://net-internals/#dns zeigt den aktuellen Cache von Chrome.

Schritt 2 – Ihr Betriebssystem-Stub-Resolver überprüft seinen Cache. Windows, macOS und Linux verfügen alle über einen lokalen DNS-Cache (geleert mit ipconfig /flushdns, dscacheutil -flushcache, oder resolvectl flush-caches bzw.).

Schritt 3 – Ihr rekursiver Resolver wird abgefragt. Dies ist normalerweise der Resolver Ihres Internetdienstanbieters. 1.1.1.1, 8.8.8.8oder ein Unternehmens-DNS-Server. Es verfügt über einen eigenen Cache, der von Ihrem getrennt ist und von allen Benutzern gemeinsam genutzt wird. Wenn 10.000 Personen denselben ISP-Resolver verwenden, werden alle von einer zwischengespeicherten Antwort bedient.

Schritt 4 – Der rekursive Resolver durchläuft die Hierarchie (wenn der Cache leer ist). Es fragt einen Root-Nameserver nach der TLD, den TLD-Server nach dem autorisierenden Nameserver und dann den autorisierenden Server für Ihren Eintrag. Die Antwort wird mit der von Ihnen angegebenen TTL zwischengespeichert.

Die Ausbreitung ist langsam, weil: Schritt 4 wird nur ausgeführt, wenn der Cache des Resolvers abgelaufen ist. Bis dahin wird die alte zwischengespeicherte Antwort bereitgestellt – unabhängig davon, was Sie auf dem autorisierenden Server geändert haben.

TTL: Die Zahl, die alles kontrolliert

TTL (Time To Live) ist ein Wert, den Sie für jeden DNS-Eintrag festlegen und der in Sekunden gemessen wird. Es teilt Resolvern mit, wie lange Ihr Datensatz zwischengespeichert werden soll, bevor er den autorisierenden Server erneut abfragt.

Gemeinsame TTL-Werte:

TTL Sekunden Typische Verwendung
1 Minute 60 Aktive Migrationen, Tests
5 Minuten 300 Vor der Migration (24 Stunden vorher eingestellt)
15 Minuten 900 Häufig geänderte Datensätze
1 Stunde 3600 Standard für die meisten Datensätze
4 Stunden 14400 Stabile Aufzeichnungen
24 Stunden 86400 Standard für viele Anbieter
48 Stunden 172800 Nameserver (NS)-Einträge

Die von Ihnen eingestellte TTL bestimmt die maximal Ausbreitungsfenster. Aber es gibt einen Haken.

Diagramm, das die DNS-Ausbreitungszeit im Vergleich zum TTL-Wert mit den besten, typischen und schlechtesten Szenarios zeigt
Der beste Fall spiegelt Resolver wider, die TTL genau respektieren. Schlimmster Fall: Einige ISP-Resolver puffern weit über die deklarierte TTL hinaus, insbesondere bei kurzen TTLs – und behandeln alles unter 5 Minuten als „5 Minuten“, um die Last zu reduzieren.

Das schmutzige Geheimnis über TTL: Viele ISPs ignorieren niedrige TTL-Werte. Ein Resolver, der Millionen von Benutzern bedient, kann es sich nicht leisten, alle 60 Sekunden eine erneute Abfrage nach Domänen mit hohem Datenverkehr durchzuführen. Einige erzwingen eine Mindestcachezeit von 5 Minuten, unabhängig davon, was Sie angeben. Dies bedeutet, dass sich sehr niedrige TTLs (60–300 Sekunden) in der Praxis für einen Teil der Resolver eher wie 5-Minuten-TTLs verhalten.

Eine 24-Stunden-TTL bedeutet, dass einige Benutzer Ihren alten Datensatz möglicherweise volle 24 Stunden lang sehen, nachdem Sie eine Änderung vorgenommen haben – selbst wenn Sie ihn unmittelbar nach einem vorherigen TTL-Ablauf geändert haben.

Wie lange dauert die DNS-Verbreitung tatsächlich?

Zeitleistendiagramm im Gantt-Stil, das die DNS-Ausbreitung in verschiedenen Weltregionen nach einer DNS-Eintragsänderung zeigt
Regionale Ausbreitungszeitleiste für einen Datensatz mit 1-stündiger TTL. Lokale Resolver werden am schnellsten aktualisiert; Ausreißer-ISPs, die TTL ignorieren, können stundenlang zurückbleiben. Dies erklärt, warum einige Benutzer Ihre neue Website sehen, während andere die alte sehen.

Bei einer Standard-TTL von 1 Stunde können Sie Folgendes erwarten:

  • Ihr lokales Gerät: Fast sofort nach dem Leeren des Caches
  • Gleichstädtische Resolver: 5–30 Minuten (Resolver fragt autorisierend ab, wenn sein Cache abläuft)
  • Wichtiges öffentliches DNS (8.8.8.8, 1.1.1.1): typischerweise 10–60 Minuten
  • Weltweite Verbreitung: 1–4 Stunden für die meisten Benutzer
  • Langsame/Ausreißer-ISPs: bis zu 8–12 Stunden

Die Zahl „bis zu 48 Stunden“, die Sie überall sehen, ist technisch möglich, wird aber bei A- und CNAME-Datensätzen mit normalen TTLs immer seltener. Dies ist genauer für NS-Datensatzänderungen (Nameserver), die längere inhärente TTLs haben und sich über die Root-/TLD-Ebene verbreiten.

Warum speziell 48 Stunden? Für NS-Einträge werden häufig TTLs von der Registry (nicht von Ihnen) festgelegt, üblicherweise 24–48 Stunden. Wenn Sie Ihre Nameserver bei Ihrem Registrar ändern, warten Sie auf die Aktualisierung der TLD-Registrierung – und diese Aktualisierung wird über Root-Server weltweit verbreitet. Dieser Pfad dauert länger als ein einfacher Datensatzwechsel innerhalb eines festen Nameservers.

Der professionelle Ansatz: Senken Sie Ihre TTL vorab

Der größte Fehler, den Menschen bei DNS-Migrationen machen: Datensätze ändern, ohne vorher die TTL zu senken.

Der richtige Prozess für geplante Migrationen:

  1. 48 Stunden vor der Migration: Senken Sie die TTL für alle Datensätze, die Sie ändern möchten, auf 300 Sekunden (5 Minuten).
  2. Warten Sie die volle aktuelle TTL vor dem Migrationsfenster (geben Sie den Resolvern Zeit, sich die neue kurze TTL anzueignen)
  3. Nehmen Sie Ihre Datensatzänderungen vor – Die Ausbreitung dauert jetzt maximal 5 Minuten statt 24 Stunden
  4. Nachdem die Migration stabil ist: Erhöhen Sie die TTL wieder auf 3600 oder höher

Dies ist der Unterschied zwischen einem Ausbreitungsfenster von 5 Minuten und einem 24-Stunden-Fenster. Jeder DNS-Profi macht das. Die meisten Anfänger lernen auf die harte Tour.

So überprüfen Sie jetzt die DNS-Weitergabe

Der schnellste Weg: Nutzen Sie unsere DNS-Verbreitungsprüfer – Es fragt Ihre Domain von mehreren geografischen Standorten gleichzeitig ab und zeigt an, ob jede Region Ihren alten oder neuen Datensatz zurückgibt.

Was Sie suchen:

  • Grün / passende IPs: Diese Regionen sehen Ihren neuen Datensatz
  • Alte IP wird immer noch angezeigt: Der Cache dieser Resolver ist noch nicht abgelaufen
  • Gemischte Ergebnisse: normal während der Ausbreitung – einige Regionen sehen das Neue, andere das Alte

Überprüfung über die Befehlszeile wenn Sie die maßgebliche Antwort direkt überprüfen möchten (unter Umgehung eines Caches):

Befehl 
# Query a specific DNS server directly (bypasses your local cache)
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

# On Linux/macOS — dig gives more detail
dig example.com @8.8.8.8
dig example.com @1.1.1.1

# Check the TTL of your current record
dig example.com | grep -i ttl

# Query the authoritative nameserver directly (no cache)
dig example.com @ns1.yourprovider.com

Wenn dig @ns1.yourprovider.com zeigt Ihren neuen Datensatz an dig @8.8.8.8 zeigt immer noch den alten, Ihre Änderung ist korrekt – Sie warten nur darauf, dass der Cache des rekursiven Resolvers abläuft.

Leeren Sie Ihren lokalen DNS-Cache um die Anzeige veralteter Daten auf Ihrem eigenen Computer zu stoppen:

Befehl 
# Windows
ipconfig /flushdns

# macOS (Sequoia / Sonoma)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Chrome browser cache only
# Navigate to: chrome://net-internals/#dns → click "Clear host cache"

Hinweis: Das Leeren Ihres lokalen Caches hilft nicht, wenn der Resolver Ihres ISP noch immer die alte Antwort zwischengespeichert hat. Ihr Gerät fragt einfach den Resolver Ihres Internetdienstanbieters erneut ab und erhält erneut die veraltete Antwort.

Häufige DNS-Verbreitungsszenarien

Szenario 1: Website-Migration auf einen neuen Server

Sie wechseln vom alten Host zum neuen Host. Alter A-Datensatz: 203.0.113.10. Neu: 198.51.100.20.

Was passiert während der Ausbreitung: Benutzer mit zwischengespeicherten alten Datensätzen landen auf dem alten Server. Benutzer, deren Resolver aktualisiert wurden, sehen den neuen Server. Bis die Weitergabe abgeschlossen ist, müssen beide Server laufen und denselben Inhalt bereitstellen. Wenn Sie den alten Server zu früh herunterfahren, erhalten Benutzer mit veraltetem Cache Fehlermeldungen.

Schadensbegrenzung: Halten Sie den alten Server nach der Änderung für mindestens eine vollständige TTL am Leben. Wenn die ursprüngliche TTL 24 Stunden betrug, halten Sie den alten Server 24 Stunden nach der Änderung betriebsbereit.

Szenario 2: Migration des E-Mail-Anbieters (MX-Eintrag)

MX-Eintragsänderungen wirken sich darauf aus, wohin eingehende E-Mails zugestellt werden. E-Mails, die während der Weitergabe gesendet werden, landen möglicherweise auf dem alten oder neuen Mailserver, je nachdem, welchen MX-Eintrag der sendende Server aufgelöst hat.

Risiko: E-Mails werden an den alten Server zugestellt, nachdem Sie die Überwachung beendet haben. Behebung: Konfigurieren Sie den alten Mailserver so, dass er nach der Migration eine Woche lang an den neuen weiterleitet, oder halten Sie alte Postfächer während des TTL-Fensters zugänglich.

Szenario 3: CDN- oder Load Balancer-Umstellung (CNAME-Änderung)

CNAME-Einträge, die auf ein CDN oder einen Load Balancer verweisen, verbreiten sich normalerweise schneller als A-Einträge – der CNAME selbst speichert den Cache, aber die zugrunde liegende IP, die das CDN zurückgibt, kann sich schnell ändern, ohne die Verbreitung Ihres Eintrags zu beeinträchtigen.

Achten Sie auf: CNAME-Abflachung. Einige DNS-Anbieter „glätten“ CNAME-Einträge am Zonen-Apex (indem sie den CNAME durch den A-Eintrag ersetzen, in den er aufgelöst wird). Dies kann bei Migrationen zu unerwartetem Verhalten führen, wenn der Anbieter die reduzierte IP zwischenspeichert.

Szenario 4: Änderung des Nameservers (NS-Eintrags).

Die langsamste Art der Ausbreitung. Nameserver-Datensätze werden auf der TLD-Registrierungsebene gespeichert (.com, .netusw.) mit von der Registrierung festgelegten TTLs, normalerweise 24–48 Stunden. Sie haben keine Kontrolle über diese TTL.

Wenn Sie Nameserver bei Ihrem Registrar ändern:

  1. Ihr Registrar benachrichtigt die TLD-Registrierung
  2. Registry aktualisiert die Delegation
  3. Das Update der Registrierung verbreitet sich auf allen Root-Nameservern weltweit

Rechnen Sie mit 12–48 Stunden für die vollständige Ausbreitung. Es gibt keinen TTL-Vorabsenkungstrick, der hier hilft.

Checkliste zur Fehlerbehebung

✅ Wenn Ihre DNS-Änderung nicht weitergegeben wird

1. Bestätigen Sie, dass der neue Datensatz auf dem <strong>autorisierenden Server</strong> korrekt ist: <code>dig example.com @ns1.yourprovider.com</code><br> 2. Überprüfen Sie, was mehrere öffentliche Resolver sehen: <a href="/dns-propagation.php">DNS Propagation Tool →</a><br> 3. Leeren Sie Ihren lokalen Cache (Befehle oben) – möglicherweise sehen Sie nur Ihren eigenen veralteter Cache<br> 4. Überprüfen Sie Ihre TTL: <code>dig example.com | grep TTL</code> – wenn es 86400 ist, warten Sie bis zu 24 Stunden<br> 5. Wenn „Authoritative“ korrekt anzeigt, die Resolver jedoch nicht: Warten Sie auf TTL-Ablauf – es gibt nichts anderes zu tun<br> 6. Wenn „Authoritative“ einen falschen Datensatz anzeigt: Sie haben die Änderung beim falschen Anbieter vorgenommen oder sie wurde nicht gespeichert

DNS-Propagierung vs. DNS-Replikation: Der Unterschied

Diese werden oft verwechselt. Sie sind verwandt, aber unterschiedlich:

DNS-Verbreitung = Warten auf Ablauf der rekursiven Resolver-Caches und erneute Abfrage. Dies ist die Verzögerung, die Sie als Benutzer erleben. Sie können es nicht erzwingen. Sie können es nur reduzieren, indem Sie TTL vorab absenken.

DNS-Replikation = Synchronisierung zwischen mehreren autorisierenden Nameservern für dieselbe Zone (z. B. ns1.provider.com und ns2.provider.com). Die meisten DNS-Anbieter replizieren innerhalb von Sekunden. Wenn Sie eine Änderung vornehmen und diese nicht innerhalb von 5 Minuten auf den eigenen Nameservern Ihres Anbieters angezeigt wird, liegt ein Problem auf Anbieterseite vor. Wenden Sie sich an den Support.

Werkzeuge