summary: Praktikum 2 - Das DNS ausfragen mit dig id: lab_2 categories: Praktikum tags: DNS, dig status: Draft authors: Rolf Winter analytics account: UA-50831568-1

dig Praktikum

Einführung

Duration: 2:00

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.

Vorbereitung

Duration: 15:00

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:

• qr: query response bit (und damit eine Antwort)
• rd: recursion desired bit (war schon in der Anfrage gesetzt)
• ra: recursion available bit (hier wird das rd-Flag bestätigt)

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:

• server: Name oder IP-Adresse des Namensservers, bei dem angefragt werden soll (optional, sonst wird der lokal konfigurierte verwendet). Das @ muss dem Server-Namen, bzw. der IP-Adresse ohne Leerzeichen vorangestellt werden
• name: Name des resource records, der angefragt werden soll, z.B. www.example.com
• type: Typ des resource records, der zurückerwartet wird, z.B. MX, NS, ANY, AAAA. default: A

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:

• +[no]recurse: Hier kann man das recursion desired Flag setzen oder löschen (Beispiel: dig +norecurse www.example.com)
• +[no]short: Hier kann man nur die gesuchte Antwort ausgeben lassen (nützlich, wenn man Kommandos mit Pipes verbinden möchte)
• +[no]tcp: Man kann DNS auch über TCP nutzen, auch, wenn üblicherweise UDP genutzt wird und der Server Anfragen über TCP unterstützt
• +[no]trace: Hier kann man mit dig die gesamte iterative Namensauflösung selbst übernehmen, was ja typischerweise der rekursive Namensserver für einen macht

Mit diesem Wissen ausgestattet kann es nun losgehen.

Jetzt sollten Sie in der Lage sein…

• Komplexe Anfragen nach beliebigen Resource Records im Internet zu stellen

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

Viel Erfolg!

Aufgabe 1 - Fingerübungen mit Wireshark

Duration: 15

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

Aufgabe 2 - Selbst DNS-Anfragen stellen

Duration: 15

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

Aufgabe 3 - Komplexere Anfragen

Duration: 20

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?

Aufgabe 4 - DNS und CDNs

Duration: 20

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 world Quelle.

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.

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 <IP-Adresse von www.audi.com>. 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.

Nachbereitung

Duration: 15

• Schauen sie mal, was das DNS sonst noch so auflösen kann (welche Resource Records es sonst noch gibt). Probieren Sie einfach ein paar davon im Internet aus!
• Untersuchen Sie mal einige TTL-Werte, die im Internet verwendet werden (evtl. beim autoritativen Server anfragen!). Vergleichen Sie mal Werte von CDN-gehosteten Seiten, News Seiten, www.example.com und was Ihnen sonst noch einfällt. Versuchen Sie die Unterschiede zu erklären.
• Finden Sie doch den Namen ihres WLAN Routers zu Hause raus, also den Namen, der von Ihrem Provider vergeben wurde (Hinweis, es gibt diverse Dienste/Webseiten im Internet, die Ihnen die öffentlich sichtbare IP-Adresse Ihres Routers verraten).

Umfrage

Duration: 2

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