1.12.3. Hostnamen-Auflösung im DNS

Eine Netzanwendung, die aus einem Hostnamen die dazugehörige IP-Adresse herausfinden muß, verwendet dazu einen Resolver. Diese Funktionen stecken häufig in betriebssystemnahen Bibliotheken, etwa der winsock.dll oder der C-Library. Sie fragen Daten aus dem DNS ab, indem sie einen Nameserver (NS) kontaktieren. Anschließend stellen sie die Ergebnisse dem Programm zur Verfügung.

Um möglichst schnell Antworten zu erhalten, verwendet man als Transportprotokoll primär UDP. TCP ist ebenfalls zulässig, kommt allerdings im Normalfall lediglich in den relativ seltenen Fällen zum Einsatz, in denen größere Datenmengen zu transferieren sind, z.B. bei Antworten der Nameserver, deren Länge 512 Byte übersteigt, sowie beim sog. Zonentransfer (s. 1.12.4 und 1.12.5). Der Standard-Port eines Nameservers ist sowohl für UDP als auch für TCP 53.

Der Resolver sendet ein UDP-Datagramm an einen konfigurierten Nameserver. Im einfachsten Fall kann der Nameserver die Anfrage aus seiner eigenen Datenbasis beantworten; er sendet dann sofort eine entsprechend aufgebaute Antwort zurück. Hat der Nameserver die Antwort nicht parat und ist die Anfrage rekursiv (dies wird in der Anforderung durch ein Flag gekennzeichnet, das die "faulen" Resolver gerne setzen), so wird der Nameserver selbst zum Nutzer des DNS. Durch Abfragen der zuständigen Nameserver tastet er sich schrittweise (iterativ) zum verantwortlichen Server vor.

Die bei DNS verwendeten UDP-Nachrichten haben eine maximale Länge von 512 Bytes. Längere Antworten lassen sich folglich nicht mehr komplett in einem UDP-Datagramm unterbringen und werden deshalb abgeschnitten, d.h., der NS sendet nur die ersten 512 Byte an den Resolver. Dieser wird dann in der Regel seine Anfrage wiederholen, jetzt aber über TCP statt über UDP, so daß problemlos die vollständige Antwort übertragen werden kann.

Ein Beispiel soll den Ablauf etwas verdeutlichen: Ein WWW-Browser möchte Daten vom Server www.ksc.nasa.gov abfordern. Der eingebaute Resolver fragt den per Konfiguration eingestellten Nameserver im lokalen Netz nach der zu www.ksc.nasa.gov gehörenden IP-Adresse. Unser Nameserver hat die gewünschten Daten nicht und wird nun das DNS bemühen, um die Anfrage zu beantworten. Er befragt einen Root-Nameserver (deren IP-Adressen muß man vorgeben!) nach der Adresse von www.ksc.nasa.gov und wird an den zuständigen Nameserver der Toplevel-Domain gov verwiesen. Die nächste Anfrage geht an diesen. Er verweist seinerseits auf den NASA-Nameserver. Die Anfrage an diesen bringt den Verweis auf den Nameserver der Domain ksc.nasa.gov. Dieser wird uns schließlich und endlich die gesuchte IP-Adresse liefern. Unser lokaler Nameserver sendet die Antwort an den Resolver zurück. Nun kann der WWW-Browser die Verbindung zum gewünschten Server aufnehmen. Allerhand, was durch einen "Klick" ausgelöst wird ...

Deutlich wird an diesem Beispiel die Wichtigkeit der Root-Nameserver. Wären all diese nicht erreichbar, funktionierte keine Hostnamen-Auflösung mehr. Deshalb gibt es zur Zeit 13 Root-NS, wohl verteilt im ganzen Internet. Den jeweils aktuellen Stand finden Sie in der Datei ftp://ftp.rs.internic.net/domain/named.root. Des weiteren gibt es für jede Domain mindestens zwei redundante Nameserver.

Einmal beantwortete Anfragen speichert ein NS zusammen mit den Antworten in einem Cache. Spätere gleiche Anfragen werden danach aus diesem Cache beantwortet. Im Laufe der Zeit baut sich ein großer Cache auf, so daß viele Anfragen dann sofort beantwortet werden können. Dies spart enorm Netzverkehr, entlastet die NS und beschleunigt die Hostnamen-Auflösung. Neue NS-Implementationen merken sich auch Anfragen zu nicht existierenden Daten; das wird als Negative Caching bezeichnet.

Natürlich bleiben solche "Fremddaten" nicht ewig im Cache des NS, sondern unterliegen einer "Alterung". Alle DNS-Daten haben ein vom zuständigen Administrator vergebenes TTL-Feld (Time To Live). Nach Ablauf der "Lebensdauer" wird die Dateneinheit aus dem Cache entfernt und muß bei einer nachfolgenden Abfrage erneut beschafft werden.


Diskussion 1.12.3.1:
Warum setzen die NS ihre Anfragen nicht selbst rekursiv ab?

Diskussion 1.12.3.2:
Welches Risiko birgt Negative Caching?
© Frank Richter, Holger Trapp, 16.4.1998