Dieses Praktikum beschäftigt sich mit einem der wichtigsten Dienste des Internets: DNS. Wenn DNS nicht funktioniert, dann funktioniert effektiv das Internet für den Endanwender nicht. DNS wird aber mitterweile für weit mehr als die einfache Namensauflösung benutzt, z.B. für Lastverteilung, Content Distribution Networks und vieles mehr. Da DNS eine so zentrale Rolle spielt, ist es wichtig DNS zu verstehen und Werkzeuge zu kennen, um DNS-Probleme zu debuggen. Das ist das Ziel dieses Praktikums. Wir werden auch wieder Wireshark einsetzen, um uns die DNS Pakete genau anzuschauen, aber das primäre (Kommandozeilen-)Tool heute heißt dig (domain information groper).

Das "Problem" an DNS ist, dass DNS typischerweise im Hintergrund passiert. Anwendungen nutzen APIs um die DNS-Auflösung zu starten (für C bietet Posix z.B. getaddrinfo()) und der Nutzer sieht und merkt nicht, dass der eingegebene Name in eine IP-Adresse umgewandelt wird. Im ersten Praktikum haben wir aber Wireshark kennengelernt, und damit lässt sich dieser Vorgang zumindest sichbar machen. Auch kann man so z.B. sehen, ob der lokale Cache auf dem Host die Antwort geliefert hat, wenn keine DNS Pakete gesendet werden, die Anwendung aber dennoch funktioniert. Man kann auch in die DNS-Pakete schauen, um Details über den Auflösungsprozess aus dem DNS Header zu erfahren. Was Wireshark aber nicht leistet, ist dass man DNS Pakete selbst erstellen und senden kann und den Auflösungsprozess steuern kann. Dafür gibt es aber ein Werkzeug, dass wir heute besser kennenlernen: dig.

Der Domain Information Groper

Die man page von dig beschreibt den Funktionsumfang und Anwendungszweck von dig eigentlich am besten:

