Computer in einem Netzwerk lokalisieren sich gegenseitig über numerische (IPv4) oder alphanumerische (IPv6, MAC-Adresse) Zeichen. Für Menschen ist dieses Format aber nicht gut zu merken. Für das Internet Protokoll wurde daher das Domain Name System entworfen, welches neben einem Protokoll auch ein komplettes System und dessen Verfahrensweise beschreibt.

Zu den Anfangszeiten des Internets wurden lokale Dateien verwendet, welche Adressen mit eindeutig zuordbaren Begriffen korrelierten. Die Universität XY konnte so beispielsweise durch das Alias UniXY kontaktiert werden, anstatt über die nummerische Adresse. Noch heute befindet sich eine solche Datei auf jedem Betriebssystem. Unter Windows findet man sie unter /Windows/System32/drivers/etc/hosts und unter *NIX unter /etc/hosts.

Der strukturelle Aufbau ist dabei immer der selbe - Pro Zeile eine Adresse, gefolgt von einem Begriff und optional, einem Kommentar. Der Begriff ist dabei prinzipiell frei wählbar:

127.0.0.1          localhost         # Virtuelle Loopback Adresse
192.168.1.1        router            # Webinterface des Routers
192.168.1.250      drucker           # Webinterface des Netzwerkdruckers
192.0.32.10        ex                # www.example.org, .com, .net

Diese Beispieldatei enthält als erstes den Alias für die virtuelle Loopback Adresse des Computers. Darauf folgen zwei Adressen im lokalen Netzwerk, die auf Netzwerkgeräte verweisen. Schließlich existiert noch eine öffentliche Adresse, welche auf eine bekannte Testseite verweist. Durch diese Einträge könnte man die Testseite im Browser durch ex aufrufen oder bei einem Verbindungstest den Router durch ping router kontaktieren. Offensichtlich eine sehr praktische Angelegenheit.

Allerdings haben lokale host-Dateien einen gravierenden Nachteil, sobald es in einem globaleren Kontext betrachtet wird. Schon in mittleren Netzen, wie einem Unternehmensnetzwerk, erfordert es einen enormen Verwaltungsaufwand.

Daher wurde in den Achtzigern das Domain Name System entworfen. Es sollte die Vorteile der hosts-Dateien übernehmen und deren Nachteile bestmöglich vermeiden. Das neue System war denkbar einfach - es wurden nicht mehr alle Aliase lokal gespeichert, sondern bei Bedarf von den zentralen Instanzen, den Nameservern erfragt. Zudem wurden FQDNs (Fully Qualified Domain Names) eingeführt. Quasi Aliase, die einem vorgeschriebenen Aufbau folgen. Denn mit dem Domain Name System hielt auch ein strukturierter Namensraum, der Domain Namespace Einzug.

Der Namensraum wurde dabei in Ebenen (Root, TDL, unsw.) unterteilt, welche wiederum Zonen (org., net., opendns., unsw.) beinhalten. Folgendes Diagramm soll die heutige Hierarchie verdeutlichen:

Die oberste Ebene stellt die Wurzel des Domain Namespace dar. Diese Zone ist mit einem Punkt, gefolgt von n Leererzeichen definiert. Die Root Zone hat also keinen Namen. Wenn auch im alltäglichen Gebrauch nicht präsent, ist diese Regel existent und beispielsweise bei der Konfiguration von Nameservern zwingend erforderlich. Praktischer Weise wird dabei nur der Punkt mit Null Leerzeichen verwendet.

Direkt unterhalb dieser Ebene folgen die Zonen der Top Level Domains (TLDs). Eine vollständige Liste ist auf der Webseite der IANA einsehbar. Liste der TLDs auf iana.org

Darauf folgen Zonen für Subdomains (Second Level, Third Level, unsw.) oder Hosts. Im obigen Beispiel ist beta06 ein Host, da sich keine weitere Subdomain mehr darunter befindet. Hingegen ist ripe eine Subdomain und erst lirportal und labs definieren Hosts.

