# Rekursive und iterative Namensauflösung

Rekursive und iterative Namensauflösung beschreibt verschiedene Arten der Namensauflösung im Domain Name System (DNS).
Eine DNS-Anfrage kann von einem Nameserver nach drei verschiedenen Verfahren beantwortet werden:
* autoritativ (der Server holt die Daten aus einer lokalen Zonendatei)
* nicht-autoritativ
** rekursiv (der Server holt die Daten von einem anderen Nameserver)
** iterativ (der Server antwortet mit einem Verweis auf andere Nameserver)
Welches Verfahren angewandt wurde, ergibt sich aus den Flags im Header der DNS-Antwort.

## Autoritative Antwort

Eine autoritative Antwort erfolgt, wenn der angefragte Domainname in einer Zone enthalten ist, für die der angefragte Nameserver zuständig ist. Ob eine Anfrage autoritativ, also aus einer lokalen Zonendatei, beantwortet wurde, wird durch das Flag Authoritative Answer (AA) in der DNS-Antwort definiert.

## Rekursive Antwort

Der Administrator eines Nameservers kann konfigurieren, ob der Nameserver Anfragen rekursiv bearbeiten kann oder nicht. Gängige Praxis ist es, Rekursion für unbekannte Clients zu deaktivieren, da ein offener DNS-Resolver für DNS Amplification Attacks missbraucht werden kann. Ein anfragender Resolver setzt im Header einer DNS-Anfrage das Flag Recursion Desired (RD), wenn er eine rekursive Auflösung seiner Anfrage wünscht. Der Nameserver kopiert das RD-Flag von der Anfrage in die Antwort unverändert. Zusätzlich zeigt der Nameserver über das Flag Recursion Available (RA) an, ob er Rekursion unterstützt. Nur wenn die Antwort sowohl das RD-Flag, als auch das RA-Flag enthält, kam tatsächlich Rekursion zum Einsatz.
Ein Nameserver kann eine rekursive Anfrage entweder selbst auflösen, indem er nacheinander Nameserver anfragt, bis er eine autoritative Antwort erhält, oder die Anfrage an einen anderen rekursiv arbeitenden Nameserver weiterleiten. Im Falle einer Weiterleitung wird der Nameserver, an den eine rekursive Anfrage weitergeleitet wird, Forwarder genannt.
Eine rekursive Antwort enthält entweder die gesuchten Resource Records oder einen Fehlercode, jedoch niemals einen Verweis auf einen anderen Nameserver. Der anfragende Resolver erhält bei einer rekursiven Antwort das Ergebnis einer abgeschlossenen Namensauflösung zurück.

## Iterative Antwort

Eine iterative Antwort enthält anstelle der gesuchten Daten einen Verweis auf andere Nameserver, die der Resolver als Nächstes anfragen kann. Ein derartiger Verweis enthält einen Zonennamen, für den ein oder mehrere andere Nameserver zuständig sind, sowie die Domainnamen der zuständigen Nameserver. Falls bekannt, sind auch die IP-Adressen der Nameserver enthalten (Glue Records).
Eine iterative Antwort bringt den anfragenden Resolver im hierarchischen Domain-Namensraum einen Schritt näher an die gesuchten Daten. Die Root-Nameserver beispielsweise verweisen mit einer iterativen Antwort auf die zuständigen Nameserver der Top-Level-Domain, die wiederum mit einer iterativen Antwort auf die Nameserver der Second-Level-Domain verweisen. Durch wiederholte (iterative) Anfrage erreicht der anfragende Resolver schließlich einen autoritativen Nameserver, von dem er eine autoritative Antwort mit den gesuchten Resource Records erhält.
Das folgende fiktive Beispiel zeigt eine iterative DNS-Antwort mit nslookup:
C:\> nslookup test.example.com
Name: test.example.com Served by:  - dns01.extern.com  172.27.182.11, 172.27.158.208  example.com  - dns02.extern.com  example.com  - dns03.extern.com  172.27.157.16  example.com
Der Nameserver teilt in diesem Beispiel dem Resolver mit, dass er den Namen test.example.com nicht auflösen kann, dass er aber drei Nameserver kennt, die Informationen zu diesem Namen besitzen. Für den Nameserver dns01.extern.com werden zwei IP-Adressen mitgeliefert, für dns02.extern.com keine und dns03.extern.com eine.

## Beispiel Namensauflösung
### Forward Lookup

