Wenn manche Transaktionen unerklärlich lange brauchen, müssen nicht verspätet übertragene Nutzdaten schuld sein. Es kommt nämlich auch eine stolpernde Namensauflösung als Ursache in Betracht. Sysadmin Charly hat drei Tools in Gebrauch, die den DNS-Server kritisch abklopfen.

Der pure Zufall nahm mich an die Hand und führte mich zu Dnsping, Dnstraceroute und Dnseval. Die Toolsammlung rund um die Namensauflösung nennt sich Dnsdiag [1]. Ich brauche Python 3 und Pip 3, um das Trio zu installieren und zu betreiben, sowie »sudo«-Aufrufe, damit es ICMP-Sockets anlegen darf.

Dnsping macht seinem Namens alle Ehre, fragt einen DNS-Server wiederholt ab und stellt die Antwortzeiten dar. Als Parameter ist der aufzulösende Hostname zwingend. Dnsping befragt den Default-Nameserver des Systems, was sich mit »-s Nameserver« ändern lässt. Mit

sudo dnsping.py -v -s 8.8.8.8 linux-magazin.de

frage ich einen öffentlichen DNS-Server von Google ab. Dessen Antworten lagen bei mir bei 20 Millisekunden, dem Vierfachen meines Provider-DNS.

Dnseval fragt gleich mehrere Server parallel ab. Als Wettkampfrichter stellt es die Ergebnisse so dar, dass ich gleich sehe, welcher Server am schnellsten oder langsamsten antwortet. Eine Liste der zu überprüfenden Server schreibe ich in eine Textdatei, ein Server pro Zeile. Listen von öffentlichen DNS-Servern sind leicht zu finden, ich habe mich bei [2] bedient und von dort die ersten fünf Server der Liste genommen. Der Aufruf sieht so aus:

sudo dnseval.py -f ./liste.txt -c 5 linux-magazin.de

Beim Ergebnis in Abbildung 1 beachtlich finde ich die Diskrepanz zwischen minimaler und maximaler Antwortzeit.

Abbildung 1: Überraschender noch als die Unterschiede zwischen den fünf per Dnseval zeitgestoppten Servern ist die Minimal/Maximal-Diskrepanz jedes einzelnen.

Ein Wegelagerer?

Dnstraceroute ermittelt den Pfad, den meine DNS-Abfrage bis zum Ziel nimmt. Vergleiche ich ihn mit einem klassischen ICMP-Traceroute, so komme ich durch Abweichungen vom rechten Wege einem Angreifer auf die Schliche, der meine DNS-Anfragen entführt, um mir etwas unterzujubeln. Mein Testaufruf lautet:

sudo dnstraceroute.py --expert --asn -C -s 8.8.4.4 linux-magazin.de

Das Ergebnis zeigt Abbildung 2. Der Parameter »–expert« liefert Tipps, wenn an der Ausgabe etwas nicht sauber erscheint – etwa wenn der Zielserver nur einen Hop von einer privaten IP-Adresse (RFC 1918) entfernt liegt. Fehlalarme passieren auch, wenn der Admin nicht auf einem Cloudserver, sondern lokal arbeitet, und auf dem Router ein DNS-Cache wie Dnsmasq [3] läuft.

Der Parameter »–asn« zeigt für jeden Hop an, im Netz welches autonomen Systems (AS) sich die Adresse befindet. So sehe ich schnell, wo der Vorgang die Providergrenze überschreitet. (jk)

Abbildung 2: Dnstraceroute verfolgt den Weg einer Namensauflösung.