Funktionsweise von DNS

Wie für jeden wichtigen Dient im Internet gibt es auch für DNS RFCs die ihn genau beschreiben. Es handelt sich um RFC1034 und RFC1035.

Im Prinzip ist DNS eine riesige verteilte Datenbank. Das Prinzip nachdem DNS-Anfragen beantwortet werden, könnte man salopp mit

»Frag doch denjenigen der zuständig ist.«

beschreiben. Aber wer ist nun zuständig? Wir hatten ja gesagt, dass der Namensraum des Internet in nicht überlappende Zonen aufgeteilt ist. Jede Zone besitzt mindestens zwei, oft mehrere Name-Server, die alle Informationen zu den Hosts der Zone bereitstellen. Man sagt auch, diese Nameserver hätten die Autorität für ihre Zone.

Erhält nun ein Name-Server eine Anfrage über einen FQDN so gibt es folgende Möglichkeiten.

Rekursive Anfrage

Die Adresse fällt in seinen Verwaltungsbereich, oder er hat das Ergebnis der Anfrage wegen einer früheren Anfrage im Cache. In diesem Fall beantwortet er die Anfrage aus seiner eigenen Datenbank.

Die gesuchte Adresse fällt nicht in seinen Verwaltungsbereich und er hat auch keine Informationen dazu. Dann sendet der Nameserver eine Anfrage an  den Name-Server der Toplevel-Domain. Dieser prüft ob er die Frage aus seinem Cache beantworten kann, und leitet die Anfrage an den nächstniederen Server weiter, auf dem sich das Ganze fortsetzt, bis schließlich ein Nameserver gefunden wird, der einen Teil der Anfrage erkennt. Dieser leitet die Anfrage dann den Baum wieder hinunter, bis zum zuständigen Name-Server. 

Beispiel: Auf dem Rechner gibtsnich.schlurchingen.bwl.de wird eine Anfrage nach der Adresse des Rechners gestellt. nomachine.cs.indiana.edu gestartet. Dann geht die Anfrage zuerst an den Zonennameserver ns.schlurchingen.bwl.de(1). Dieser hat noch nie etwas von der Informatikfakultät der Universität von Indiana gehört, und leitet die Anfrage weiter an den Toplevel-Name-Server von edu (2), der in der Datenbank edu.server.net steht. Der kennt zwar auch nicht alle Maschinen in seinem Bereich, weiss aber zumindest über alle seine Nachkommen bestens Bescheid un erkennt messerscharf, das der Nameserver der Domain indiana.edu dafür zuständiger ist als er (3). Dieser kennt immerhin schon die Domain cs und fragt bei deren Nameserver (4) an, ob er etwas über nomachine wisse. Der kennt den angefragten Rechner tatsächlich und beantwortet die Frage (5). Der Nameserver von indiana.edu speichert das Ergebnis zwischen und leitet die Anfrage weiter an den Nameserver der Toplevel-Domäne edu(6). Diese merkt sich die Antwort und erteilt dem Nameserver von schlurchingen.bwl.de die erhoffte Auskunft(7). Dieser Wiederum merkt sich die Antwort und sagt seinem Client welche Adresse nomachine.cs.indiana.edu hat(8).

Iterative Anfrage

Die iterative Anfrage läuft im Prinzip wie die rekursive Anfrage. Während bei der rekursiven Anfrage allerdings die eigentliche Adresse über die Serverkaskade zurückberichtet wird, wird bei der iterativen Variante jeweils die Adresse des zuständigen Nameservers zurückgeliefert. ns.schlurchingen.bwl.de befragt also zuerst edu.server.net und erhält von dort die Adresse des Name-Servers von indiana.edu. Anschließend befragt er diesen und erhält die Adresse des Nameservers von cs.indiana.edu. Dieser wiederum kann ihm Auskunft über die Adresse von nomachine.cs.indiana.edu geben.

In beiden Fällen wird die Anfrage letztendlich von dem Nameserver beantwortet, der die Autorität für die Zone hat.

Reverse Lookup

DNS kann aber nicht nur die IP-Adresse zu einem vorgegebenen Namen liefern, sondern auch den Namen zu einer vorgegebenen IP-Adresse. Um das zu erreich wurde eine besondere Domain geschaffen, die Domain IN-ADDR.ARPA.

Ein Eintrag in der IN-ADDR.ARPA-Domain besteht aus der IP-Adresse, rückwärts gelesen, und dem Suffix in-addr.arpa. 

Der Reverse-Eintrag für einen Rechner mit der IP-Adresse 194.63.55.1 würde also 1.55.63.194.in-addr.arpa lauten.