DNSSEC Pt.1: Resolver

Dies ist ein technischer Beitrag zum Thema DNSSEC Validierung.

Seit 15. Juli 2010 ist die Root Zone mit DNSSEC signiert (Siehe http://www.root-dnssec.org). So ist es nun möglich, die ganze Trustkette herzustellen und mit dem Root Key bis auf die Host Einträge zu validieren. Voraussetzung: alle Teile des FQDN unterstützen DNSSEC und sind signiert. D.h. auch die Top Level Domain (TLD) muss signiert sein. Im Falle von .ch/.li hat Switch bereits den Betrieb gestartet. Siehe http://www.switch.ch/dnssec.

In diesem Blog Beitrag zeige ich die Einrichtung eines validierenden Resolvers am Beispiel von Unbound und Bind. Als zusätzliche Konfiguration zeige ich, wie Unbound konfiguriert werden kann, gewisse Domains aus einem lokal installierten Bind (oder einem anderen DNS Server, wie z.B. Active Directory) zu beziehen und doch noch ein dynamisches Update der DNS Zonen vom DHCP Server zu erlauben. Da es bereits viele Anleitungen auf Englisch gibt, schreibe ich diesen Beitrag auf Deutsch.

Einrichten von Unbound

Unbound ist ein sehr leistungsfähiger Resolver, welcher DNSSEC von Anfang an unterstützt hat. Folgende Schritte sind nötig, einen lokalen, validierenden Unbound-Resolver einzurichten:

1. Installation von Unbound: Abhängig vom System. Unter Debian/Ubuntu reicht ein "apt-get install unbound"
2. Erstellen der Datei /etc/unbound/root.key mit dem Inhalt:
   

   . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

   Der Inhalt kann zur Sicherheit auch von https://data.iana.org/root-anchors/ bezogen werden!

3. Einrichten der Unbound Konfigurationsdatei wie folgt:
   

   server: 	# chroot disabled here as example, to make pathnames work 	chroot: "" 	directory: "/etc/unbound" 	# root key file, automatically updated 	auto-trust-anchor-file: "/etc/unbound/root.key"

4. Restart von Unbound und testen der Konfiguration:
   <code></code><code>
   user@host:~$ dig . SOA +dnssec
   
   ; <<>> DiG 9.7.1-P2 <<>> . SOA +dnssec
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35069
   ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 1</code>
   
   Wichtig ist das "ad" Bit, welches darüber informiert, dass die Antwort erfolgreich validiert wurde.

Nun läuft auf "localhost" ein einfacher Resolver, welcher die Antwort eines DNSSEC-fähigen DNS Servers validiert. Weitere Konfigurationsinfos siehe weiter unten.
Dank der Unterstützung von RFC 5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors, Unbound Config-Key "auto-trust-anchor-file"), wird der Root Key automatisch erneuert und man muss sich nicht mehr selber darum kümmern.

Einrichten von Bind

Auch Bind ist in der Lage, DNSSEC Antworten zu validieren. Die Einrichtung ist in wenigen Schritten erledigt:

1. Installation von Bind: Abhängig vom System. Unter Debian/Ubuntu reicht ein "apt-get install bind9"
2. DNSSEC Key aus Root Zone auslesen
   

   dig . dnskey

   ;; ANSWER SECTION: .			71410	IN	DNSKEY	256 3 8 AwEAAb...                                                         QjHQ3F...                                                         DNFv34...                                                         8Icy19hR .			71410	IN	DNSKEY	257 3 8 AwEAAagA...                                                         FVQUTf6v...                                                         bfDaUeVP...                                                         X6RS6CXp...                                                         W5hOA2hz...                                                         Qageu+ip...                                                         QxA+Uk1ihz0=

   Es wird der Wert hinter "257" benötigt -> Speichern in Datei. Dies ist der sogenannte "Secure Entry Point" oder "Key Signing Key (KSK)". Der Wert hinter "256" ist der "Zone Signing Key (ZSK)". Dieser validiert die Resource Records. Der ZSK wiederum wird durch den KSK validiert.
   
   
3. Umwandeln in DS Record für Bind Konfiguration
   

   /usr/local/sbin/dnssec-dsfromkey -2 -f /path/to/keyfile .

4. Nun wird dieser DS Record in die Bind Konfiguration eingetragen
   

   managed-keys {         "." initial-key 257 3 8 "AwEAAagAIKlVZrp..."; };

5. Als letztes wird DNSSEC in Bind aktiviert (Eintrag in der "options" Konfigurationssektion)
   

   dnssec-enable yes; dnssec-validation yes;

6. Restart von Bind und testen der Konfiguration
   <code>user@host:~$ </code><code>dig . SOA +dnssec</code>