dig (domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Other lookup tools tend to have less functionality than dig.

Ich persönlich würde noch hinzufügen, dass dig hervorragend eingesetzt werden kann, um die Funktionsweise des DNS praktisch zu erlernen.

dig ist also ein Kommandozeilenwerkzeug, um Anfragen an DNS-Server zu schicken. Als Antwort gibt es die Informationen aus dem DNS-Auflösungsprozess und Meta-Informationen (z.B. wie lange es gedauert hat eine Antwort zu bekommen). Was und wie angefragt wird kann man dabei über Kommandozeilenargumente sehr genau einstellen. Das erlaubt es ziemlich viel auszuprobieren und ich kann Sie nur auffordern dies auch zu tun. Aber als erstes hier als Beispiel, ein einfacher Aufruf von dig:

student@lernVM:~$ dig www.example.com

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52300
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.example.com.		IN	A

;; ANSWER SECTION:
www.example.com.	13184	IN	A	93.184.216.34

;; Query time: 6 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Mar 29 14:00:24 CEST 2020
;; MSG SIZE  rcvd: 60

Der Aufruf von dig war hier einfach:

dig www.example.com

Wenn das einzge Kommandozeilenargument ein DNS-Name ist (hier www.example.com), dann wird der A-Record zu diesem Namen (also die IPv4-Adresse) angefragt. In der Antwort oben sieht man alles, was wir im DNS-Header erwarten. Dort ist z.B. die ID angegeben und die Flags des DNS-Headers. Hier sind die drei folgenden Flags gesetzt:

Noch interessant wäre das aa-Flag (autoritative answer), d.h. ob die Antwort eine autoritative Antwort ist. Da aa hier nicht vorkommt, ist die Antwort wohl aus einem Cache gekommen.

Nach den Flags kommen die Counter. In der Antwort steht die ursprüngliche Anfrage, eine Antwort auf diese Anfrage und ein Eintrag in der Additional Section des DNS Pakets. Die Frage wird dann auch aufgelistet und man sieht, dass der A-Record angefragt wurde. Die Antwort beinhaltet dann auch die IPv4-Adresse, die angefragt wurde. In der Answer Section ist noch etwas aufgetaucht, eine Zahl (13184). Das ist die TTL, die wir schon als Teil der Resource Records kennengelernt haben.

Ganz unten in der Antwort stehen noch ein paar Meta-Daten. Z.B. der Server, der geantwortet hat, die Größe der empfangenen Antwort, die Dauer der Anfrage und ein Zeitstempel.

Soweit, so einfach.

Typische Anwendung

Die typische Anwendung von dig sieht in etwa so aus:

dig @server name type

wobei:

Aus dem obigen Aufruf von dig können wir jetzt auch ganz explizit die Anfrage nachbilden mit:

dig @127.0.0.53 www.example.com A

Interessanter wäre es natürlich gewesen etwas völlig anderes anzufragen, aber dazu kommen wir noch.

Schalter, Schalter, Schalter

Es gibt wie schon erwähnt viele Schalter, mit denen man die DNS-Anfrage beeinflussen kann. Allumfassend ist dabei natürlich die man page. Wir schauen uns einige ausgewählte Schalter an.

Mit -x kann man die Umkehroperation zur normalen DNS-Auflösung durchführen. D.h. anstatt einen Namen in eine IP-Adresse aufzulösen wird aus einer IP-Adresse ein Name aufgelöst. Das DNS unterstützt diese Operation mit einem cleveren Trick und nennt sich Reverse DNS. Nach dem -x-Schalter muss gefolgt von einem Leerzeichen eine IP-Adresse folgen. Mehr dazu aber in den Aufgaben.

Dann gibt es noch eine Reihe an Flags, mit denen man Dinge ein, oder ausschalten kann:

Mit diesem Wissen ausgestattet kann es nun losgehen.

Jetzt sollten Sie in der Lage sein...

Spielen Sie ein bisschen mit dig herum. Keine Angst, Sie können nichts kaputt machen.

Viel Erfolg!

Zunächst ein paar Fingerübungen, damit Sie den Paketaufbau von DNS und den Ablauf einer Anfrage kennenlernen. Starten Sie die Paketaufzeichnung mit Wireshark und öffnen Sie www.spiegel.de im Browser. Nachdem die Seite vollständig geladen ist stoppen Sie die Aufzeichnung. Im ersten Praktikum sollten Sie den Umgang mit Wireshark erlernt haben. Wenn Sie das DNS-Vorlesungsmaterial angeschaut haben und sich mit DNS vertraut gemacht haben, dann sollte die Anwendung des dns-Wireshark-Filters keine größeren Schwierigkeiten verursachen.

Versuchen Sie nun folgende Fragen zu beantworten:

  1. Wieviele DNS Anfragen werden gesendet? Wieviele IPv4 und wieviele IPv6 Adressen wurden versucht aufzulösen? Hint
  2. Warum werden so viele DNS-Anfragen gesendet? Hint
  3. Wohin werden die Anfragen geschickt? Was ist das für ein Server? Hint
  4. Wird rekursive Auflösung angefragt? Hint
  5. Sind die Antworten autoritativ? Hint
  6. Wie sind Domänennamen im DNS-Paket kodiert? Hint

Jetzt werden Sie selbst DNS-Anfragen erstellen, um so DNS besser zu verstehen und Probleme mit DNS in Zukunft selbst lösen zu können. Nutzen Sie dig um folgende Fragen zu beantworten:

  1. Lösen Sie die IP-Adresse vom Webserver von heise.de auf. Wie lautet diese? Hint
  2. Holen Sie sich zusätzlich die autoritative Antwort (wen müsste man da wohl fragen und wie komme ich an den Namen, bzw. an die IP-Adresse?)! Hint
  3. Wie lautet die IPv4-Adresse des Mail-Servers von heise.de? Hint
  4. Gibt es eine IPv6-Adresse für den Webserver von heise.de? Hint

Jetzt versuchen wir die vorher eingeführten Schalter von dig einzusetzen, um DNS noch besser kennenzulernen.

  1. Wir hatten gesehen, dass dig mit +trace die iterative Auflösung selbst übernehmen kann. Schauen Sie sich die Auflösung genau an (auch in Wireshark!), um zu verstehen, wie die iterative Auflösung funktioniert. Sie müssen noch einen Namensserver mit angeben (z.B. mit @1.1.1.1).
  2. Welche Server werden in der Kette angefragt (versuchen Sie diese Frage mit Wireshark zu beantworten)?
  3. Was wird angefragt (nur bezüglich des aufzulösenden Namens, den Sie im dig-Kommando angegeben haben, nicht die Namensauflösungen der Namensserver, die auch passieren)?
  4. Was antworten die Root- und TLD-Server? Besser gefragt, wie drücken diese aus, dass ein anderer Server gefragt werden muss?
  5. In Wireshark sehen wir die IP-Adressen der Server, die wir anfragen. Kann man anhand der IP Adressen auch die Namen dazu finden? Ja, man kann: mit reverse DNS. Benutzen sie den -x-Schalter, um die IP Adresse vom heise.de-Webserver in den Namen des Webservers aufzulösen. Fällt Ihnen bei der Anfrage etwas auf? Was ist mit der angefragten IP-Adresse passiert?

Zum Schluss schauen wir uns noch etwas Interessantes an: CDNs (Content Distribution Networks). Bevor wir uns CDNs anschauen, ein paar Worte zur Funktion und Existenzberechtigung von CDNs. CDNs haben über das ganze Internet verteilt Server stehen (sehr, sehr viele Server). Die generelle Idee hinter einem CDN ist, dass CDN-Kunden ihre Inhalte auf diesen Servern ablegenm, damit sie nah beim Endnutzer sind. Dadurch können diese Inhalte schneller zum Nutzer ausgeliefert werden (plus Hochverfügbarkeit der Daten etc.). Damit man mal ein Gefühl dafür bekommt wie gigantisch diese Dienstleister seien können, hier das Beispiel Akamai. Akamai allein hat:

approximately 325,000 servers in more than 135 countries and nearly 1,435 networks around the worldQuelle.

Aber nicht nur die Größe dieser Content-Netzwerke ist beeindruckend. Auch die Spitzenlasten lassen sich sehen:

Akamai delivers daily Web traffic reaching more than 50 terabits per second Quelle, s.o.

Die Grundlage vieler CDNs ist dabei DNS. Um zu verstehen wie genau DNS dabei genutzt wird, schauen wir uns die Abbildung unten an. Ein CDN-Kunde tritt zunächst die autoritative DNS-Auflösung an den CDN-Provider für die zu hostenden Namen ab, d.h. der autoritative DNS-Server wird nun vom CDN-Provider gestellt. Im Bild links sieht man den iterativen DNS-Auflösungsprozess, wie wir ihn bisher kennengelernt haben. Der Host sendet seine Anfrage and den rekursiven DNS-Server, der die gesamte Anfrage abwickelt und dem Host letztendlich die Antwort sendet. Der autoritative DNS-Server am Ende der iterativen Auflösung ist nun in CDN-Provider Hand, und dieser muss nun mit der IP-Adresse des für den Kunden besten (meist der topologisch nähste) Servers des CDN-Providers antworten. Diese Information ,also was der zum Host topologisch nächste Server ist, ermittelt der autoritative DNS-Server aus der IP-Adresse der Anfrage. Hier stellt sich aber ein Problem, denn der CDN-DNS-Server hat niemals mit dem Host direkt Kontakt, sondern nur mit dem von ihm genutzten rekursiven DNS Server. D.h. der DNS-Server kennt nur die IP-Adresse des rekursiven DNS-Servers und nicht die des Clients. Anders ausgedrückt, der autoritative DNS-Server kann nur einen CDN-Server für die Antwort auswählen, der nah beim rekursiven Server ist. Da der rekursive Server und der Host in der Regel topologisch sehr nah beieinander sind, ist dies in der Praxis tatsächlich kein Problem.

CDN Aufbau

Jetzt, da die Funktion von vielen CDNs bekannt ist, versuchen Sie sich an folgende Aufgaben:

  1. Finden Sie bitte folgende Informationen: a) die IP-Adresse von www.audi.com, den Namensserver von audi.com und www.audi.com, und die Route zu www.audi.com (mithilfe von traceroute . Nutzen Sie hier nicht den Namen. Akamai selbst antwortet meist nicht auf traceroute-generierte Pakete, daher kommen von dort keine Antworten. Der letzte Name vor den Sternchen * ist wahrscheinlich sehr nah am Ort des Akamai-Servers). Was fällt Ihnen dazu auf. Wer ist wofür verantwortlich? Wo befindet sich www.audi.com?
  2. Jetzt nehmen wir einen speziellen, offenen DNS resolver unter der 8.8.8.8 (Google Public DNS), um diese Anfragen erneut zu stellen. Was stellen Sie fest? Hat sich etwas verändert? Finden Sie mit traceroute heraus wo sich die 8.8.8.8 befindet.
  3. Jetzt nehmen wir einen DNS-Server auf einem anderen Kontinent von folgender Webseite: http://public-dns.info/. Stellen Sie die o.g. Anfrage nach www.audi.com nun an diesen Server und nutzen die aufgelöste IP-Adresse in traceroute. Wo liegt www.audi.com jetzt?
  4. Zu guter letzt, finden Sie den/einen Namensserver von der TU München (tum.de). Bitten Sie diesen www.audi.com aufzulösen. Macht er es? Überlegen Sie sich, warum dieser Server sich so verhält.

Ich würde mich über Ihre Kritik und Verbesserungsvorschläge freuen. Auch Lob, klar. Eine kurze Umfrage finden Sie hier.