Infrastruktur Transparenz: DNS Server

This entry is part 1 of 1 in the series Infrastruktur Transparenz
  • Infrastruktur Transparenz: DNS Server

DNS, also das Domain Name System, ist heute als Infrastrukturdienst nicht mehr weg zu denken. Im Zeitalter von Technologien wie Kerberos, Jabber oder Active Directory sind wir – durch die Nutzung von z.B. SRV Records – über das Verteilen von zentral gepflegten hosts-Dateien weit hinaus. Aber wie kann ich den Zustand und die Qualität meines DNS Dienstes messen?

Monitoring

Ein einfaches Monitoring von DNS Servern läßt sich zum Beispiel mit Nagios und dem check_dig Plugin realisieren. Um zu vermeiden, daß der DNS aus seinem lokalen Cache antwortet bietet es sich an einen Record mit extrem niedriger TTL zu konfigurieren und diesen zum Monitoring zu nutzen; weitreichendere Setups für rekursive DNS Server sind mit Plugins wie check_multi realisierbar. Doch welche Aussage kann man an Hand dieser Checks treffen? Man kann mit Sicherheit sagen, daß für definierte Records der DNS Server dem Nagios Host in einer bestimmten Zeit antwortet. Auch der Inhalt der Antwort kann mit check_dig ausgewertet, und somit die Datenquelle des DNS Systems bewertet werden. Für viele DNS Setups ist diese Form von Monitoring ausreichend und die Admins können sich wieder anderen Themen widmen … wäre da nicht der Client Support.

„Mein Internet ist langsam!“

Oder „Google funktioniert nicht.“ sind nur zwei Beispiele, die je nach Situation durchaus auf langsame oder ausbleibende DNS Antworten zurück zu führen sind. Benutzer sind eben doch das effizienteste Monitoring und ist das Problem nach dem obligatorischen Reboot des betroffenen PCs nicht behoben geht die Fehlersuche los.

Hier kommt DSC, der DNS Statistics Collector ins Spiel. DSC sammelt lokal auf den DNS Systemen mittels libpcap den DNS Traffic ein und übermittelt alle Anfragen und deren Antworten an ein zentrales System zur Auswertung. Sind die eingesetzten DNS Rekursoren Windows Server oder Appliance Systeme können die Daten auch auf Netzwerk Ebene über einen mirror Port ausgeleitet werden. Die zentrale Komponente nimmt die Daten entgegen, aggregiert und visualisiert sie und bietet über eine Web-Schnittstelle mehrere Ansichten die in kürzester Zeit eine Aussage über die Qualität des DNS Systems treffen lassen. Beispielsweise das Verhältnis von SERVFAIL zu NOERROR oder die blanke Anzahl von NXDOMAIN pro Server pro Zeiteinheit. Steigt die Anzahl von NXDOMAIN Antworten auf autoritativen DNS Servern wurde möglicherweise eine Zone nicht geladen oder liefern die Rekursoren plötzlich vermehrt SERVFAIL aus stimmt potentiell an den Firewalls etwas nicht.

Screenshot DSC Statistics Presenter

Anfragestatistik: Query Typen pro Zeit

Auslastungsstatistik in tiefer Detailstufe

Aber es geht noch viel mehr, denn die Informationen die DSC gesammelt hat ermöglichen auch eine Auslastungsstatistik in tiefer Detailstufe. So ist es beispielsweise möglich die Anzahl der Queries pro Subnetz zu überwachen, mit der durchschnittlichen Antwortzeit in diesem Netzsegment in Korrelation zu setzen und damit Subnetze zu finden in denen sich lokale Rekursoren lohnen würden.

Wie funktioniert das nun technisch? Wie bereits erwähnt besteht DSC aus zwei Komponenten: dem Collector der die Daten sammelt und dem Presenter als zentrale Instanz zur Auswertung. Der Collector läuft als Daemon auf den DNS Servern und sammelt jedweden Traffic auf Port 53 (konfigurierbar, falls man den DNS Dienst nicht auf Port 53 fährt) ein und speichert die Verkehrsdaten in 60s Häppchen in einem XML Containerformat auf die Festplatte. Ein weiterer Prozess übermittelt die XML Dateien an den DSC Presenter. Im Falle eines einzelnen Systems können beide Rollen auf dem gleichen Server installiert werden, im Normalfall ist allerdings eine zentrale Instanz zur Auswertung die bessere Wahl, denn die Auswertung ist sehr CPU und I/O itensiv. Als Übermittlungstechnologie wird SSH, rsync und WebDAV mit X.509 unterstützt, möchte man allerdings z.B. NFS nutzen ist dies mit nur wenigen Handgriffen machbar. Der Presenter arbeitet ebenfalls mehrstufig. Ein Prozess, wieder per cron, überträgt die Verkehrsdaten aus dem XML Container in ein internes Format und legt sie an die Stelle im Dateisystem an der das CGI basierte Web-Interface die Daten erwartet. Das CGI verwendet ploticus zur Visualisierung und erzeugt die Graphen je nach angeforderter Ansicht on the fly.

Anders als bei z.B. Round Robin Datenbanken ist die Datenhaltung von DSC nicht verlustbehaftet. Man kann somit in unveränderter Detailtiefe in die Vergangenheit sehen, braucht aber auch die Storage Kapazität um die Daten für den angestrebten Zeitraum zu speichern. Sind nur die Statistiken der z.B. letzten 13 Monate interessant, bietet sich ein cron-Job an, der regelmäßig über den Datenbestand scannt und alle Dateien löscht die älter als 400 Tage sind.

DSC ist in C und Perl geschrieben und benötigt neben libpcap und ploticus nur eine Hand voll Perl Module aus CPAN. Es ist somit auf nahezu jedem unixoiden System lauffähig.

Wer ähnliches vorhat und dabei Unterstützung braucht, wendet sich gerne an unser Managed Service Team (über den Support zu erreichen). 

Sebastian Laubscher

Sebastian arbeitet seit Sommer 2013 für teamix als Senior Consultant und Trainer. Seine Kompetenzen liegen in den Bereichen Netzwerktechnik und Unix-/Linux Administration, speziell im Bereich der Automatisierung mit Puppet. Vor der Zeit bei teamix war er für einen großen deutschen ISP tätig.

 
Kommentare

Das native DSC Interface kann man aber getrost als hässlich bezeichnen. Es gibt seit einiger Zeit das DSC-ng Projekt der nic.cz welches zwar den DSC Collector weiterverwendet, die Daten aber in Postgresql aggregiert und ein zeitgemäßes Interface präsentiert.

http://www.dscng.cz/pages/installation.html

Hinsichtlich der Überwachung mit Nagios (*hust* Icinga *hust*) und der Erreichbarkeit der eigenen Zone von verschiedenen Locations aus gesehen ist imho das RIPE Atlas Projekt sehr interessant.

https://www.icinga.org/2014/03/05/monitoring-ripe-atlas-status-with-icinga-2/

Danke für Dein Feedback.
Neben dem RIPE Atlas Projekt ist auch der NLNOG Ring erwähnenswert. Das ist ein Zusammenschluss mehrere ISPs und Carrier weltweit die sich gegenseitig Zugang zu dedizierten Maschinen geben um remote Debugging zu ermöglichen. Zugang bekommt wer selbst eine Maschine sponsert.

https://ring.nlnog.net/

Sowohl Atlas als auch der Ring sind eigentlich eigene Artikel wert. Die Moeglichkeiten beider Technologien sind enorm – sehr schöne Idee übrigens per Icinga und Atlas zu monitoren!

Und danke für den Link zu DSC-ng; klingt als sollte ich mir das mal genauer ansehen, denn der vanilla DSC ist zugegebenermaßen wirklich hässlich.

Hinterlassen Sie einen Kommentar