Im folgenden, kommentierten Beispiel wird zum Namen „www.heise.de.“ die IPv4-Adresse mit Hilfe des Resolver-Tools dig bestimmt. „+trace“ bedeutet, dass die einzelnen Antworten auf iterative Anfragen an die Nameserver-Hierarchie angegeben werden, „+additional“ sorgt dafür, dass zusätzlich dargestellt wird, dass die Nameserver für Delegierungen nicht nur NS Resource Records verwalten, sondern teilweise auch deren IP-Adressen in Form von A oder AAAA Resource Records kennen und mit ausliefern, „-t A“ schließlich verlangt nach dem A Resource Record, also der IPv4-Adresse. Es zeigt sich, dass nacheinander vier Nameserver befragt werden müssen, um zur Antwort zu gelangen:
192.168.2.1 (siehe letzte Zeile) ist der eingetragene Nameserver des abfragenden Rechners, welcher auf die Root-Nameserver verweist, die alle weiter via IPv4 befragt werden können, einige zusätzlich auch mittels IPv6. Die Root-Nameserver verwalten die Wurzel-Zone (Zone, die die Nameserver für .org, .de, .com und andere Top Level Domains enthält) der Namensauflösung, dargestellt durch einen Punkt. Die IP-Adressen der Root-Nameserver ändern sich sehr selten und müssen allen Nameservern bekannt sein, sofern sie das Internet betreffende Anfragen beantworten. (Diese IP-Adressen können beispielsweise in einer als „Root Hints“ bezeichneten Textdatei mitgeliefert werden.)
Aus den 13 genannten Root-Nameservern wurde zufällig „I.ROOT-SERVERS.NET.“ ausgewählt, um ihm die Frage nach „www.heise.de.“ zu stellen. Er antwortete mit sechs Nameservern zur Auswahl, die für die Zone „de.“ verantwortlich sind. Auch hier ist bei zwei Servern die Abfrage mittels IPv6 möglich.
Aus den sechs genannten Nameservern wurde zufällig „F.NIC.de.“ ausgewählt, um Näheres über „www.heise.de.“ zu erfahren. Er beantwortet die Anfrage mit fünf möglichen Delegierungen. Unter anderem mit einer Delegierung auf den Server „ns.heise.de.“. Diese Information würde ohne den dazugehörigen A Resource Record, auf 193.99.145.37 zeigend, auf demselben Server nichts helfen, denn der Name liegt in der Zone „heise.de.“, die er selbst verwaltet. Man spricht bei dieser Art von Information auch von Glue Records (von engl. glue, kleben). Sollte der Server „ns2.pop-hannover.net.“ für den nächsten Schritt ausgewählt werden, so wäre in einer gesonderten Namensauflösung zunächst dessen IP-Adresse zu bestimmen, da diese hier nicht mitgesendet wurde.
Aus den fünf genannten Nameservern wurde zufällig „ns.pop-hannover.de.“ herangezogen, um die Frage nach „www.heise.de.“ zu beantworten. Die Antwort lautet 193.99.144.85. Damit ist die Anfrage am Ziel angelangt. Es werden auch wieder dieselben Nameserver als verantwortlich für „heise.de.“ genannt, ohne also auf andere Nameserver zu verweisen.

### Reverse Lookup

Für den Reverse Lookup, also das Auffinden eines Namens zu einer IP-Adresse, wandelt man die IP-Adresse zunächst formal in einen Namen um, für den man dann das DNS nach einem PTR Resource Record befragt. Da die Hierarchie bei IP-Adressen von links nach rechts spezieller wird (siehe Subnetz), beim DNS aber von rechts nach links, dreht man beim ersten Schritt die Reihenfolge der Zahlen um und aus der IPv4-Adresse 193.99.144.85 wird z. B. der Name „85.144.99.193.in-addr.arpa.“ sowie aus der IPv6-Adresse 2a02:2e0:3fe:100::6 der Name „6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.e.f.3.0.0.e.2.0.2.0.a.2.ip6.arpa.“ erzeugt. (Dieser Name ist lang, da die implizit enthaltenen Nullen nun wieder explizit genannt werden müssen.)
Der PTR Resource Record für die so umgeformte IPv4-Adresse lässt sich analog zum vorigen Beispiel bestimmen:
Die Antwort lautet also „www.heise.de.“. Es ist jedoch weder notwendig, dass jeder IP-Adresse ein Name zugeordnet ist, noch müssen Hin- und Rückauflösung einander entsprechen. Die Auflösung beginnt wieder mit dem Verweis auf die Root-Nameserver und die Delegierungen finden offensichtlich an den durch Punkte markierten Grenzen zwischen den Zahlen statt. Man sieht in dem Beispiel jedoch auch, dass nicht an jedem Punkt in einem Namen delegiert werden muss.