Konfiguration mit BIND >9.8

Bei der Einführung von DNSSEC ist die Einrichtung der DNSSEC-Überprüfung auf den eigenen Resolvern der einfachste Vorgang. Dazu müssen keine DNSKEYs erstellt werden oder Zonen regelmäßig signiert werden.

Es ermöglicht aber DNS-Abfragen fremder autoritativer Nameserver zu validieren und damit den Clients authentizierte Antworten (AD Flag) zu liefern. Ein validierender Nameserver, dem man vertraut, ist die Voraussetzung zur Einrichtung ausgehender DANE-Validierung TLS-verschlüsselter Übertragung zwischen Mailservern.

Schritt-für-Schritt-Anleitung

In diesem Howto-Artikel wird erklärt wird ein validierender Nameserver mit BIND >9.8 konfiguriert und auf seine Funktion getestet werden kann.

Eine ausführliche englisch-sprachige Abhandlung aller DNSSEC-Einstellung und Hintergrundinformation findet sich auf der BIND-Dokumentationsseite (als PDF-Dokument)

Mindestanforderungen
BIND Konfiguration
Testen der DNSSEC-Validierung
Clients und DNSSEC

1. Mindestanforderungen

DNSSEC-Validierung wird von BIND seit Version 9 unterstützt. Bei selbstkompilierten Versionen müssen diese gegen openssl gelinkt sein. Es ist aber zu empfehlen eine Version größer als 9.8 zu verwenden, die die Schlüssel der root-Domain "." selbst installiert bzw. herunter lädt.

2. BIND Konfiguration

In den Optionen der BIND-Konfiguration, named.conf, je Distribution in /etc/ (z.B. SuSE), /etc/bind/ (z.B. Debian) oder /etc/named/ (z.B. ) muss die DNSSEC-Validierung angeschaltet werden, und ein Verzeichnis zur Ablage temporärer Daten mit dem Keyword directory angegeben werden.

Seit BIND 9.5 sind sowohl dnssec-enable als auch dnssec-validation default yes, es sollte aber ein Verzeichnis für die temporären Daten gesetzt sein.


options {
  directory "/var/cache/bind";
};

Ab BIND Version 9.8 kann dnssec-validation auto gesetzt werden, damit BIND die managed-keys (d.h. den .root-DNSKEY) selbst verwaltet, also auch einen zukünftigen neuen .root-DNSKEY herunterlädt. Diese Einstellung ist zu empfehlen!


options {
  directory "/var/cache/bind";
  dnssec-validation auto;
};

Sollten sich die bind.keys (enthält den .root-Schlüssel als Ankerpunkt für die "chain of trust") nicht im default Verzeichnis /etc/bind/ befinden muss das mit dem Parameter bindkeys-file angegeben werden.

Dann muss BIND noch neu gestartet werden, je nach Distribution:

service named restart oder (CentOS / RHEL / Fedora)

service bind9 restart oder (Debian / Ubuntu)

/etc/init.d/bind9 restart (alternativ auf Debian / Ubuntu)

Ist der Nameserver sowohl rekursiv als auch autoritativ (das ist aber NICHT zu empfehlen) sollte noch ein spezielles managed-keys-directory gesetzt werden:

options {

...

managed-keys-directory "managed-keys";

}

wobei dies ohne absoluten Pfad ein Unterverzeichnis des in directory angegebenen Verzeichnisses ist.

NB: Im unter directory bzw. managed-keys angegebenen Verzeichnis finde Sie dann die Dateien managed-keys.bind, die die Schlüssel selbst enthält und das Journal managed-keys.bind.jnl für die dynamischen Schlüsselupdates.

Wenn DNSSEC-Validierung eingeschaltet und korrekt konfiguriert ist, wird der Resolver alle Antworten von signierten sicheren Zonen ablehnen, die bei der Validierung durchfallen (z.B. abgelaufene Signaturen besitzen), ablehnen und SERVFAIL an den Client zurück geben.

3. Testen der DNSSEC-Validierung

Beachten Sie, dass Sie zum Testen der Validierung einen autoritativen Nameserver abfragen müssen, der für seine Zone selbst DNSSEC-Signierung aktiviert hat! Die LRZ-Nameserver unterstützen schon seit einigen Jahren DNSSEC, alternativ kann der Nameserver des Internet Standards Consortiums (ISC) mittels dig abgefragt werden.

dig +dnssec www.lrz.de

dig +dnssec www.isc.org

Die Antwort in der "Answer Section" sollte DNSSEC-Signaturen (RRSIG Resource Records) enthalten. Die kompaktere Information, die letztendlich an Clients weitergereicht wird, ist die Prüfung nur auf das "AD" Flag.

AD Flag

"AA"-Flag (Authoritative Answer) und "AD" (Authenticated Data) schließen sich aber aus - d.h. auch eine DNSSEC-signierte Antwort eines autoritativen Nameservers wird nie das AD, sondern nur das AA Flag zeigen!

Darum müssen wir hierfür einen anderen autoritativen Nameserver fragen:

dig +ad www.mpg.de

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4

4. Clients und DNSSEC

Onlinetest

Intern nutzen die TCP/IP-Stacks der Betriebssysteme einen stub resolver, der aber die Antworten nur weiter reicht und nicht validiert. Clients müssen sich damit zufrieden geben, einem ihnen als DNSSEC-validierenden Nameserver (z.B. der ihrer Hochschule eingetragen in /etc/resolv.conf) zu vertrauen. Darüber versichern können sich sich durch das manuelle Prüfen auf as "AD"-Flag.

Auf Internet.nl kann man testen, ob der vom Client verwendete Nameserver DNSSEC-validierend ist oder nicht.

Firefox Add-on

Für Mozilla Firefox gibt es das Add-on/Plugin DNSSEC/TLSA-Validator, das durch ein Symbol in der Adressleiste signalisiert, ob eine DNSSEC-validierte IP als DNS-Antwort zurück kam.

DNSSEC-Validator-Addon

Lokaler stub-resolver

Wenn man die DNSSEC-Validerung auch bis auf die Client-Seite konsequent durchziehen will, muss man sich einen validierenden stub-resolver einrichten. Die Anwendungen auf dem Client fragen dann zuerst den lokalen stub-resolver, der die Antworten an einen (vertrauenswürdigen!) rekursiven Resolver weiter reicht, der dann die Antwort der hierarchischen DNS-Abfrage ermittelt.

Aus Sicherheitsgründen sollte der stub-resolver so konfiguriert sein, dass er nur Anfragen des localhost akzeptiert.

BIND kann auch auf Unix-Workstations installiert und in dieser Weise konfiguriert werden, eine leichtgewichtigere Alternative ist Unbound (ab Version 1.4).

Unbound als stub resolver unter Mac OS X konfigurieren.

Unbound als validierender (stub) Resolver unter Windows konfigurieren.