Verbundene Zonen bilden einen FQDN, welcher letztendlich einen eindeutigen Host definiert. Für den Host labs aus dem obigen Beispiel würde der FQDN wie folgt lauten:

labs.ripe.net.

Die FQDN unterliegt folgenden Regel:

• maximale länge einer FQDN beträgt 255 Zeichen (inkl. der Punkte)
  
• erlaubt sind Buchstaben (keine Umlaute oder ß), Zahlen und der Bindestrich
• jede Ebene unter den TDLs darf maximal 63 Zeichen enthalten

Hinter dieser FQDN verbirgt sich letztendlich nur eine nummerische (IPv4) oder alphanumerische (IPv6) Adresse . Diese Adresse kennt der zuständige Nameserver, also der Nameserver, der die Zone ripe. verwaltet.

Welcher dies wiederum ist, ermittelt das Domain Name System selbstständig. Denn passend zur Hierarchie des Domain Namespace verwalten zuständige, so genannte autorisierte Nameserver die registrierten Adressen ihrer Zonen. Der Vorteil dieses Systems ist, dass nicht jeder Nameserver alle Adressen kennen muss. Sonst bestände ja wieder das gleiche Problem, wie eingangs mit den hosts-Dateien. Zudem ist die Administration einzelner Zonen einfacher, als aller Zonen zusammen.

Bevor der Ablauf einer DNS Anfrage genauer betrachtet wird, müssen noch die Verfahrensweisen der rekursiven Abfrage und iterativen Abfrage angesprochen werden. Beides sind mögliche Verfahren, wie Erfragung einer Internet Protokoll Adresse erfolgen kann.

Die rekursive Anfrage arbeitet nach folgendem Schema - "Gib mir die IP Adresse der FQDN XY oder frag jemanden, der sie weiß!"

Die iterative Abfrage arbeitet hingegen so - "Gib mir die IP Adresse der FQDN XY oder nenn mir jemanden, der sie weiß! Ich werden ihn dann selbst befragen."

Folgendes Schaubild beschreibt den prinzipiellen Ablauf der Namensauflösung für das Ziel labs.ripe.net. am Beispiel eines Webbrowsers:

Anmerkung: Die angedeutete Kopie im DNS Bereich soll symbolisieren, dass es so gut wie nie nur einen Nameserver für eine Zone gibt. Diese Redundanz soll den reibungslosen Betrieb des Domain Name Systems gewährleisten.

1. Zu Beginn wird die lokale hosts-Datei befragt. Ist dort ein passender Eintrag zu finden, ist die Abfrage abgeschlossen. Dieser Teil ist allerdings noch kein Bestandteil des Domain Name Systems.
2. Liefert die lokale hosts-Datei kein Ergebnis, wird der Resolver mit der Ermittlung beauftragt. Der Resolver ist Bestandteil des TCP/IP Stacks und mit ihm beginnt das Domain Name System.
3. Der Resolver befragt als erstes seinen lokalen Cache. Dies ist ein Zwischenspeicher, in dem kürzlich aufgerufene FQDNs für eine kurze Zeitspanne gespeichert werden. Dies ist ein Kompromiss aus Effizenz und Speicherbedarf. Das kurzeitige Zwischenspeichern ermöglicht die schnelle Namensauflösung, ohne dass ein Nameserver befragt werden muss. Navigiert man beispielsweise innerhalb einer Website, so muss für die neu aufgerufene Seite auf dem selben Webserver nicht erst nochmal ein Nameserver befragt werden.
4. Ist auch im lokalen Cache kein Eintrag zu finden, wird der im System eingetragene primäre Nameserver rekursiv befragt. Dies ist in der Regel der Nameserver des Internet Service Providers. Diese Nameserver sind allerdings selten für eine Zone autorisiert. Sie besitzen keine Zonendatenbank, sondern nur einen Cache, in dem bereits angeforderte FQDNs nach diversen Kriterien temporär gespeichert werden.
5. Daher wird beim primären Nameserver nur der lokale Cache abgefragt, dessen Zweck und Arbeitsweise der selbe ist, wie der des lokalen Resolvers. Allerdings ist er größer, da er deutlich mehr Anfragen bearbeitet.
6. Trifft auch im Cache des primären Nameservers kein Eintrag zu, dann beginnt die iterative Auflösung der FQDN in die IP Adresse. Daher befragt der primäre Nameserver als erstes einen der globalen Root Server nach dem zuständigen Nameserver für die Top Level Domain net. Root Nameserver - Grundlagen Grafische Darstellung der Standorte
7. Daraufhin befragt der primäre Nameserver den autorisierten Nameserver für die TLD net. nach dem autorisierten Nameserver für die Subdomain ripe.net. und erhält als Antwort wieder eine Adresse eines Nameservers.
8. Schließlich hat der primäre Nameserver nun die Adresse des autorisierten Nameservers für die FQDN labs.ripe.net. und kann diesen nach der IP Adresse für selbige befragen.

