Stellen Sie sich vor, die Serveradresse einer Domain wurde geändert: Zu Hause öffnet sich die neue Website, doch das Telefon verbindet sich noch mit dem alten Server. Auch bei gleichem Namen können die Ergebnisse vorübergehend abweichen, wenn die Geräte unterschiedliche DNS-Caches verwenden. Ein HTTP-Cache für heruntergeladene Seiten und ein DNS-Cache zur Ermittlung einer Verbindungsadresse erfordern unterschiedliche Prüfungen.
Dieser Artikel verfolgt den fiktiven Bibliothekshost www.library.example, um Namensauflösung und Caching zu erklären. Namen und Zeitplan dienen der Veranschaulichung; Antworten eines realen Dienstes wurden nicht gemessen. Wir unterscheiden, wie DNS Adressen liefert, warum Änderungen verzögert erscheinen und welche Fehler erst nach der Namensauflösung auftreten.
1. DNS liefert zu jedem Namen verschiedene Antworttypen
DNS stellt Informationen zu Domainnamen als verschiedene Ressourceneinträge bereit. A steht für eine IPv4-Adresse, AAAA für eine IPv6-Adresse; ein Name kann mehrere Adressen haben. CNAME ist ein Alias für einen anderen Namen, MX bezeichnet einen Server zum Empfang von E-Mails und NS einen autoritativen Nameserver für die Zone. Die Antwort zum gleichen Namen kann sich daher je nach angefragtem Eintragstyp unterscheiden.
Wie Cloudflares Erklärung der DNS-Eintragstypen beschreibt, enthält CNAME einen anderen Namen, keine IP-Adresse. Um eine Adresse zu erhalten, muss gegebenenfalls auch dieser Name aufgelöst werden. Bei https://www.library.example/books behandelt DNS den Hostnamen www.library.example. Weder der Pfad /books noch der Seiteninhalt werden in DNS eingetragen. Ein CNAME erzeugt nicht automatisch eine HTTP-Weiterleitung, die die Adresszeile des Browsers verändert.
2. Wie ein rekursiver Resolver autoritative Server findet
Die Namensauflösung eines Geräts fragt normalerweise den konfigurierten rekursiven Resolver. Dieser nutzt vorhandene Cacheinformationen oder fragt weitere DNS-Server ab und liefert die abschließende Antwort oder einen Fehler. Der DNS-Terminologiestandard RFC 9499 unterscheidet diese Auflösung im Auftrag des Clients von der Rolle eines autoritativen Servers, der Informationen über seine eigene Zone besitzt. Die Herkunft einer Antwort muss anhand der jeweiligen Serverrolle gelesen werden.
In einem vereinfachten Ablauf ohne Cache und Zwischenstellen erhält der Resolver vom Root einen Verweis auf die Server der Top-Level-Domain und von dort auf die autoritativen Server der Zielzone. Vom abschließenden autoritativen Server erhält er den gewünschten Eintrag oder Alias. Ein einzelner Rootserver speichert nicht die IP-Adressen sämtlicher Websites. Tatsächlich kann die Auflösung mit gespeicherten Delegationsinformationen beginnen oder an einen weiteren Resolver weitergereicht werden; nicht jeder Besuch wiederholt die gesamte Folge.
3. TTL ist verbleibende Cachezeit, keine weltweite Uhr
Die TTL eines Eintrags übermittelt dessen Cachelebensdauer in Sekunden. Bei gewöhnlichen Cacheantworten nimmt die verbleibende Zeit während der Speicherung ab. Speichert ein Resolver um 10:00 eine Adresse mit TTL 300 Sekunden, bleiben bei einer Antwort aus derselben Kopie um 10:02 ungefähr 180 Sekunden. Die folgende Tabelle setzt einen einzelnen Resolver ohne erneute Abfrage, vorzeitige Aktualisierung oder Ausgabe veralteter Antworten voraus.
| Fiktive Uhrzeit | Adresse beim autoritativen Server | Verhalten dieses Resolvers |
|---|---|---|
| 10:00 | Alte Adresse | Speichert die alte Adresse mit TTL 300 Sekunden |
| 10:01 | Auf neue Adresse geändert | Die gespeicherte Kopie hat noch 240 Sekunden |
| 10:03 | Neue Adresse | Kann die alte Adresse für die verbleibenden 120 Sekunden wiederverwenden |
| Erste Abfrage nach 10:05 | Neue Adresse | Annahme: erneute Abfrage statt der abgelaufenen Kopie liefert die neue Adresse |
Andere Resolver könnten den Eintrag später gespeichert oder noch nie gesehen haben. Ihre Aktualisierungen erfolgen zu unterschiedlichen Zeiten; eine TTL legt deshalb keinen weltweiten gleichzeitigen Wechsel fest. Ein Cache kann Daten vor Ablauf verwerfen, und das Neuladen einer Webseite löscht nicht die Kopie eines gemeinsam genutzten Resolvers. TTL erklärt die Wiederverwendung von DNS-Antworten, begrenzt aber nicht die gesamte Webverbindung oder Bildschirmaktualisierung.
4. Wann die TTL zu senken ist und wie eine Abwesenheit gespeichert wird
Ein Cache, der die alte Adresse mit TTL 3.600 Sekunden erhalten hat, erfährt nicht sofort, dass der Betreiber sie jetzt auf 60 Sekunden senkt. Passen Sie bei geplanten Änderungen die TTL im Voraus an und berücksichtigen Sie Antworten, die noch mit der früheren längeren Lebensdauer gespeichert sind. Eine niedrigere TTL kann häufigere Änderungsprüfungen bewirken, erhöht aber Abfragelast und Abhängigkeit von autoritativen Servern. Prüfen Sie Änderungsplan und Störungsreaktion gemeinsam, statt allen Diensten denselben kurzen Wert zu geben.
Auch NXDOMAIN für einen nicht existierenden Namen und NODATA für einen vorhandenen Namen ohne Einträge des angefragten Typs können gecacht werden. Der Standard für negatives Caching RFC 2308 bestimmt diese Lebensdauer aus dem kleineren Wert von SOA-Eintrags-TTL des autoritativen Servers und dem SOA-Feld MINIMUM. Deshalb kann eine frühere Fehlanzeige unmittelbar nach dem Anlegen eines Hosts fortbestehen. Wer dafür dieselbe Lebensdauer wie für den neuen A-Eintrag annimmt, kann die Ursache übersehen.
5. Bei Prüfungen Namen, Typ und Server konstant halten
Notieren Sie den genauen abgefragten Namen, den Typ wie A oder AAAA, den befragten DNS-Server und die Uhrzeit. Wenn dig installiert ist, lassen sich Name und Typ mit dig example.com A angeben. Ersetzen Sie bei einem echten Problem example.com durch den zu prüfenden Host. Dieser Befehl veranschaulicht das Vorgehen; er wurde für diesen Artikel weder ausgeführt noch zur Messung von Antwortzeiten verwendet.
Lesen Sie Antwortstatus sowie Namen, Typen, Werte und TTL in ANSWER gemeinsam. Prüfen Sie bei derselben wiederholten Anfrage an denselben Resolver, ob die TTL sinkt; ein Anstieg ist aber nicht sofort ein Fehler. Eine vorzeitige Aktualisierung oder ein anderer antwortender Cacheknoten kann ihn erklären. Getrennte Aufzeichnungen für A und AAAA zeigen leichter, welche Adressfamilie abweicht.
Als Betreiber können Sie die Antwort Ihres rekursiven Resolvers mit der des autoritativen Servers Ihrer Zone für denselben Namen und Typ vergleichen. Prüfen Sie bei Abweichungen nacheinander restliche Cachezeit, Datenkonsistenz zwischen autoritativen Servern und Delegationseinstellungen. Verallgemeinern Sie die Antwort eines öffentlichen Resolvers nicht auf alle Nutzer. Internes Unternehmens-DNS oder eigene DNS-Einstellungen des Browsers können den Abfrageweg verändern; notieren Sie daher auch die Verbindungsumgebung.
6. DNS-Fehler, Verbindungsfehler und Ausnahmen unterscheiden
NXDOMAIN meldet, dass der Name nicht existiert; NODATA bezeichnet den fehlenden angefragten Eintragstyp. SERVFAIL bedeutet dagegen, dass der Server die Anfrage nicht verarbeiten konnte. Ein Timeout besagt, dass innerhalb der Wartezeit keine Antwort ankam. Deuten Sie nicht alle Fälle als gelöschte Domain. Halten Sie zuerst fest, ob es einen Antwortcode gab und welcher Server befragt wurde, um die nächste Prüfung festzulegen.
Eine alte Antwort nach TTL-Ablauf verletzt nicht immer die Regeln. Das serve-stale-Verfahren in RFC 8767 beschreibt, wie abgelaufene Informationen die Verfügbarkeit verbessern können, wenn die Aktualisierung bei autoritativen Servern ausnahmsweise unmöglich ist. Nicht alle Resolver verwenden dafür dieselben Einstellungen. Prüfen Sie das Verhalten des tatsächlich verwendeten Resolvers, statt aus einer einzelnen TTL eine sichere Änderungsfrist abzuleiten.
Schließlich garantiert eine korrekte Adressauflösung keinen erfolgreichen Websitezugriff. Netzwerkweg, TLS-Zertifikat, Webserver und Anwendung sind eigene Stufen. Liefert DNS die erwartete Adresse, aber die Seite öffnet sich nicht, untersuchen Sie die nachfolgende Verbindung. Getrennte Aufzeichnungen von DNS- und Webantwort helfen, den Fehler einzugrenzen, bevor Sie wahllos Seitencaches löschen oder DNS-Einstellungen ändern.