Da Bind RFC 5011 (noch) nicht unterstützt, muss von Zeit zu Zeit der Root Key von Hand erneuert werden.

Firefox Extension

Für Firefox gibt es eine Extension, welche den Status der DNSSEC Validierung im Adressfeld anzeigt: DNSSEC Validator
Leider stürzt Firefox immer ab, wenn mehrere Tabs gleichzeitig offen sind. Man kann nur hoffen, dass diese Funktionalität bald in Firefox (und vielen anderen Browsern und Software Produkten) eingebaut wird.

Erweiterte Konfiguration von Unbound

Nun möchte man evtl. gewisse lokale Zonen von einem anderen DNS Server (z.B. Active Directory oder lokaler Bind) geliefert haben. Das lässt sich über folgende Konfiguration bewerkstelligen:

server:
        interface: 127.0.0.1
        interface: 192.168.1.2
        interface: ::0
        access-control: 0.0.0.0/0 allow
        access-control: ::0/0 allow
        chroot: ""
        logfile: "/var/log/unbound.log"
        log-time-ascii: yes

        private-address: 10.0.0.0/8
        private-address: 172.16.0.0/12
        private-address: 192.168.0.0/16
        private-address: 192.254.0.0/16
        private-address: fd00::/8
        private-address: fe80::/10
        private-domain: "yourdomain.ch"
        private-domain: "1.168.192.in-addr.arpa"
        local-zone: "1.168.192.in-addr.arpa." transparent

        do-not-query-localhost: no
        auto-trust-anchor-file: "/etc/unbound/root.key"

stub-zone:
      name: "yourdomain.ch"
      stub-addr: ::1@10053
      stub-prime: no
      
stub-zone:
      name: "yourdomain2.ch"
      stub-addr: 127.0.0.1@10053
      stub-prime: no
      
stub-zone:
      name: "1.168.192.in-addr.arpa"
      stub-addr: 127.0.0.1@10053
      stub-prime: no

Erklärung zur Konfiguration:

• interface: Sorgt dafür, dass Unbound auf den angegebenen Interfaces auf Port 53 auf Anfragen wartet
• access-control: Diese Parameter erlauben allen Hosts abfragen zu machen (IPv4 und IPv6)
• private-address: Zusätzliche Sicherheit. Definiert private IP Adressen, welche niemals von einem öffentlichen DNS Server zurückgegeben werden dürfen.
• private-domain: Diese Domains dürfen private IP Adressen zurückgeben
• local-zone: Wird für Reverse Lookups benötigt
• stub-zone: Definition der lokalen Domains, welche auf einem anderen DNS Server liegen
• name: Name der lokalen Domain
• stub-addr: Adresse und Port des DNS Servers (Dieses Beispiel sendet die Anfrage an einen lokalen Bind Server, welcher auf Port 10053 lauscht. yourdomain.ch via IPv6 und yourdomain2.ch via IPv4)
• stub-prime: Verhindert die Auswertung der NS Records des Stub DNS Servers

Damit Bind auf 127.0.0.1 Port 10053 lauscht, ist in der Bind Konfiguration (Sektion options) folgendes einzutragen: listen-on port 10053 { 127.0.0.1; };

Falls auf demselben Server ein DHCP Server eingerichtet ist, welcher dynamische DNS Updates macht, gibt es nun ein Problem: Es ist nicht möglich, dem DHCP Server einen anderen Port als der DNS Port 53 anzugeben, an welchen DNS Updates gesendet werden sollen. Die Lösung: Bind soll zusätzlich noch auf 127.0.1.1 (virtuelles Interface lo:1) Port 53 lauschen (listen-on port 53 { 127.0.1.1; };) und dem DHCP Server diese IP Adresse konfigurieren:

zone yourdomain.ch. {
        primary 127.0.1.1;
        key DHCP_UPDATER;
}

zone 1.168.192.in-addr.arpa. {
        primary 127.0.1.1;
        key DHCP_UPDATER;
        }

Der Grund für den Aufwand mit einer zweiten localhost ist folgender: Ich möchte, dass der Server auch auf 127.0.0.1 validierte Antworten bekommt und der Bind Server kein Resolving mehr macht, sondern nur noch Unbound. Bind soll jedoch weiterhin für lokale Zonen zuständig sein. Bind ist nicht mehr im Netzerk erreichbar, sondern nur noch lokal auf 127.0.0.1:10053 und 127.0.1.1:53. Das ganze ist ein etwas komplexeres Setup, bringt aber vollständige Flexibilität mit sich.

Ein weiterer Beitrag wird sich mit dem Ausliefern signierter Zonen beschäftigen.