Nach diesem Prinzip verläuft eine klassische Namensauflösung im Domain Name System. Wie tief die Iteration bis zu dem gewünschten autorisierten Nameserver geht, hängt natürlich von der Tiefe der aufzulösenden FQDN ab, respektive von der Anzahl der Zonen. Zudem besitzten prinzipiell alle Nameserver einen lokalen Cache. Allerdings ist die Konfiguration der Nameserver Sache der zuständigen Administration und daher könnte nur spekuliert werden, wie genau sie arbeiten (Cachegröße, Dauer des Zwischenspeicherns, unsw.).

Nach dieser theoretischen Betrachtung, soll nun ermittelt werden, welche Nameserver alles in die Auflösung der FQDN labs.ripe.net. involviert sind. Dazu wird sich dem Tool dig unter Linux bedient, welches in diesem Fall wie folgt aufgerufen wird:

dig +trace labs.ripe.net.

; <<>> DiG 9.4.2-P2 <<>> +trace labs.ripe.net.
;; global options:  printcmd
.                 99463   IN  NS     H.ROOT-SERVERS.NET.
.                 99463   IN  NS     M.ROOT-SERVERS.NET.
.                 99463   IN  NS     E.ROOT-SERVERS.NET.
.                 99463   IN  NS     C.ROOT-SERVERS.NET.
.                 99463   IN  NS     J.ROOT-SERVERS.NET.
.                 99463   IN  NS     D.ROOT-SERVERS.NET.
.                 99463   IN  NS     B.ROOT-SERVERS.NET.
.                 99463   IN  NS     G.ROOT-SERVERS.NET.
.                 99463   IN  NS     L.ROOT-SERVERS.NET.
.                 99463   IN  NS     K.ROOT-SERVERS.NET.
.                 99463   IN  NS     F.ROOT-SERVERS.NET.
.                 99463   IN  NS     A.ROOT-SERVERS.NET.
.                 99463   IN  NS     I.ROOT-SERVERS.NET.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 54 ms   <--- 1.

net.              172800  IN  NS     H.GTLD-SERVERS.net.
net.              172800  IN  NS     J.GTLD-SERVERS.net.
net.              172800  IN  NS     A.GTLD-SERVERS.net.
net.              172800  IN  NS     L.GTLD-SERVERS.net.
net.              172800  IN  NS     K.GTLD-SERVERS.net.
net.              172800  IN  NS     E.GTLD-SERVERS.net.
net.              172800  IN  NS     I.GTLD-SERVERS.net.
net.              172800  IN  NS     C.GTLD-SERVERS.net.
net.              172800  IN  NS     D.GTLD-SERVERS.net.
net.              172800  IN  NS     M.GTLD-SERVERS.net.
net.              172800  IN  NS     F.GTLD-SERVERS.net.
net.              172800  IN  NS     B.GTLD-SERVERS.net.
net.              172800  IN  NS     G.GTLD-SERVERS.net.
;; Received 500 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 87 ms  <--- 2.

ripe.net.         172800  IN  NS     ns-pri.ripe.net.
ripe.net.         172800  IN  NS     ns3.nic.fr.
ripe.net.         172800  IN  NS     sns-pb.isc.org.
ripe.net.         172800  IN  NS     sunic.sunet.se.
;; Received 176 bytes from 192.35.51.30#53(F.GTLD-SERVERS.net) in 215 ms <---- 3.

labs.ripe.net.       600  IN  CNAME  pigeon.ripe.net.
pigeon.ripe.net.  172800  IN  A      193.0.19.90
ripe.net.         172800  IN  NS     ns3.nic.fr.
ripe.net.         172800  IN  NS     sunic.sunet.se.
ripe.net.         172800  IN  NS     ns-pri.ripe.net.
ripe.net.         172800  IN  NS     sns-pb.isc.org.
;; Received 226 bytes from 193.0.0.195#53(ns-pri.ripe.net) in 62 ms <--- 4.

Anmerkung: Die Bedeutung der verschiedenen Einträge wird bei der Protokollbeschreibung genauer erläutert.

1. Als erstes erhält das Tool eine Liste der Root Server Adressen (.) vom primären Nameserver mit der IP Adresse 8.8.8.8
   Die Liste der Root Server liegt jedem Nameserver beim erstmaligen Start vorkonfiguriert vor.
2. Von einem dieser Root Server, hier C.ROOT-SERVERS.NET, wird eine Liste mit autorisierten Nameservern für die Zone net. bekanntgegeben.
3. Die Liste mit den autorisierten Nameservern für die Zone ripe.net.teilt der Nameserver F.GTLD-SERVER.net mit.
4. Der Nameserver ns-pri.ripe.net wiederum kennt die autorisierten Nameserver für den Host labs.ripe.net. ,
   welcher in diesem Fall ein Alias für den Host pigeon.ripe.net. ist.

Schließlich soll nun auch das Protokoll selbst genauer betrachtet werden. Das DNS Protokoll ist im OSI Referenzmodell auf der Anwendungsschicht (Schicht 7) angesiedelt, da ein Nameserver nichts weiteres ist, als ein Dienst, respektive eine Anwendung.

Als Übertragungsprotokolle kommen primär UDP/IP zum Einsatz. UDP ist zwar wie das IP Protokoll ein verbindungsloses Protokoll, gewährleistet dafür aber einen schnellen Transport der Informationen. Alternativ kann TCP/IP eingesetzt werden, wenn die übertragenen Informationen beispielsweise so groß sind, dass sie fragmentiert (aufgeteilt) werden müssen. In beiden Fällen wird in jedem Fall für den DNS Dienst der Zielport 53 verwendet, welcher explizit für das DNS Protokoll vorgesehen ist.

Die Informationen die ein Nameserver zu einer Anfrage mitteilen kann, werden Resource Record Sets genannt. Darin sind alle Informationen enthalten, die ein Nameserver zu einer FQDN (bei inverser Anfrage zu einer IP Adresse) kennt. So einen Resource Record Set kann abstrahiert wie folgt aussehen:

beta06.de.               3600  IN  A       82.100.220.53
                               IN  TXT     "Zusätzlich abrufbare Informationen in Textform"
mail                     1800  IN  MX  10  smtp.hoster.de.
dns                                NS      nameserver.hoster.de.
53.220.100.82.in-addr.arpa.        PTR     beta06.de.

Anmerkung: Wie sich Zonendatenbanken und deren Resource Records auf einem Nameserver wirklich darstellen, würde zu tief in das Thema der Konfiguration eines Nameservers eingehen.  

Der Aufbau der DNS Daten folgt wie bei jedem Protokoll einem vorgeschriebenen Format. Dies ist für Anfragen, wie auch für Antworten das selbe:

• ID
  16 Bit Wert, welcher eine Art Transaktionsnummer darstellt, so dass der Resolver die Antwort einer bereits gesendeten Anfrage zuordnen kann.
