Die Domain zeigt seit wenigen Minuten auf den neuen Server. Im Büro erscheint bereits die neue Webseite, ein Kunde erreicht dagegen noch die alte Installation und über das Mobilfunknetz sieht das Ergebnis wieder anders aus. Dieses scheinbar widersprüchliche Verhalten ist nach einer DNS-Änderung häufig normal: Verschiedene DNS-Resolver können noch unterschiedlich lange gespeicherte Antworten verwenden.
TTL steht für Time To Live und gibt bei DNS-Einträgen an, wie lange eine Antwort zwischengespeichert werden darf. Technisch bezieht sich der Wert auf DNS-Ressourcendaten beziehungsweise ein Resource Record Set, kurz RRset. Eine niedrige TTL kann Änderungen schneller sichtbar machen, wenn sie rechtzeitig vor der Umstellung gesetzt wurde. Sie erklärt jedoch nicht jede Verzögerung: Fehlerhafte Nameserver, DNSSEC-Probleme, eine falsche Webserverkonfiguration, Zertifikatsfehler sowie Browser- oder CDN-Caches verschwinden nicht allein durch Abwarten.
TTL im DNS: Was die Cache-Zeit tatsächlich bedeutet
DNS übersetzt Namen wie www.example.com in die für einen Dienst benötigten Daten, etwa eine IPv4-Adresse aus einem A-Eintrag oder eine IPv6-Adresse aus einem AAAA-Eintrag. Ein rekursiver DNS-Resolver fragt diese Informationen nicht bei jedem Seitenaufruf vollständig neu bei den zuständigen Nameservern ab. Er speichert eine erhaltene Antwort für die durch die TTL begrenzte Zeit und kann sie bei weiteren Anfragen direkt aus seinem Cache liefern.
Dieses Caching verkürzt wiederholte Namensauflösungen, reduziert den DNS-Verkehr und entlastet die autoritativen Nameserver. Autoritativ bedeutet: Diese Server veröffentlichen die maßgeblichen Daten der DNS-Zone. Der rekursive Resolver eines Internetanbieters, Unternehmens oder öffentlichen DNS-Dienstes beschafft die Antwort und reicht sie an das Endgerät weiter. Das Betriebssystem kann zusätzlich einen lokalen Clientcache führen.
TTL-Werte werden gewöhnlich in Sekunden angegeben
- 300 Sekunden entsprechen fünf Minuten.
- 3600 Sekunden entsprechen einer Stunde.
- 86400 Sekunden entsprechen einem Tag.
Speichert ein Resolver einen A-Eintrag mit 3600 Sekunden TTL, darf er diese Antwort im Normalbetrieb bis zu eine Stunde verwenden. Die angezeigte Rest-TTL sinkt währenddessen. Hat Resolver A den Eintrag vor 50 Minuten abgefragt und Resolver B erst vor fünf Minuten, laufen ihre gespeicherten Antworten zu unterschiedlichen Zeitpunkten ab. Genau dadurch können Nutzer vorübergehend verschiedene Server erreichen.
Niedrige und hohe TTL lösen unterschiedliche Betriebsaufgaben
Eine niedrige TTL verkürzt das reguläre Zeitfenster, in dem ein Resolver einen alten Wert weiterverwenden darf. Das erleichtert geplante IP-, Hosting-, Mail- oder CDN-Wechsel und beschleunigt eine mögliche Rücknahme. Dafür fragen Resolver häufiger nach. Das erhöht das Abfragevolumen und macht die zuverlässige Erreichbarkeit der autoritativen DNS-Infrastruktur wichtiger.
Eine hohe TTL reduziert Abfragen und sorgt häufig dafür, dass Antworten schnell aus einem nahegelegenen Cache kommen. Sie ist bei stabilen Einträgen daher nicht grundsätzlich nachteilig. Änderungen bleiben allerdings länger uneinheitlich sichtbar. Die passende TTL hängt von Änderungsfrequenz, Rückfallanforderungen, DNS-Verfügbarkeit und den zulässigen Werten des jeweiligen Anbieters ab. Eine universell optimale Zahl existiert nicht.
TTL ist eine maximale reguläre Cache-Dauer, keine sekundengenaue weltweite Zusage. Resolver können Einträge früher aus ihrem Cache entfernen oder eigene Obergrenzen anwenden. Bei einer gescheiterten Aktualisierung dürfen entsprechend konfigurierte Resolver unter bestimmten Voraussetzungen sogar abgelaufene Daten vorübergehend als sogenannte Stale-Antwort ausliefern, um einen Ausfall zu überbrücken. Das ist eine Resilienzfunktion und nicht der normale Ablauf einer Migration.
Eine TTL von null signalisiert, dass ein Datensatz nur für die laufende Transaktion verwendet und nicht regulär gespeichert werden soll. Daraus folgt keine empfehlenswerte Standardstrategie für Domainumzüge. Viele Verwaltungsoberflächen erlauben den Wert nicht; zudem steigen Abfragen und Abhängigkeit von der autoritativen Infrastruktur erheblich.
Mehrere Resource Records mit gleichem Namen, Typ und gleicher Klasse bilden ein RRset und besitzen innerhalb dieses Satzes dieselbe TTL. Eine Auflösung kann trotzdem mehrere RRsets durchlaufen. Verweist etwa ein CNAME auf einen anderen Hostnamen, besitzen der CNAME, dessen Ziel sowie die dortigen A- und AAAA-Einträge jeweils eigene Cache-Zeiten. Prüfen Sie bei einem Wechsel deshalb die gesamte Auflösungskette statt nur den sichtbarsten Eintrag.
DNS-Propagation: Warum Änderungen nicht überall gleichzeitig sichtbar sind
„DNS-Propagation“ ist ein gebräuchlicher Sammelbegriff für die verzögerte Sichtbarkeit einer Änderung. Die Vorstellung, ein neuer Eintrag müsse aktiv von Land zu Land an sämtliche DNS-Server verteilt werden, führt jedoch in die Irre. Bei einer Änderung innerhalb einer bestehenden Zone geht es häufig vor allem darum, dass dezentral gespeicherte alte Antworten auslaufen.
Zwei Vorgänge sind zu trennen. Zuerst muss der DNS-Anbieter den neuen Wert auf seinen autoritativen Nameservern veröffentlichen. Danach erhalten Resolver den neuen Wert, sobald sie erneut fragen. Resolver mit einer noch gültigen alten Antwort fragen dagegen zunächst nicht nach. Zeigen bereits die autoritativen Server unterschiedliche Daten, liegt nicht nur ein normaler Cache-Ablauf vor: Die Zone wurde möglicherweise noch nicht überall aktualisiert oder die autoritativen Server sind inkonsistent konfiguriert.
DNS-Antworten können auf mehreren Wegen zwischengespeichert werden
- Rekursiver Resolver: Der Resolver des Internetanbieters, Unternehmens oder gewählten DNS-Dienstes hält Antworten typischerweise im Cache.
- Betriebssystem: Ein lokaler DNS-Clientcache kann kürzlich verwendete Antworten auf dem einzelnen Gerät speichern.
- Browser oder Anwendung: Je nach Implementierung nutzt die Software den Systemresolver, einen eigenen Resolverpfad oder DNS over HTTPS und kann zusätzliche Zustände vorhalten.
- Router oder Forwarder: Ein Heimrouter oder internes Gateway kann DNS-Anfragen weiterleiten und abhängig von seiner Software selbst cachen.
- Unternehmensfilter und Sicherheitsdienste: Schutzsysteme, Proxys oder zentrale DNS-Dienste können den tatsächlich verwendeten Resolverpfad verändern.
Diese Stationen bilden keine universelle feste Kette. Welche Ebene beteiligt ist, hängt von Betriebssystem, Browser, Netzwerk, DNS-over-HTTPS-Einstellung und Unternehmensrichtlinien ab. Das Leeren des lokalen DNS-Caches betrifft daher nur das jeweilige Gerät. Ein vorgeschalteter Resolver kann den alten Wert weiterhin gespeichert haben.
Hosting, E-Mail und CDN reagieren nicht identisch auf alte DNS-Antworten
Bei einem Hosting- oder IP-Wechsel zeigen A- und AAAA-Einträge auf die neue Infrastruktur. Ein Resolver mit alter Antwort führt Nutzer noch zum bisherigen Server. Besonders leicht wird ein vergessener AAAA-Eintrag übersehen: IPv4 verweist bereits auf das neue System, während IPv6 weiterhin das alte Ziel oder einen nicht funktionsfähigen Server erreicht.
Bei einer MX-Umstellung können sendende Mailserver zeitweise noch den bisherigen Mailserver auswählen. Lassen Sie den alten und den neuen Dienst während eines kontrollierten Übergangs erreichbar, sofern die Sicherheits- und Betriebsvorgaben dies zulassen. DNS-TTL allein bestimmt nicht die gesamte Zustelldauer: Bereits gebildete SMTP-Warteschlangen besitzen eigene Wiederholungsintervalle.
Bei einer CDN-Aktivierung verweist häufig ein CNAME auf einen Hostnamen des Anbieters. Dadurch sind mehrere RRsets mit eigenen TTLs beteiligt. Proxybetrieb, interne Routingentscheidungen und anbieterspezifische DNS-Funktionen können den sichtbaren Weg zusätzlich abstrahieren. Die DNS-Umstellung legt dabei fest, welcher Dienst angesprochen wird; sie löscht nicht automatisch bereits gespeicherte Webinhalte im CDN.
Wurde ein falscher Eintrag veröffentlicht und anschließend korrigiert, bleibt die fehlerhafte Antwort bis zum Ablauf ihrer Rest-TTL in betroffenen Resolvercaches. Dasselbe Prinzip gilt für negative Antworten: Hat ein Resolver zuvor NXDOMAIN für einen nicht vorhandenen Namen oder NODATA für einen fehlenden Eintragstyp erhalten, kann er auch diese Information speichern. Ein neu angelegter Datensatz ist dann nicht zwingend sofort sichtbar, obwohl seine eigene TTL niedrig eingestellt wurde.
Für die Diagnose ist die Rest-TTL einer konkreten Resolverantwort deshalb aussagekräftiger als die pauschale Behauptung, eine Änderung benötige weltweit 24 oder 48 Stunden. Solche Zeiträume können als betriebliche Reserve sinnvoll sein, sind aber kein DNS-Gesetz. Maßgeblich sind unter anderem die zuvor gültige TTL, negative Cache-Zeiten, der geänderte Datensatztyp und die konsistente Veröffentlichung auf den autoritativen Servern.
Domainumzug und DNS-Wechsel: TTL mit einem belastbaren Zeitplan steuern
Der häufigste Planungsfehler besteht darin, die TTL erst unmittelbar vor dem Umschalten zu senken. Bereits gespeicherte Antworten behalten die vorherige längere TTL. War bisher ein Wert von 86400 Sekunden gültig, muss die neue kurze TTL mindestens einen vollständigen alten TTL-Zeitraum, also 24 Stunden, vor der eigentlichen Änderung wirksam werden. Zusätzliche 24 bis 48 Stunden Planungsreserve können bei kritischen Diensten sinnvoll sein, sind jedoch keine universelle Protokollvorgabe.
Klären Sie zuerst, was mit „Domainumzug“ gemeint ist. Ein Hostingwechsel bei unveränderter DNS-Zone betrifft meist A-, AAAA- oder CNAME-Einträge. Ein Mailwechsel betrifft vor allem MX sowie zugehörige Hostnamen und Mailrichtlinien. Ein Wechsel des autoritativen DNS-Anbieters verändert dagegen die Nameserverdelegation und kann zusätzlich Glue-Einträge sowie DNSSEC-Daten in der übergeordneten Zone betreffen. Ein reiner Registrartransfer löst nicht automatisch eine Änderung der Website- oder Mailziele aus.
| Phase | Konkrete Prüfung | Erforderliche Aktion | Warnzeichen | Praxisfolge |
|---|---|---|---|---|
| Bestandsaufnahme | Erfassen Sie die aktuell autoritativen Nameserver, die bisherige TTL sowie A, AAAA, CNAME, MX und abhängige Ziele. Prüfen Sie bei einem DNS-Anbieterwechsel zusätzlich Delegation, Glue und DNSSEC. | Dokumentieren Sie alte und neue Werte, testen Sie die Zielsysteme ohne öffentliche DNS-Umschaltung und erstellen Sie einen Rückfallplan. | Unbekannte Einträge, abweichende Zonenstände, ein übersehener AAAA-Eintrag oder unklarer DNSSEC-Status. | Ohne vollständigen Bestand kann eine scheinbar erfolgreiche IPv4- oder Webumstellung andere Zugriffswege und den Mailverkehr beschädigen. |
| Mindestens einen alten TTL-Zeitraum vorher | Ermitteln Sie den bisher veröffentlichten Wert. Bei 86400 Sekunden sind mindestens 24 Stunden erforderlich, bevor die kurze TTL zuverlässig für neue Cache-Abfragen gilt. | Senken Sie die TTL der tatsächlich zu ändernden RRsets auf einen vom Anbieter unterstützten Migrationswert. 300 Sekunden sind ein verbreitetes Beispiel, aber keine Pflichtvorgabe. | Die TTL wird erst wenige Minuten vor dem Wechsel geändert oder nur beim neuen Anbieter eingetragen. | Resolver mit alter Cache-Antwort verwenden weiterhin die vorherige lange TTL; die spontane Absenkung erzeugt keine garantierte Fünf-Minuten-Umstellung. |
| Unmittelbar vor dem Umschalten | Prüfen Sie neuen Webserver, Virtual Host, TLS-Zertifikat, CDN-Origin, Firewall und Mailannahme. Vergleichen Sie die Zone auf allen autoritativen Servern. | Halten Sie alte und neue Infrastruktur parallel betriebsbereit. Sichern Sie Datenänderungen oder synchronisieren Sie sie bis zum Wechsel. | Das neue Ziel liefert die falsche Website, ein ungültiges Zertifikat oder lehnt Anfragen des CDN beziehungsweise eingehende E-Mails ab. | TTL kann ein nicht funktionsfähiges Ziel nicht reparieren. Ein schneller DNS-Wechsel würde den Fehler lediglich schneller sichtbar machen. |
| Umschaltzeitpunkt | Kontrollieren Sie die neuen A-, AAAA-, CNAME- oder MX-Werte direkt auf den autoritativen Nameservern. | Ändern Sie nur die geplanten Datensätze und protokollieren Sie Zeitpunkt sowie alte und neue Werte. Lassen Sie die TTL zunächst niedrig. | Autoritative Server liefern unterschiedliche Antworten, die Zone fehlt oder der neue Wert erscheint nur bei einem einzelnen rekursiven Resolver. | Erst konsistente autoritative Antworten belegen, dass die Änderung veröffentlicht wurde. Öffentliche Resolver zeigen zusätzlich ihren jeweiligen Cache-Zustand. |
| Beobachtungs- und Rückfallfenster | Vergleichen Sie mehrere rekursive Resolver, Rest-TTLs, IPv4 und IPv6 sowie Web-, TLS- und Mailfunktion. Beobachten Sie Fehlerprotokolle beider Systeme. | Betreiben Sie den alten Webserver weiter und lassen Sie den bisherigen Mailserver nach einem festgelegten Konzept annehmen oder weiterleiten. Halten Sie die kurze TTL für eine mögliche Rücknahme. | Einzelne Resolver liefern alte Werte, SERVFAIL tritt auf, Mail bleibt in Warteschlangen oder nur IPv6-Nutzer melden Fehler. | Alte Antworten mit sinkender Rest-TTL sprechen für Cache-Ablauf. SERVFAIL, dauerhaft falsche Antworten oder Dienstfehler erfordern dagegen eine Konfigurationsprüfung. |
| Nameserverwechsel gesondert prüfen | Kontrollieren Sie die NS-Daten der übergeordneten Zone, die Child-Zone, erforderliche Glue-Adressen und bei DNSSEC die DS- und DNSKEY-Kette. | Folgen Sie dem abgestimmten Verfahren von Registrar, Registry und DNS-Anbieter. Halten Sie die alte DNS-Zone während des Delegationsübergangs konsistent erreichbar. | Parent und Child nennen unterschiedliche Nameserver, Glue fehlt oder ein alter DS-Eintrag verweist auf nicht passende Schlüssel. | Die TTL eines Webseiten-A-Eintrags steuert keine Delegationscaches. Ein falscher DS-Eintrag kann bei validierenden Resolvern zu SERVFAIL führen und wird nicht durch Warten korrekt. |
| Stabilisierung und Wiederanhebung | Prüfen Sie, ob autoritative Server konsistent antworten, alte Rest-TTLs ausgelaufen sind und Web-, CDN- sowie Mailbetrieb stabil laufen. | Erhöhen Sie die TTL auf einen zum normalen Änderungsbedarf passenden Betriebswert. Schalten Sie Altsysteme erst nach dem geplanten Übergangs- und Sicherheitsfenster ab. | Die alte Infrastruktur wird entfernt, sobald ein einzelner Testresolver den neuen Wert liefert. | Eine kontrollierte Nachlaufzeit schützt Nutzer und sendende Mailserver, deren Resolver den alten Wert später als Ihre eigenen Tests erneuern. |
Bei einer Webmigration sollte der alte Server während des Cache-Ablaufs weiterhin eine korrekte Antwort liefern. Enthält die Anwendung veränderliche Daten, reicht bloßer Parallelbetrieb nicht aus: Planen Sie Synchronisation, einen kontrollierten Schreibstopp oder eine andere konsistente Übergabestrategie. DNS entscheidet nur, welches Ziel ein Client erreicht; es synchronisiert keine Datenbanken, Uploads oder Sitzungen.
Bei einer Mailmigration benötigen auch die Hostnamen der MX-Ziele korrekte A- und gegebenenfalls AAAA-Einträge. SPF-, DKIM- und DMARC-Anpassungen besitzen eigene DNS-Einträge und Cache-Zeiten. Ändern Sie diese abgestimmt, statt nur den MX-Wert zu betrachten. Der alte Server sollte während des vereinbarten Übergangs E-Mails zuverlässig annehmen oder kontrolliert an das neue System übergeben.
Vor einem CDN-Wechsel müssen Zielhostname, Origin-Zugriff, Host-Header, Zertifikat und Cache-Regeln funktionieren. Eine niedrige DNS-TTL erleichtert die Umschaltung und Rücknahme, ersetzt aber keinen Test des neuen Auslieferungswegs. Prüfen Sie nach dem Wechsel getrennt, ob die DNS-Auflösung auf das CDN zeigt und ob das CDN anschließend die erwartete aktuelle Webantwort ausliefert.
Lassen Sie eine vorübergehend kurze TTL nicht unbeabsichtigt dauerhaft bestehen. Sobald das System stabil ist und kein kurzfristiger Rückfall mehr geplant wird, reduziert ein angemessener höherer Wert die Abfragen. Dokumentieren Sie den normalen Betriebswert und den nötigen Vorlauf für den nächsten Wechsel. Dadurch beginnt eine spätere Migration nicht erneut mit einer unbekannten oder unnötig langen Cache-Zeit.
DNS-Fehler richtig einordnen: Ursachen jenseits der TTL und kompakte FAQ
Ein kurzer Diagnosepfad trennt Cache-Ablauf von Fehlkonfigurationen
- Prüfen Sie die autoritativen Nameserver direkt. Sie müssen den erwarteten Eintrag konsistent liefern. Abweichungen sprechen für eine nicht vollständig veröffentlichte oder falsch konfigurierte Zone.
- Vergleichen Sie mehrere klar benannte rekursive Resolver. Liefert nur ein Teil noch den alten Wert mit plausibler Rest-TTL, ist regulärer Cache-Ablauf wahrscheinlich.
- Beachten Sie Antworttyp und Fehlercode. Eine alte A- oder MX-Antwort ist anders zu bewerten als NXDOMAIN, NODATA oder SERVFAIL.
- Prüfen Sie IPv4 und IPv6 getrennt. Ein veralteter AAAA-Eintrag kann Fehler verursachen, obwohl der A-Eintrag bereits korrekt ist.
- Rufen Sie das neue Ziel technisch getrennt vom DNS auf. Kontrollieren Sie Webserver, Virtual Host, Hostname, SNI und TLS-Zertifikat.
- Untersuchen Sie danach lokale und inhaltliche Caches. Ein lokaler DNS-Flush betrifft nur das Gerät; Browser-, HTTP- und CDN-Caches speichern Inhalte nach eigenen Regeln.
SERVFAIL ist kein gewöhnlicher Hinweis darauf, dass eine Änderung lediglich noch „propagiert“. Nach einem Nameserverwechsel kann beispielsweise ein DS-Eintrag in der übergeordneten Zone nicht mehr zu den DNSKEY-Daten der neuen Zone passen. Validierende Resolver können dann keine gültige DNSSEC-Vertrauenskette bilden. Ebenso können nicht erreichbare autoritative Server, eine fehlende Zone oder dauerhaft fehlerhafte Antworten SERVFAIL auslösen. Solche Ursachen müssen korrigiert werden.
Liefert DNS bereits zuverlässig die neue IP-Adresse, erscheint aber die falsche Website, liegt die Ursache häufig beim Webserver oder vorgeschalteten Proxy. Der Server kann den angefragten Hostnamen dem falschen Virtual Host zuordnen. Zertifikatswarnungen betreffen wiederum TLS, etwa weil das Zertifikat den Hostnamen nicht enthält, die Zertifikatskette fehlt oder das CDN noch nicht korrekt aktiviert wurde. Eine längere Wartezeit ändert diese Konfigurationen nicht.
DNS-TTL und Inhaltscache steuern verschiedene Ebenen. DNS speichert die Zuordnung eines Namens zu Ressourcendaten. Browser-, Reverse-Proxy- und CDN-Caches speichern dagegen HTTP-Antworten wie HTML, Bilder oder Skripte. Ein Nutzer kann deshalb bereits den neuen Server oder das neue CDN erreichen und trotzdem alte Inhalte sehen. Prüfen Sie in diesem Fall HTTP-Cache-Regeln, Cache-Header und gegebenenfalls die vorgesehenen Purge-Funktionen des Dienstes.
Häufige Fragen zu DNS-TTL und verzögerten Änderungen
- Was bedeutet TTL?
TTL steht für Time To Live. Der Wert gibt bei DNS-Einträgen in Sekunden an, wie lange eine Antwort im Normalbetrieb zwischengespeichert werden darf, bevor die Informationsquelle erneut abgefragt werden muss. - Warum ist meine DNS-Änderung nicht sofort sichtbar?
Rekursive Resolver oder lokale Systeme können noch eine gültige alte Antwort besitzen. Zusätzlich benötigt der autoritative DNS-Anbieter möglicherweise kurze Zeit für die Veröffentlichung. Zeigen die autoritativen Server bereits konsistent den neuen Wert, sind unterschiedliche Resolverantworten mit ablaufender Rest-TTL zunächst plausibel. - Was ist ein DNS-Cache?
Ein DNS-Cache speichert erhaltene Namensauflösungen vorübergehend. Dadurch muss ein Resolver nicht bei jeder Anfrage erneut die gesamte DNS-Hierarchie durchlaufen. Auch negative Antworten über nicht vorhandene Namen oder Eintragstypen können gespeichert werden. - Was bedeutet DNS-Propagation?
Der Begriff beschreibt im Alltag die Zeit, bis eine DNS-Änderung weitgehend einheitlich sichtbar ist. Bei Änderungen bestehender Einträge handelt es sich häufig nicht um eine aktive weltweite Verteilung, sondern vor allem um das Auslaufen alter, dezentraler Cache-Antworten. - Sollte die TTL vor einem Umzug gesenkt werden?
Bei geplanten Änderungen ist das häufig sinnvoll. Die Absenkung muss mindestens einen vollständigen Zeitraum der zuvor gültigen TTL vor der Umschaltung wirksam sein. Prüfen Sie außerdem die Mindestwerte und Vorgaben Ihres DNS-Anbieters. - Warum sehen manche Nutzer noch alte Inhalte?
Sie können über einen Resolver mit alter DNS-Antwort noch den bisherigen Server erreichen. Liefert DNS bereits das neue Ziel, kommen auch Browser-, Proxy- oder CDN-Inhaltscaches sowie eine fehlerhafte Webserverzuordnung infrage. - Ist DNS-TTL dasselbe wie CDN-Cache?
Nein. DNS-TTL steuert die Cache-Zeit von DNS-Ressourcendaten. Ein CDN-Cache speichert Webantworten und Dateien nach HTTP- und anbieterspezifischen Regeln. Beide Zeiten können unabhängig voneinander ablaufen. - Wie lange dauert eine DNS-Änderung?
Eine pauschale Dauer gibt es nicht. Entscheidend sind die vor der Änderung gültige TTL, mögliche negative Cache-Zeiten, der Datensatztyp, die Veröffentlichungszeit der autoritativen Server und die Restlaufzeiten einzelner Resolver. Bei Nameserverwechseln kommen Delegations- und DNSSEC-Daten hinzu. Fehlkonfigurationen besitzen keine sinnvolle Wartefrist.
Die entscheidende Handlungsregel: Liefern die autoritativen Nameserver konsistent den neuen Wert und zeigen nur einzelne Resolver noch die alte Antwort mit plausibler Rest-TTL, ist Abwarten bis zum regulären Cache-Ablauf nachvollziehbar. Liefern die autoritativen Server unterschiedliche Daten, tritt SERVFAIL auf oder zeigt die neue IP falsche Inhalte beziehungsweise ein fehlerhaftes Zertifikat, muss die Konfiguration korrigiert werden.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten