Herumgraben im Datenwald

Normale Anwender kennen den Domain Name Service als Black Box wie in Abbildung 1. Irgendwann einmal richtet man den Dienst ein – heutzutage oft vollautomatisch, indem man die Übermittlung von DNS-Daten beim Aufbau einer Internet-Verbindung via PPP aktiviert. Anschließend kann man beliebige Hostnamen eingeben, und der Computer weiß bzw. erfragt automatisch die zugehörige IP-Adresse. Natürlich funktioniert das (meistens) auch umgekehrt: Zu einer IP-Adresse kann der eigene Rechner den symbolischen Namen herausfinden.

Abbildung 1: DNS als Black Box

Bei solch einer typischen Konfiguration kümmert sich der eigene Computer tatsächlich nicht weiter darum, wie DNS funktioniert. Er schickt eine Anfrage an irgendeine vorgegebene Adresse und bekommt von dort auch die Antwort. Freilich steht an dieser "vorgegebenen Adresse", irgendwo bei einem beliebigen Internet-Provider, meistens ebenfalls ein Linux-Rechner. Woher bekommt der die Daten?

Der Domain Name Service ist ein hierarchisches System. Kein Computer bei T-Online, bei der amerikanischen Regierung oder sonstwo könnte jemals die IP-Adressen aller Computer im Internet speichern. Die Größe solch einer Datenbank wäre noch das kleinere Problem: Wie wollte man die Daten aktuell halten? Hier wird ein neuer Rechner gekauft, dort wechselt ein Laptop nach dem Umstöpseln der Netzwerkkarte seine IP-Adresse.

DNS löst diese Problematik nach dem Motto "teile und herrsche": Jedermann kann einen DNS-Server aufsetzen, der aber immer nur für den eigenen kleinen Teil des Internets zuständig ist. Beispielsweise hat die Uni Trier einen eigenen DNS-Server, der nur für Adressen im Bereich uni-trier.de zuständig ist. Man sagt: Er ist für diesen Bereich autoritativ (englisch: authoritative, maßgeblich). Wenn also jemand die Adresse von www.uni-trier.de sucht, fragt er den DNS-Server, der für uni-trier.de verantwortlich ist (siehe Abbildung 2).

Abbildung 2: DNS-Server der Uni Trier

Der zwischengeschaltete DNS-Server des Internet-Providers nimmt hier die Anfrage entgegen und leitet sie an den eigentlich zuständigen Server weiter; dann nimmt er dessen Antwort und leitet sie an den ursprünglich fragenden Computer weiter. Er weiß selbst praktisch nichts bzw. nur sehr wenig über das Netz, sondern beschränkt sich auf das Weiterleiten (englisch Forwarding) von Anfragen. Daher wird er auch Forwarding Name Server genannt. Selbstverständlich ist er redundant: Wenn Sie wollen, richten Sie auf Ihrem Computer einen eigenen DNS-Server ein und verzichten auf den des Internet-Providers. Darauf gehen wir an dieser Stelle aber nicht weiter ein.

Spionage in Aktion

Stattdessen wollen wir den versprochenen Spion einmal ausprobieren. Das kleine Hilfsprogramm dig schickt eine Anfrage an einen Domain Name Server und zeigt die Antwort ganz ausführlich an.

dig ist eigentlich ein Teil des BIND-Distribution und soll das Testen eines Name-Servers erleichtern. Uns verrät es nebenbei eine Menge Interna.

dig starten Sie an der Kommandozeile, z. B. in einem Terminal-Fenster. (Ist das Programm nicht installiert, finden Sie es meist in einem Paket namens bind-utils.) Als Argument übergeben Sie den gesuchten Hostnamen bzw. eine IP-Adresse. Optional ist die Angabe eines Name-Servers nach einem Klammeraffen @, dann wird statt des voreingestellten Name-Servers ein anderer Rechner abgefragt. Als letztes Argument darf noch ein Abfragetyp festgelegt werden, so dass nicht nur eine Adresse, sondern noch andere oder zusätzliche Informationen ausgegeben werden.

dig @name.server.org
 host.name.com
 any

Ein Beispiel finden Sie in Listing 1. Gezeigt wird eine Anfrage an einen Name-Server von T-Online (dns00.btx.dtag.de) nach dem Hostnamen www.uni-trier.de. Das Ergebnis orientiert sich in seinem Format an einer BIND-Konfigurationsdatei; dabei sind Kommentare durch Strichkommata am Anfang der Zeile gekennzeichnet.

dig wiederholt zunächst seine Argumente und stellt anschließend die Antwort vom Server in halbwegs verständlicher Form dar. Diese besteht hier aus einem Header und vier Abschnitten: Der Anfrage (QUERY SECTION), der Antwort im engeren Sinne (ANSWER), dem Authority-Abschnitt sowie zusätzlichen Daten (ADDITIONAL SECTION).

nathan:~ $ dig @dns00.btx.dtag.de www.uni-trier.de
; <<>> DiG 8.3 <<>> @dns00.btx.dtag.de www.uni-trier.de
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 6
;; QUERY SECTION:
;;      www.uni-trier.de, type = A, class = IN
;; ANSWER SECTION:
www.uni-trier.de.       1D IN CNAME     maui.uni-trier.de.
maui.uni-trier.de.      1D IN A         136.199.8.62
;; AUTHORITY SECTION:
uni-trier.de.           1h49m49s IN NS  dns.uni-trier.de.
uni-trier.de.           1h49m49s IN NS  dns2.uni-trier.de.
uni-trier.de.           1h49m49s IN NS  rzsun02.uni-trier.de.
uni-trier.de.           1h49m49s IN NS  ws-was.win-ip.dfn.de.
uni-trier.de.           1h49m49s IN NS  deneb.dfn.de.
;; ADDITIONAL SECTION:
dns.uni-trier.de.       4h12m47s IN A   136.199.8.101
dns2.uni-trier.de.      4h12m47s IN A   136.199.8.129
rzsun02.uni-trier.de.   4h12m47s IN A   136.199.8.224
ws-was.win-ip.dfn.de.   16h43m53s IN A  193.174.75.126
ws-was.win-ip.dfn.de.   16h43m53s IN A  193.174.75.110
deneb.dfn.de.           15h31m36s IN A  192.76.176.9
;; Total query time: 633 msec
;; FROM: nathan to SERVER: dns00.btx.dtag.de  194.25.2.132
;; WHEN: Mon Sep 16 15:08:55 2002
;; MSG SIZE  sent: 34  rcvd: 292
nathan:~ $

Die Anfrage war hier nach www.uni-trier.de, Typ A, Klasse IN. Der Typ zeigt die Art des Ergebnisses, in diesem Fall eine numerische IP-Adresse. Wichtige Datentypen sind in Tabelle 1 aufgelistet; all diese Typen lassen sich durch ein entsprechendes Argument an dig auch direkt abfragen. Die Klasse IN steht für "Internet" und ist die einzige Klasse, die in unseren Beispielen vorkommen wird.

In der ANSWER SECTION folgen die eigentlich abgefragten Daten. Dieser Abschnitt darf fehlen! Wenn ein Name-Server die Antwort nicht kennt, aber auf einen anderen Name-Server verweisen kann, der vermutlich mehr weiß, liefert er ein Ergebnis zurück, das keine Answer Section enthält.

Stattdessen steht in der folgenden AUTHORITY SECTION die Information darüber, welcher (oder welche) Name-Server für den betreffenden Adressbereich autoritative Daten vorhalten. In unserem Beispiel kennt dns00.btx.dtag.de zwar die Antwort auf die Frage und liefert ein Ergebnis zurück: www.uni-trier.de ist ein CNAME (Spitzname) für maui.uni-trier.de, und dieser Rechner hat die IP-Adresse 136.199.8.62. Autoritative, also garantiert richtige Daten, kann man jedoch nur von den übrigen aufgelisteten Name-Servern erhalten, also von dns.uni-trier.de, dns2.uni-trier.de usw.

Die einzelnen Datenzeilen enthalten neben Hostname, Klasse, Datentyp und "Inhalt" (IP-Adresse oder ein weiterer Hostname) noch eine Zeitangabe, z. B. 1D (ein Tag) oder 16h43m53s (16 Stunden, 43 Minuten, 53 Sekunden). Dies ist ein Mindesthaltbarkeitsdatum für die angegebenen Daten: Mindestens für diese Zeit bleibt der "Inhalt" der Datenzeile gültig, danach muss er aufgefrischt werden.

Es folgt ein Abschnitt mit zusätzlichen Infos, in denen die IP-Adressen der weiteren erwähnten Hosts zurückgeliefert werden. So könnten wir beispielsweise dns.uni-trier.de direkt ansprechen und müssten dann nicht im nächsten Schritt versuchen, dessen IP-Adresse herauszufinden.

iptables -I OUTPUT 1 -p udp --dport 53 -j ACCEPT
iptables -I INPUT  1 -p udp --sport 53 -j ACCEPT

ipchains -I output 1 -p udp --dport 53 -j ACCEPT
ipchains -I input  1 -p udp --sport 53 -j ACCEPT

Durch Bäume klettern

Eine wichtige Frage ist bislang noch unbeantwortet. dns.uni-trier.de kennt also "autoritative" Daten für die Domain uni-trier.de. Aber woher wissen wir das? Bzw. woher weiß dns00.btx.dtag.de das?

Für die Antwort muss man sich hierarchisch durch den DNS-"Baum" hindurch hangeln. In Abbildung 3 ist dieser Baum traditionsgemäß mit der Wurzel oben dargestellt: Der Name dieser Wurzel-Domain ist ein einfacher Punkt. Unmittelbar nachgeordnet sind die so genannten Top-Level-Domains wie z. B. de, com, net und org. Die Root-Server oder "Wurzel-Server" verfügen über autoritative Daten für diese Wurzel-Domain, sie wissen also, welche Server beispielsweise Auskunft über die Top-Level-Domain de geben können.

Abbildung 3: Der DNS-Baum

Damit es kein Henne-und-Ei-Problem gibt, sind die Root-Server fest vordefiniert. Sie tragen Namen wie a.root-servers.net, b.root-servers.net usw. und sind quer über den ganzen Erdball verteilt. Ihre IP-Adressen haben sich seit Jahren nicht mehr geändert; jeder Root-Server kennt sie. Zusätzlich sind diese IPs in einer weit verbreiteten "Hints"-Datei ("Tipps") abgelegt, die jeder Name-Server als Ausgangsbasis nutzt.

Diese Root-Server sind einer enormen Belastung ausgesetzt; ohne sie würde im Internet kaum etwas funktionieren. Zwar beantworten sie immer nur die ewig gleichen Anfragen ("wer ist autoritativ für de?"), aber das mit enormer Frequenz. Für Listing 2 wurde ein Root-Server mit dig belästigt. Sie sehen: Eine große Top-Level-Domain wie Deutschland kommt selbstverständlich nicht mit einem einzigen autoritativen Server aus. Um die Belastung ein wenig zu verteilen, sind momentan nicht weniger als sieben Server im Einsatz. Alle diese beantworten öffentliche Anfragen nach Domains innerhalb Deutschlands.

nathan:~ $ dig @a.root-servers.net de
; <<>> DiG 8.3 <<>> @a.root-servers.net de
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 7
;; QUERY SECTION:
;;      de, type = A, class = IN
;; AUTHORITY SECTION:
de.                     2D IN NS        AUTH03.NS.DE.UU.NET.
de.                     2D IN NS        DNS.DENIC.de.
de.                     2D IN NS        SUNIC.SUNET.SE.
de.                     2D IN NS        DNS.NIC.XLINK.NET.
de.                     2D IN NS        SSS-AT.DENIC.de.
de.                     2D IN NS        SSS-NL.DENIC.de.
de.                     2D IN NS        DNS2.DENIC.de.
;; ADDITIONAL SECTION:
AUTH03.NS.DE.UU.NET.    2D IN A         192.76.144.16
DNS.DENIC.de.           2D IN A         194.246.96.79
SUNIC.SUNET.SE.         2D IN A         192.36.125.2
DNS.NIC.XLINK.NET.      2D IN A         193.141.40.42
SSS-AT.DENIC.de.        2D IN A         193.171.255.34
SSS-NL.DENIC.de.        2D IN A         193.0.0.237
DNS2.DENIC.de.          2D IN A         194.246.96.49
;; Total query time: 175 msec
;; FROM: nathan to SERVER: a.root-servers.net  198.41.0.4
;; WHEN: Mon Sep 16 15:09:40 2002
;; MSG SIZE  sent: 20  rcvd: 306
nathan:~ $

Wenn ein Name-Server auf der Suche nach einer IP-Adresse vom Root-Server eine autoritative Datenquelle für de erfahren hat, fragt er dort nach dem zuständigen Server für die nächste Verzweigung, z. B. nach uni-trier.de. Bei noch längeren Hostnamen wird dieser Prozess immer weiter fortgesetzt – bis irgendwann der letzte Knoten erreicht ist: die gewünschte Adresse selbst. Abbildung 4 zeigt diesen Prozess aus Sicht des einzelnen Name-Servers.

Abbildung 4: Eine vollständige DNS-Abfrage

Und umgekehrt?

Nicht immer sucht man zu einem Hostnamen die passende IP-Adresse. Manchmal kennt man nur die IP-Adresse und benötigt den zugehörigen Hostnamen. Zugegeben: In diesem Fall stammt die Anfrage wohl eher von einem Computer als von einem Menschen. Häufig ist diese Suchrichtung trotzdem.

Mit einem kleinen Trick funktioniert das aber mit den beschriebenen Methoden ganz hervorragend. Angenommen, in einer Protokolldatei taucht die IP-Adresse 12.41.85.202 auf. Wenn Ihr Computer den Hostnamen dazu wissen möchte, um Ihnen eine schöne Statistik zu präsentieren, kehrt er die Reihenfolge der Oktette um und hängt die spezielle Domain in-addr.arpa an.

Im DNS ist immer der letzte Teil eines Namens der hochrangigste, also ist z. B. in uni-trier.de das "de" dem "uni-trier" übergeordnet. In einer normalen IP-Adresse ist das genau umgekehrt: In 12.41.85.202 ist die 202 am Ende fast unwichtig und legt bloß einen spezifischen Computer innerhalb des LANs fest; die 12 am Anfang hingegen ist am wichtigsten und definiert das Netzwerk selbst.

Es ergibt also Sinn, die IP-Adresse für das DNS umzukehren. Mit dem angehängten in-addr.arpa, das eine "verkleidete" IP-Adresse kennzeichnet, wird aus dem angegebenen Beispiel der Pseudo-Hostname 202.85.41.12.in-addr.arpa, und dieser lässt sich über das DNS abfragen, wie es oben beschrieben wurde.