• QR
  In diesem 1 Bit großen Feld wird markiert, ob es sich um eine Anfrage (Query) oder eine Antwort (Response) handelt.
• OPCODE
  Dieses Feld ergänzt das Feld QR, in dem es die Art der Anfrage/Antwort genauer beschreibt. Die gängigsten Werte sind 1 (Standard Anfrage), 2 (Inverse Anfrage), 3 (Status), 5 (Notify) und 6 (Update).

   

  Code	Bedeutung
  1	Standard Anfrage, FQDN → IP Adresse
  2	Inverse Anfrage; IP Adresse → FQDN
  3	Statusmeldung
  5	Notify
  6	Update

 

• AA
  Ist ein Nameserver bei einer Antwort für die gesuchte Zone oder den Host autorisiert, wird das Authoritative Answer Bit gesetzt.
• TC
  Das Feld Turncated wird gesetzt, falls eine Antwort die für DNS über UDP zulässige Gesamtgröße von 512 Bytes überschreitet. Dies signalisiert dem Empfänger, dass die empfangenen 512 Bytes wahrscheinlich unbrauchbar sind und er deshalb die Anfrage über das verbindungsorientierte Transmission Control Protocol initialisieren muss.
• RD
  Wenn das Feld Recusion Desired gesetzt ist, wird der Nameserver angewiesen weitere Anfragen rekursiv durchzuführen.
• RA
  Das Feld Recusion Avaliable indiziert, ob ein Nameserver die rekursive Anfrage überhaupt unterstützt.
• Z
  Diese drei Bits haben für das konventionelle DNS keine besondere Bedeutung und sind dort immer mit dem Wert 0 belegt. Bei DNSSEC hingegen liegen hier die Flag AD und CD.
• RCODE
  Der Return Code enthält einen Rückgabewert, an dem ein Absender erkennen kann, ob die Anfrage ordnungsgemäß bearbeitet wurde oder es zu einem Fehler kam. Falls ein Fehler auftrat, wird dieser anhand des Rückgabewertes genauer spezifiziert. Die Rückgabewerte aus dem ersten Entwurf für das DNS weisen folgende Möglichkeiten auf:

   

  Code	Bedeutung
  0	Kein Fehler. Die Anfrage ist ordnungsgemäß bearbeitet worden.
  1	Der Nameserver konnte das der Anfrage nicht erkennen.
  2	Fehler aufgrund eines internen Serverproblems.
  4	Ein angefordertes Feature ist nicht auf dem Server implementiert.
  5	Die Anfrage konnte aufgrund des internen Regelwerks nicht beantwortet werden.

  
  

 

• Total Questions → n Questions
  Anzahl der Anfragen. Die Anfragen selbst werden im Feld Questions hinterlegt. Je nach Anzahl der Anfragen, kann das Feld Questions mehrere Bytes umfassen. Gewöhnlich ist aber nur eine Anfrage pro Request.
• Total Answers RRs → n Answers RRs
  Anzahl der Antworten des Nameservers aus seinen Resource Records. Die Antworten selbst werden im Feld Answers RRs hinterlegt.
• Total Authority RRs → n Authority RRs
  Anzahl der Antworten für autorisierte Nameserver aus den Resource Records. Die Antworten selbst werden im Feld Authority RRs hinterlegt.
• Total Additional RRs → n Additional RRs
  Anzahl der zusätzlichen Antworten, wie nützliche Informationen zu einer Anfrage aus den Resource Records, welche aber nicht zwingend zur Beantwortung einer Anfrage notwendig sind. Wieder werden die eigentlichen Informationen in einem zusätzlichen Feld, den Additional RRs abgelegt.

Der inhaltliche Aufbau der Daten in Questions RRs, Answers RRs, Authority RRs und Additional RRs wird im RFC 1035 ff. genau definiert. Weiterführender Weblink

Weitere Informationen:

• Die IANA bietet eine immer aktuelle Übersicht zu allen gültigen Parametern des DNS Protokolls. Weblink zur IANA