DNS beantwortet Fragen zu Namen.
Du gibst www.example.com im Browser ein. Für eine Verbindung braucht der Rechner eine passende Zieladresse. Das Domain Name System (DNS) liefert dazu strukturierte Einträge. Die Frage enthält einen Namen und einen Typ: Ein A-Eintrag beschreibt eine IPv4-Adresse, ein AAAA-Eintrag eine IPv6-Adresse. DNS kann außerdem Mailserver, Aliasnamen und weitere Informationen nennen. Es ist eine verteilte Datenbank, kein Verzeichnis fertiger Webseiten.
Der Namensraum ist hierarchisch aufgebaut. Von rechts gelesen steht über com die Wurzel, die Root. Darunter folgen die Top-Level-Domain com, die Domain example.com und der Name www.example.com. Vollständig geschrieben endet der Name mit einem Punkt: www.example.com.. Die Domain bezeichnet einen Teil dieses Baums. Eine Zone ist der administrativ verwaltete Ausschnitt, für den ein autoritativer Server Daten bereithält. Domain und Zone sind deshalb nicht immer deckungsgleich: Unterbereiche können an andere Server delegiert sein.
Ein Name kann mehrere A- und AAAA-Einträge haben. Umgekehrt können mehrere Namen dieselbe Adresse verwenden. DNS sagt auch nicht, ob der Webserver erreichbar ist oder welchen Inhalt er später ausliefert. IPv4-Grundlagen und IPv6 erklären die beiden Adressformate.
Der Resolver übernimmt die Suche.
Eine Anwendung verwendet häufig den Stub-Resolver des Betriebssystems. Dieser schlanke Client fragt einen konfigurierten rekursiven Resolver. Dessen Adresse kann zum Beispiel durch DHCP bekannt sein. Anwendungen können auch eigene Resolver und Caches verwenden; der genaue lokale Weg hängt vom System ab.
Eine rekursive Anfrage verlangt vom angesprochenen Resolver ein fertiges Ergebnis oder eine Fehlermeldung. Der Resolver kann selbst suchen oder einen weiteren Resolver als Forwarder nutzen. Bei einer eigenen Suche stellt er iterative Anfragen: Der befragte Server liefert eine Antwort oder verweist auf zuständige Nameserver. Der Resolver folgt diesen Verweisen. Die Root fragt dabei nicht stellvertretend die TLD, und die TLD lädt keine Daten vom Webserver.
Ohne verwertbaren Cache fragt der rekursive Resolver einen Root-Server nach der Zuständigkeit. Er erhält einen Verweis auf Nameserver für .com. Ein solcher TLD-Server verweist auf die autoritativen Nameserver für example.com. Ein zuständiger autoritativer Server liefert schließlich die Daten für www.example.com, sofern der angefragte Eintrag vorhanden ist. Delegationsantworten können zusätzlich Adressen von Nameservern als Glue enthalten, damit der Resolver die nächsten Server erreichen kann.
In der Praxis kennt der Resolver oft bereits die .com-Server oder die zuständige Zone. Dann beginnt er dort. Liegt die eigentliche Antwort noch gültig im Cache, muss er keinen dieser Server fragen. Moderne Resolver können die übermittelten Namen bei der Suche außerdem auf die jeweils nötigen Namensbestandteile begrenzen. Die Grafik zeigt die Rollen, keinen vollständigen Paketmitschnitt.
Der Record-Typ bestimmt die Bedeutung.
Ein Resource Record verbindet einen Namen mit einem Typ, einer Klasse, einer TTL und typabhängigen Daten. Eine Antwort kann mehrere zusammengehörige Einträge enthalten. „Welche Adresse hat der Name?“ und „Welcher Server nimmt E-Mails an?“ sind verschiedene DNS-Fragen.
| Typ | Bedeutung |
|---|---|
| A | Ordnet einem Namen eine IPv4-Adresse zu. |
| AAAA | Ordnet einem Namen eine IPv6-Adresse zu. |
| CNAME | Verweist als Alias auf einen anderen Namen; dieser muss gegebenenfalls weiter aufgelöst werden. |
| MX | Nennt einen Mailserver-Namen und dessen Priorität. Eine kleinere Zahl wird bevorzugt. |
| NS | Nennt einen zuständigen Nameserver für eine Zone beziehungsweise Delegation. |
| PTR | Verweist auf einen Namen, häufig bei der Rückwärtsauflösung einer Adresse. |
| TXT | Enthält Textdaten, deren Bedeutung das jeweilige Verfahren festlegt, etwa bei einer Domainverifikation. |
| SOA | Enthält Verwaltungsdaten der Zone, unter anderem eine Seriennummer und Zeitparameter. |
Ein MX-Eintrag ist keine IP-Adresse, ein CNAME keine HTTP-Weiterleitung. Auch ein erfolgreicher PTR-Nachschlag beweist weder die Identität noch die Vertrauenswürdigkeit eines Geräts.
Von www.example.com zur Verbindung.
Für unser ausdrücklich erfundenes DNS-Ergebnis nehmen wir an, dass eine A-Anfrage nach www.example.com. den Wert 192.0.2.80 mit TTL 300 liefert. Die Domain und die Adresse dienen der Dokumentation; dies ist keine Behauptung über aktuelle öffentliche DNS-Daten. Der rekursive Resolver gibt das Ergebnis an den Client zurück und kann es zwischenspeichern.
Der Browser besitzt jetzt eine mögliche Zieladresse. Für eine HTTPS-Seite baut er anschließend eine Verbindung zum Webdienst auf, beispielsweise über TCP und TLS oder über QUIC. Erst danach werden HTTP-Anfragen und Webinhalte übertragen. Welche Route zur Adresse verwendet wird, ist eine Frage des Routings. DNS überträgt hier weder HTML noch Bilder und garantiert keinen erfolgreichen Verbindungsaufbau.
Eine zusätzliche AAAA-Abfrage kann IPv6-Adressen liefern. Der Client entscheidet nach seinen Verbindungsverfahren und verfügbaren Wegen, welche Adresse er verwendet. Eine Domain muss also weder genau eine Adresse haben noch ausschließlich über IPv4 erreichbar sein.
TTL ist keine globale Umschaltuhr.
Die Time to Live gibt in Sekunden vor, wie lange eine empfangene Information regulär im Cache verwendet werden darf. Beim Weitergeben aus einem Cache sinkt die verbleibende TTL. Im Beispiel darf ein frisch empfangener Eintrag normalerweise bis zu 300 Sekunden wiederverwendet werden. Verschiedene Resolver haben ihn zu unterschiedlichen Zeitpunkten erhalten und behalten ihn nicht zwingend gleich lange.
Eine DNS-Änderung löscht deshalb nicht gleichzeitig alle Caches. Ein vorheriger TTL-Wert wirkt für bereits gespeicherte Antworten weiter. Zusätzlich kann ein Resolver unter den Bedingungen von Serve Stale abgelaufene Daten übergangsweise ausliefern, wenn frische Daten nicht erreichbar sind. Das ist eine definierte Ausfallschutzfunktion, kein Beleg für eine unendliche TTL.
Auch negative Antworten können zwischengespeichert werden. NXDOMAIN bedeutet, dass der abgefragte Name nicht existiert. NODATA bedeutet dagegen: Der Name existiert, aber der angefragte Record-Typ fehlt. Ein Timeout liefert gar keine verwertbare Antwort; SERVFAIL meldet ein Problem bei der Bearbeitung, etwa eine fehlgeschlagene DNSSEC-Validierung. Diese Ergebnisse haben unterschiedliche Ursachen und dürfen nicht als „Domain fehlt“ zusammengefasst werden.
DNS nutzt mehr als UDP.
Klassisches DNS nutzt UDP und TCP, üblicherweise mit Zielport 53. UDP ist für viele kleine Abfragen praktisch. TCP ist ein regulär unterstützter Transport, nicht allein für Zonentransfers gedacht. Ist eine UDP-Antwort als abgeschnitten markiert, kann der Client die vollständige Antwort über TCP abrufen. Eine Firewall, die nur UDP 53 zulässt, kann daher scheinbar zufällige DNS-Probleme verursachen.
DNS over TLS (DoT) schützt DNS-Nachrichten mit TLS, typischerweise über TCP 853. DNS over HTTPS (DoH) überträgt sie über HTTPS. Der Schutz gilt für die jeweilige Verbindung, etwa vom Client zum rekursiven Resolver. Er bedeutet nicht automatisch, dass jede nachfolgende Anfrage dieses Resolvers ebenfalls verschlüsselt ist.
DNSSEC verfolgt ein anderes Ziel: Signierte DNS-Daten lassen sich auf Herkunft und Unverändertheit prüfen, wenn eine gültige Vertrauenskette besteht. DNSSEC verschlüsselt die Anfragen nicht. DoT und DoH ersetzen diese Datenprüfung nicht; DNSSEC ersetzt keine Transportverschlüsselung.
Erst den Fehler eingrenzen, dann den Cache leeren.
Kontrolliere zunächst, ob der richtige Name und Record-Typ abgefragt werden und welchen Resolver der Rechner tatsächlich verwendet. Ein VPN oder ein Browser mit eigenem DoH kann andere Antworten erhalten als ein Werkzeug, das den Systemresolver nutzt. Interne Namen können absichtlich nur im Firmennetz auflösbar sein.
Mit nslookup www.example.com oder, falls installiert, dig www.example.com A untersuchst du die Namensauflösung. Ein gezielter Vergleich mit einem ausdrücklich gewählten Resolver hilft, lokale Konfiguration und DNS-Daten zu unterscheiden. Ein dig +trace verfolgt Delegationen direkt; es bildet nicht automatisch den Weg des konfigurierten rekursiven Resolvers nach.
Ein Timeout lenkt den Blick auf Erreichbarkeit, Filter und Serverbetrieb. NXDOMAIN lenkt ihn auf Name, Zone und negative Caches. SERVFAIL erfordert unter anderem einen Blick auf Delegation, Erreichbarkeit und Validierung. Löst ein Name korrekt auf, scheitert aber die Website, prüfst du anschließend Verbindung, TLS und Webdienst. Eine Website per bloßer IP zu testen kann wegen Zertifikaten und namensabhängiger Auslieferung irreführend sein.
Zwei Fälle selbst erklären.
Ein Resolver hat die A-Antwort für unseren Beispielnamen vor 60 Sekunden mit TTL 300 erhalten. Die Antwort liegt noch im Cache, es gibt keine abweichende Cachepolitik. Muss er Root, TLD und autoritativen Server erneut fragen?
Lösung: Cache und Zuständigkeiten
Nein. Die reguläre Restgültigkeit beträgt 300 − 60 = 240 Sekunden. Der Resolver kann den gespeicherten Eintrag zurückgeben. Die vollständige Hierarchie wird nur benötigt, soweit passende Antworten und Delegationsinformationen fehlen. Es wurde damit weiterhin keine Website übertragen.
Eine A-Abfrage liefert eine Adresse, die AAAA-Abfrage für denselben Namen jedoch NOERROR ohne AAAA-Daten. Bedeutet das, dass der Name nicht existiert?
Lösung: Name und Record-Typ trennen
Nein. Der Name existiert, wie schon die A-Antwort zeigt. Für AAAA liegt hier NODATA vor. Das ist von NXDOMAIN zu unterscheiden. Ein IPv4-Verbindungsversuch kann trotzdem möglich sein; über die Erreichbarkeit des Webdienstes sagt diese DNS-Antwort allein nichts aus.
Quellen und fachlicher Stand.
Fachlich geprüft am . Grundlage sind RFC 1034, Abschnitt 4.3.2 (Auflösung), RFC 1035, Abschnitt 3.3 (Records) und RFC 9499 (aktuelle DNS-Begriffe; ersetzt RFC 8499).
Vertiefung: RFC 3596 (AAAA), RFC 2308 (negative Antworten), RFC 8767 (Serve Stale), RFC 7766 (TCP), RFC 7858 (DoT), RFC 8484 (DoH), RFC 4033 (DNSSEC) und RFC 9471 (Glue). Die Darstellung ist eine Einführung, keine vollständige Resolver-Implementierung.
Die Grundlagen im Serverbetrieb anwenden.
Diese Lernschritte verbinden das Thema mit einer konkreten Infrastruktur: