Monitoring DNSSEC and DANE
Dies geschieht am LRZ mit "check_mk", das im Kern auf Nagios basiert, aber eine komfortablere Oberfläche bietet.
Dies ist eine kommerzielle Lösung mit Support. Es lassen sich aber leicht Skripte in bestehende Monitoring-Lösungen integrieren. Dies wird hier am Beispiel von Nagios und Icinga2 gezeigt. Die Check-Scripte selbst können in Bash, Perl, Python oder einer nahezu beliebigen anderen Skriptsprache geschrieben werden, oder als Executable vorliegen und aufgerufen werden.
Icinga2 richtet sich nach dem Nagios-Schema der Exit codes für Check-Skripte, und die Vorgabe ist, dass diese entsprechende Statusmeldungen zurück liefern.
Nagios-konforme Exit codes
| Exit code | Bedeutung | Erklärung |
|---|---|---|
| 0 | OK | Service arbeitet wie erwartet |
| 1 | WARNING | ein bedenklicher, aber unkritischer Zustand ist aufgetreten |
| 2 | CRITICAL | kritischer Fehler |
| 3 | UNKNOWN | unbekannt, Ausführen des Checks schlug fehl |
Anhand dieser Exit codes werden dann die Service-Zustände beurteilt. Dies ist bei Nagios/Icinga(2) (und auch check_mk) gleich.
Monitoring am LRZ
Die DNS-Server werden mit unterschiedlichen Tools überwacht. Am LRZ werden die folgenden Dienste bezüglich DNSSEC überwacht:
- "check_mk" (https://mathias-kettner.de/check_mk.html) überwacht den Zustand der Hardware und überprüft, ob ein regelmäßig auftretendes Update (ein TXT-Record mit einem Timestamp) auf allen autoritativen Servern ankommt und ob NTP funktioniert.
- Ein Skript (cronjob) validiert alle DNSSEC-Zonen mit unterschiedlichen Tools (dnssec-verify von bind und ldns) und prüft mit externen validierenden DNS-Resolvern auf das AD-Flag im SOA-Record (Google-DNS 8.8.8.8, OARC BIND 9 184.105.193.73, OARC Unbound 184.105.193.74)
Icinga2
Aufgrund der einfacheren Installation, weniger Resourcenverbrauch und als Opensource freien Verfügbarkeit wurde Icinga2 als Demonstrationslösung gewählt, die auch auf den Workshop-VMs installiert ist.
Icinga2 Webinterface
Icinga2 selbst ist ein "daemon", der die Service-Checks anhand der Konfigurationen in /etc/icinga2/conf.d regelmäßig ausführt. Auf welchen Zeitintervallen ein Servicecheck durchgeführt wird, kann mit Templating oder individuell pro Host fest gelegt werden.
Anhand der durch gereichten Exit-Codes (siehe oben) der ausgeführten Checkskripte wird in der Serviceübersicht das Ergebnis dargestellt.
Icinga2 Service Übersicht, in der alle geprüften Dienste "Ok" sind.
Bei bestimmten Service-Checkergebnissen, die einen festgelegten Wert über- oder unterschreiten, wird eine Warnung angezeigt. Zum Beispiel wenn die Signaturen in einer Zonen-Datei nicht mehr lange genug gültig sind:
Check-Skripte
Allen Monitoring-Systemen liegen auf der untersten Ebene Checkskripte (oder zum Teil kompilierte Programme) zugrunde, die anhand der Ihnen als Kommandoargumente übergebenen Parameter, einen Dienst oder ein Fakt prüfen. Die Parameter legen fest, welcher Host, und beispielsweise welcher Port auf Erreichbarkeit überprüft wird.
Bash-Skript, um die DNSSEC Konfiguration mit dem Tool ldns-verify-zone aus dem ldns-Paket zu überprüfen:
CheckCommand-Definitionen
Diese Argumente werden vom darüber laufenden Monitoring-Daemon als "Check_command"-Definitionen (im Falle von Nagios und Icinga(2)) durch geschleift. D.h. für die Einbindung in Icinga2 muss eine CheckCommand-Definition geschrieben werden, die festlegt, welches Skript ausgeführt wird, in welchem Verzeichnis es liegt, und welche Parameter erwartet werden:
Service-Definitionen
Da ein "check_command" nur das Zutreffen einer bestimmten Tatsache, abhängig von dem ihm übergegebenen Host, überprüft, müssen die "check_commands" noch über Services Hosts konkret zugeordnet werden. Hier können dann Checkperiode, benachrichtigte Admins, usw. angepasst werden:
Check-Skripte Beispiele
Was an den eigenen DNSSEC- und DANE-Diensten überwacht wird, bleibt den Systemadministratoren überlassen. Eine feinkörnigere Abfrage der notwendigen Voraussetzungen für eine fehlerfreie Konfiguration erhöht zwar im Katastrophenfall die Anzahl an generierter Meldungen, kann aber die Fehlersuche etwas erleichtern.
Hier einige Beispielskripte für den Einstieg, die für die Workshop-VMs geschrieben wurden. Diese sind aber primär als Lehrbeispiele zu sehen und sollten nicht ungeprüft eins-zu-eins in eine Produktivumgebung übernommen werden:
| Skript | Überprüft... | Kommandoparameter |
|---|---|---|
| check_dnssec-ad | AD flag in der Anfrage über (OARC - oder anderen) Resolver | -z <zone> -n <resolver> |
| check_dane | TLSA-Eintrag und matcht ihn gegen das Zertifikat | -H <host> -p <port> --starttls="smtp" |
| check_namedconf | korrekte Konfiguration von BIND (/etc/bind/named.conf) | |
| check_dnssec-ldns | DNSSEC Konfiguration mit ldns-verify-zone | -z <zone> -e <expirationdate> |
| check_dnssec-keys | gibt die ZSK und KSK zurück, die es in einer Zone findet | -z <zone> |
| check_dnssec-ds | ob die Key ID im RSA-2 DS-RR einem KSK in der Zone entspricht | -z <zone> |
| check_mtu | die MTU Größe, default: Critical 1220 Bytes, Warning 2048 Bytes | -w <WARNVAL> -c <CRITVAL> |
DNSSEC Monitoring Tools
Es gibt mittlerweile eine ganze Reihe von DNSSEC-Check- und Monitoringtools für jeden Geschmack und bevorzugte (Skript-)Spracke. Mice & Men haben hierzu eine (etwas veraltete) Liste von DNSSEC-monitoring-tools zusammen gestellt.