DNS-Einträge und TTLs: eine überprüfbare Änderung vorbereiten
DNS teilt Clients mit, wo sie einen Dienst finden. Es verschiebt keine Anwendungsdaten, installiert kein Zertifikat und macht keinen neuen Server bereit. Eine zuverlässige Änderung beginnt mit einer Bestandsaufnahme der Einträge und endet sowohl mit DNS-Nachweisen als auch mit einer funktionierenden Anwendung.
Das Wichtigste in Kürze
Ändern Sie die Einträge, die den Dienst tatsächlich steuern, berücksichtigen Sie bestehende Cache-Laufzeiten, prüfen Sie autoritative und rekursive Antworten getrennt und behalten Sie den bisherigen Endpunkt unter Kontrolle.
Wissen, welchen Beitrag jeder Eintrag leistet
| Typ | Zweck | Vor einer Hosting-Änderung prüfen |
|---|---|---|
| A | Ordnet einem Namen eine IPv4-Adresse zu | Das Ziel stellt den vorgesehenen Hostnamen und die HTTPS-Konfiguration bereit |
| AAAA | Ordnet einem Namen eine IPv6-Adresse zu | IPv6 erreicht denselben funktionierenden Dienst wie IPv4 |
| CNAME | Aliast einen Namen einem anderen Namen zu | Das Ziel ist ein Hostname, keine IP-Adresse oder vollständige URL |
| MX | Kennzeichnet Ziele für die Mailzustellung | Website-Änderungen leiten eingehende Mail nicht unbeabsichtigt um |
| TXT | Enthält Verifizierungs- und andere Textrichtlinien | Erforderliche Eigentums- und Mail-Authentifizierungseinträge bleiben intakt |
| CAA | Schränkt die Ausstellung durch Zertifizierungsstellen ein | Der vorgesehene Zertifikatsaussteller ist mit der Richtlinie kompatibel |
Beispielsweise kann example.com einen A-Eintrag haben und www.example.com ihn über einen CNAME als Alias darauf verweisen. Prüfen Sie beide benutzerseitigen Namen. Eine Adressänderung für den ersten kann den Alias beeinflussen, während ein unabhängiger Hostname weiterhin direkt auf den alten Server zeigen kann. Alias-Funktionen für die Zonen-Apex unterscheiden sich je nach DNS-Anbieter; folgen Sie dessen dokumentiertem Mechanismus, statt anzunehmen, dass jede Oberfläche einen gewöhnlichen Apex-CNAME akzeptiert.
Lassen Sie keinen alten AAAA-Eintrag zurück, wenn sich das IPv4-Ziel verschiebt. Einige Clients erreichen möglicherweise weiterhin den veralteten IPv6-Dienst, während andere die neue IPv4-Adresse verwenden. Bestätigen Sie die vorgesehene IPv6-Verfügbarkeit, bevor Sie diesen Pfad veröffentlichen. Ebenso ist ein Website-Umzug kein Grund, MX- oder TXT-Einträge zu ersetzen, wenn der Mail-Dienst bleibt, wo er ist.
Antworten einplanen, die bereits in Caches liegen
TTL gibt einer DNS-Antwort eine Cache-Lebensdauer. Eine Verkürzung im autoritativen Record verkürzt keine ältere Antwort, die bereits anderswo im Cache liegt. Wenn der bestehende Wert 86.400 Sekunden beträgt und Sie für einen geplanten Wechsel einen Wert von 300 Sekunden wünschen, senken Sie ihn rechtzeitig genug, damit die vorherige Lebensdauer abläuft. Diese Werte dienen der Planung; die verfügbaren Optionen hängen vom DNS-Dienst und dem Record ab.
DNS kann auch eine Antwort cachen, die besagt, dass ein Name nicht existiert oder keinen angeforderten Record hat. Dieser negative Cache richtet sich nach den DNS-Regeln und Zoneninformationen, nicht nach der TTL eines Records, den Sie später hinzufügen. Vermeiden Sie, dies erst bei einem Launch zu entdecken, indem Sie den neuen Hostnamen erst testen, nachdem er bewusst veröffentlicht und im Plan berücksichtigt wurde.
Eine TTL ist kein Countdown bis zu einem weltweit gleichzeitigen Wechsel. Clients, rekursive Resolver und bestehende Anwendungsverbindungen aktualisieren sich nicht alle gemeinsam. Halten Sie den vorherigen Endpunkt während der Überlappung unter Kontrolle. Wenn die Anwendung Schreibvorgänge akzeptiert, muss der Migrationsplan eine einzige Datenautorität festlegen, solange der Traffic noch an mehr als eine Adresse gelangen kann.
Prüfen Sie die DNS-Antwort, dann den Dienst dahinter
- Halten Sie den vorherigen Wert und den exakt beabsichtigten Ersatz fest.
- Fragen Sie jeden autoritativen Nameserver nach dem betroffenen Namen und Record-Typ ab.
- Vergleichen Sie Antworten von mehr als einem rekursiven Resolver und notieren Sie verbleibende TTLs.
- Prüfen Sie jeden tatsächlich veröffentlichten öffentlichen Hostnamen und beide IP-Familien.
- Testen Sie HTTPS und repräsentatives Anwendungsverhalten mit dem echten Hostnamen.
- Beobachten Sie Resttraffic, bevor Sie die TTL erhöhen oder den alten Endpunkt außer Betrieb nehmen.
Unterscheiden Sie einen autoritativen Fehler von einer gecachten alten Antwort. Wenn die autoritativen Server voneinander abweichen, untersuchen Sie die Zonenveröffentlichung oder Delegation. Wenn die Autorität korrekt ist, ein Resolver aber noch eine ältere Antwort hat, vergleichen Sie deren verbleibende Lebensdauer, bevor Sie eine weitere unabhängige Änderung vornehmen. Wiederholtes Ändern von Werten kann das Beobachtungsfenster schwerer interpretierbar machen.
Eine korrekte Adressantwort beweist weder ein gültiges Zertifikat noch einen funktionierenden virtuellen Host. HTTPS verwendet den angeforderten Hostnamen, und die Anwendung muss ihn erkennen. Wenn ein Proxy oder CDN Teil des Designs ist, müssen Sie verstehen, welche zurückgegebene Adresse diesen Vermittler repräsentiert und welche Origin-Einstellung sein Backend steuert. Behalten Sie das DNS-Ergebnis und den Origin-Diensttest als getrennte Prüfungen bei.
Schützen Sie die DNSSEC-Validierung und halten Sie den Rollback realistisch
Wenn DNSSEC aktiviert ist, muss eine Migration von Nameservern oder Signaturanbietern den DS-Record der übergeordneten Zone und die neuen Signaturschlüssel berücksichtigen. Eine Abweichung kann dazu führen, dass validierende Resolver Antworten ablehnen. Befolgen Sie das dokumentierte Migrationsverfahren für beide Anbieter und die Registrierungsstelle, einschließlich der geltenden Cache-Lebensdauern. Löschen Sie keine Vertrauensrecords und deaktivieren Sie die Validierung nicht als improvisierte erste Reaktion auf einen unerklärlichen Webfehler.
Bewahren Sie die vorherigen DNS-Werte zusammen mit dem Änderungsdatensatz auf, aber bedenken Sie, was sie rückgängig machen können. Das Wiederherstellen einer alten Adresse ändert, wohin künftige Auflösungen führen; es kopiert keine Kundendaten zurück, die von der neuen Anwendung angenommen wurden. Legen Sie mit dem separaten Migrationsplan fest, wann ein Traffic-Rollback sicher ist und wann ein Datenabgleich erforderlich ist. Schließen Sie erst ab, nachdem die Anwendung, Mail-Abhängigkeiten und Wiederherstellungskopien geprüft wurden.
