Was tun, wenn DNS-Änderungen nicht wirksam werden

Eine DNS-Änderung, die nicht wirksam zu werden scheint, gehört zu den häufigsten Ärgernissen im Infrastruktur-Alltag -- vor allem, weil das zugrunde liegende System (verteiltes Caching mit Ablauf pro Record) unsichtbar bleibt, bis man gezielt danach sucht.

Gehen Sie das durch, bevor Sie einen Defekt annehmen

1. Bestätigen Sie, dass die Änderung auf der autoritativen Seite tatsächlich gespeichert wurde -- fragen Sie die autoritativen Nameserver der Domain direkt ab statt eines allgemeinen öffentlichen Resolvers, um ein stillschweigend fehlgeschlagenes Speichern oder eine noch nicht synchronisierte Anbieter-Infrastruktur auszuschließen.
2. Prüfen Sie die vorherige TTL des Records -- war sie etwa auf 86400 Sekunden (24 Stunden) gesetzt, fragt ein Resolver, der die alte Antwort Minuten vor Ihrer Änderung gecacht hat, bis zu einen ganzen Tag lang nicht erneut nach.
3. Schließen Sie einen DNS-Cache auf Browser- oder Betriebssystemebene aus -- diese liegen noch näher bei Ihnen als der konfigurierte Resolver und können eine Antwort unabhängig von ihm vorhalten.
4. Vergewissern Sie sich, dass Sie den Record geändert haben, den Sie ändern wollten -- ein überraschend häufiger Fehler ist, versehentlich eine Staging- oder Nicht-Produktiv-DNS-Zone zu bearbeiten.
5. Prüfen Sie von mehr als einem Standpunkt aus -- dass ein einzelner Resolver die alte Antwort zeigt, sagt nichts darüber, ob sich die Änderung anderswo bereits verbreitet hat.

Eine weniger offensichtliche Ursache: ein zurückhängender sekundärer oder Slave-Nameserver

Größere DNS-Setups betreiben oft einen primären (oder „Master“-)Nameserver, auf dem die Änderungen tatsächlich vorgenommen werden, und einen oder mehrere sekundäre („Slave“-)Nameserver, die die Zone regelmäßig per Zonentransfer von ihm kopieren. Hat ein Sekundärserver den letzten Transfer noch nicht übernommen -- wegen eines falsch konfigurierten Transferplans, eines Netzwerkproblems zwischen Primär- und Sekundärserver oder schlicht, weil das Transferintervall noch nicht abgelaufen ist --, erhalten Resolver, die zufällig genau diesen Sekundärserver abfragen, weiterhin die alte Antwort, obwohl der Primärserver selbst vollständig aktuell ist und das TTL-basierte Caching aller Resolver abgelaufen ist. Das ist seltener die Ursache als einfaches Caching, sollte aber gezielt ausgeschlossen werden, wenn verschiedene autoritative Nameserver derselben Domain einander widersprechen und nicht nur öffentliche Resolver.

Vorausplanung vermeidet das meiste davon

Bei einer geplanten Änderung -- einer Migration, einem Anbieterwechsel, einem Cutover -- ist es der wirkungsvollste Einzelschritt, die TTL ein bis zwei Tage vorher zu senken. Das kostet etwas zusätzliches Abfragevolumen und sorgt dafür, dass sich die Änderung später in Minuten statt womöglich einem ganzen Tag verbreitet. Setzen Sie sie, warten Sie das alte TTL-Fenster vollständig ab, nehmen Sie die Änderung vor und erhöhen Sie die TTL wieder, sobald Sie bestätigt haben, dass alles stimmt.

Den eigenen lokalen Cache leeren, wenn er wirklich der Übeltäter ist

Stimmen die autoritativen Nameserver und jeder von Ihnen geprüfte öffentliche Resolver bereits in der neuen Antwort überein, doch ein bestimmter Rechner zeigt noch die alte, ist dessen eigener lokaler Cache der verbleibende Verdächtige.

Es lohnt sich, diese erst zu prüfen, nachdem Sie bestätigt haben, dass die autoritative Seite bereits korrekt ist -- einen lokalen Cache zu leeren, wenn sich der eigentliche Record noch gar nicht aktualisiert hat, liefert nur eine frische Kopie derselben alten Antwort und sieht aus, als wäre das Leeren fehlgeschlagen.