DNSSEC mit BIND 9.9

BIND 9.9 liegt den meisten aktuellen Distributionen bei oder ist über externe repositories einfach über den Paketmanager zu installieren.

Die für das manuelle Signieren einer Zone auf einem autoritativen Zone nötigen Schritte gestalten sich bei BIND 9.9 wie folgt.

1. BIND für DNSSEC konfigurieren

dnssec-validation ist seit BIND Version 9.8 default auf yes, sollte aber für das Management des root-key (/var/cache/bind/managed-keys.bind) in /etc/bind/named.conf auf dnssec-validation auto gestellt werden.

Ferner sollte mit der Option key-directory für die Schlüssel ein eigenes Verzeichnis angegeben werden, in denen BIND beim Signierten nach gültigen DNSKEYs sucht.

/etc/bind/named.conf

options {

        ....

        key-directory "/var/bind/keys";

        dnssec-validation auto;

        .... 

};

Danach BIND mit /etc/init.d/bind9 restart neu starten.

Darum werden bei der Erstellung der DNSKEYs zwei Schlüssel erzeugt:

Zone-signing-key (ZSK)

Key-signing-key (KSK)

Unter BIND wird dafür dnssec-keygen benutzt.

dnssec-keygen kann mit dem Parameter -K <directory> angewiesen werden, erzeugte Schlüssel dort zu speichern. In diesem Fall wechseln wir aber in dieses Verzeichnis und erzeugen die Schlüssel lokal.

cd /var/bind/keys/

[root@dnssec-ws01 keys]#

2. Zone-signing key (ZSK) erzeugen

Weil RSASHA1 ursprünglich die minimale Anforderungen für DNSSEC-fähige Nameserver darstellte, ist das noch der default Algorithmus bei der Schlüsselerstellung, falls mit der Option "-a <algorithm>" keiner angegeben wird. RSASHA1 ist aber unsicher und sollte NICHT mehr benutzt werden.

Daher muss mit der Option ein Algorithmus bei der Schlüsselerzeugen angegeben werden, z.B. RSASHA256 / RSASHA512 oder elliptic curve algorithms ECDSAP256SHA256 / ECDSAP384SHA384.

Als zweiter Schlüsselparameter muss die Bitlänge angegeben werden. NIST empfiehlt für RSA-ZSK 1024 Bit. Am LRZ beträgt die Länge der auf den Nameservern verwendeten ZSKs 2048 Bit, da der Performance-Einfluss absolut vernachlässigbar ist.

Am Ende wird der Name der Zone angegeben, für die dieser Schlüssel gelten soll. DNSKEYs sind damit immer Zonen zugeordnet, und diese Meta-Information wird beim Signieren von BIND ausgewertet. Wurde ein Schlüssel für eine falsche Zone erzeugt - dnssec-keygen überprüft nicht, ob die Zone definiert ist - führt das zu Fehlermeldungen.

dnssec-keygen -a RSASHA256 -b 2048 wsXX.ws.dnssec.bayern

erzeugt ein Zone-signing-key-Paar aus öffentlichem (.key) und privatem (.private) Schlüssel:

Generating key pair.................................................+++ .............+++
Kws01.ws.dnssec.bayern.+008+45750

nach dem Namensschema

K<zonename>+<algorithm>+<keyID>

jeweils mit der Endung .key für den öffentlichen und .private für den privaten Schlüssel:

-rw-------+ 1 root root 1.8K Jan 27 16:48 Kws01.ws.dnssec.bayern.+008+45750.private
-rw-rw-r--+ 1 root root  626 Jan 27 16:48 Kws01.ws.dnssec.bayern.+008+45750.key

Die ID ist wichtig, um im Fehlerfall überprüfen zu können, mit welchen Schlüsseln BIND die Zone signiert und unterscheidet den ZSK vom KSK.

Die Schlüssel selbst sind herkömmliche RSA-Schlüssel, ohne intrinsische Gültigkeitsbeschränkung. dnssec-keygen fügt aber Meta-Informationen hinzu, die von BIND ausgewertet werden. Created, Publish, Activate geben an, wann der Schlüssel erzeugt wurde, in der Zone veröffentlicht werden soll, und aktiv zum Signieren verwendet werden soll.

Die plain-text Schlüssel-Datei kann einfach eingesehen werden:

cat Kws01.ws.dnssec.bayern.+008+45750.key

; This is a zone-signing key, keyid 45750, for ws01.ws.dnssec.bayern.
; Created: 20170127154840 (Fri Jan 27 16:48:40 2017)
; Publish: 20170127154840 (Fri Jan 27 16:48:40 2017)
; Activate: 20170127154840 (Fri Jan 27 16:48:40 2017)
ws01.ws.dnssec.bayern. IN DNSKEY 256 3 8 AwEAAb/53RK2Bsd026KxdXfA1dT3V4wki3SJUDmbIy6VlAnZCpu1S3mR x1l9BvboUiiZTG8I3LZMXHvBEGGx08v1XbwV5WXfYEBWuzS0dTvuEtxi 4483t3NWPUC+HaU+HfU4Yrh8ST3CdhcZyz3rvBs2+fRAzaMTmx3OnTwD j8DWnz07b+R4wpwFYeACXO9E+qRmb0os0pvEK7A1Fg05/ucBNEm+4DXI fT56taosSWwEsy81gmTUTjAzEpoSlI7e+Wd6zDFqDtkA8yspaW5uIRW7 ioqOfOwrVpr3NvSIQMdrqhrJ3+R7rR3Wkx2uXmf3XSy8y+9xxN/6dS4O QJyl5ZSBynk=

Die erste Zeile des Headers

; This is a zone-signing key, keyid 42396, for ws01.ws.dnssec.bayern.

sagt uns, dass der Schlüssel mit der ID 42396 ein Zone-signing key (ZSK) ist.

3. Key-signing key (KSK) erzeugen

Um die Authenzität der notwendigen Kommunikation der Delegation in der Parentzone mit einem Schlüssel signieren zu lassen, der nicht so oft erneuert oder ad-hoc gewechselt wird wie Zone-signing keys (ZSKs), wird noch ein sogenannter Key-signing key (KSK) erzeugt.

Dazu wird dnssec-keygen der zusätzliche Parameter -f KSK übergeben, um diesen Schlüssel als key-signing key zu erzeugen.

dnssec-keygen -a RSASHA256 -b 2048 -f KSK -n ZONE ws01.ws.dnssec.bayern

Generating key pair.......................................................................+++ ...............................................+++
Kws01.ws.dnssec.bayern.+008+34939

Das erzeugt wiederum ein Schlüsselpaar aus .key (öffentlichem) und .private (privatem) Schlüssel nach dem Namensschema

K<zonename>+<algorithm>+<keyID>

jedoch mit einer anderen keyID:

-rw------- 1 root root 1.8K Jan 27 16:18 Kws01.ws.dnssec.bayern.+008+34939.private
-rw-r--r-- 1 root root  625 Jan 27 16:18 Kws01.ws.dnssec.bayern.+008+34939.key

Auch in diesem Fall steht im öffentlichen Schlüsselteil in der ersten Headerzeile die Information, dass es sich hier um einen Key-signing key (KSK) handelt:

cat Kws01.ws.dnssec.bayern.+008+34939.key

; This is a key-signing key, keyid 34939, for ws01.ws.dnssec.bayern.
; Created: 20170127151820 (Fri Jan 27 16:18:20 2017)
; Publish: 20170127151820 (Fri Jan 27 16:18:20 2017)
; Activate: 20170127151820 (Fri Jan 27 16:18:20 2017)
ws01.ws.dnssec.bayern. IN DNSKEY 257 3 8 AwEAAan+qkZEzxidlNB9lLc/YCMXTwLSdNKH9RomkI6VsksDYfVUxmwM kF+j/G7oRjbEFRDRFAYk07sKqirpUMlRIKZxADrrLEWLMaLARtkaRtIE CsQATAJCKlNPnhAulOGS1H1UPmKCp8+If6CREd4Ee0J9aDyhuBa7r3VZ cLygk1OTpHGo6JrK4fMqczLBJZIGqRouyMgE6IB75UE8rW+FyYmHpe4J OFhhe3Ad/s/X6UROS3CNbtZ5DbwWV0EvI2GY2HzD3XnKlOtEh9ro3Drc CsNs/wDojfHYwkNEhBpslVdQMVS/EWnCmCpVk3J0Hl2P8xRDUuUp6WPc CpV+ZQhdoSc=

4. Zone signieren

Wie eingangs erwähnt, wird man im praktischen Betrieb Zonen nicht per Hand auf der Kommandozeile signieren. Zum einmaligen Signieren per Hand verwenden wir in diesem Tutorial aber dnssec-signzone.

dnssec-signzone -S -o ws01.ws.dnssec.bayern /etc/bind/ws01.dnssec.bayern.zone

-S                                                        

aktiviert "smart signing", d.h. es wird im in /etc/bind/named.conf angegebenen key directory nach Schlüsseln gesucht, die zum Signieren verwendet werden

-o ws01.ws.dnssec.bayern.zone

gibt die Zone mit dem Namen "ws01.ws.dnssec.bayern" als origin an, nach der in der Datei...

/etc/bind/ws01.dnssec.bayern.zone    

gesucht wird.

Fetching KSK 34939/RSASHA256 from key repository.

Fetching ZSK 45750/RSASHA256 from key repository.

Verifying the zone using the following algorithms: RSASHA256.

Zone fully signed:

Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked

                      ZSKs: 1 active, 0 stand-by, 0 revoked

Die Zone wurde also mit einem KSK und einem ZSK signiert. D.h. die RRSets wurden mit dem ZSK signiert und der KSK signiert den ZSK (und sich selbst). dnssec-signzone schreibt die signierte Zone in eine neue Datei <zonenfilename>.signed, also in unserem Fall

/etc/bind/ws01.ws.dnssec.bayern.zone.signed

Diese signierte Zonen-Datei ist mit den enthaltenen Signaturen über alle RRSets erheblich größer

ls -lthr /etc/bind/ws01.ws.dnssec.bayern.zone*

-rw-r--r-- 1 root root  334 Jan 27 16:47 /etc/bind/ws01.ws.dnssec.bayern.zone
-rw-r--r-- 1 root root 6.0K Jan 27 16:49 /etc/bind/ws01.ws.dnssec.bayern.zone.signed

Sie ist aber noch eine plain-text ASCII-Datei und kann auch inspiziert werden:

vim /etc/bind/ws01.ws.dnssec.bayern.zone.signed

; File written on Fri Jan 27 16:49:18 2017
; dnssec_signzone version 9.9.5-9+deb8u9-Debian
ws01.ws.dnssec.bayern.  300     IN SOA  dnssec-ws01.dnssec.bayern. root.dnssec-ws01.dnssec.bayern. (
                                        1          ; serial
                                        14400      ; refresh (4 hours)
                                        3600       ; retry (1 hour)
                                        1209600    ; expire (2 weeks)
                                        300        ; minimum (5 minutes)
                                        )
                        300     RRSIG   SOA 8 4 300 (
                                        20170226144918 20170127144918 45750 ws01.ws.dnssec.bayern.
                                        Um/qyvnbcrKWsragXJdoPnJrYgXpRhmjYVJK
                                        NM93z3pIRzXHTKMZhVIwjwmyoXNb7z7p87uz
                                        ngjPTPnYxYUcBPgyJNfR5aa0zXDr3CRT2apI
                                        lU00yYj6FXRs4LULEzOhvQth5oPpeM6/GFHO
                                        tZfaqaxVn0DQHxvbE5rqvfNiEHiegA4hDr15
                                        wQh1bn+IQkuEaR/3sLHX5SOd6HaZSx/CpevN
                                        629gkInUFulErVhILnhYNfyO6GCxXHHgaDZp
                                        Xj+dfVjfJcDTmtWtjr1d2y5PMeK3E4l4Vmjo
                                        2UU5/RLTkL58mlZed0pWYvSgqVUcHzToMOby
                                        w2xzDdRLu0XMWGdIbg== )
                        300     NS      dnssec-ws01.dnssec.bayern.
                        300     RRSIG   NS 8 4 300 (
                                        20170226144918 20170127144918 45750 ws01.ws.dnssec.bayern.
                                        c/s9VpiH57A5D0RVGCxFrALEYSo8A95rLe9f
                                        JKFKelPYjrX3BFXyTqf2G2Gfhqrg5T/u1dBX
                                        3+jxds9xT8cfnqnpNOjGFypc2fPkAUNFGCri
                                        inyQSiwRsyeT9dkNnEs9lqTjaLmJB2fjVnfX
                                        cMdp53FN0GUED8vgVk0Kn1bBnzulkwH0yh8+
                                        BjRkWD8pWZr+xZvbEqtkYGWKxrFbcj/vExdJ
                                        tTjxDIAUxwslBIEqGoiSvYm5ZNHVSPPTK4Hk
                                        NUgIRf7StSYEOhIyD78t+gF7Gx69mq7OoT7A
                                        kjoiSMuH8HLjMBbXdbOyH3Lbtdrkeq23k7Lv
                                        ES8NdF53kRRi/7Utrw== )
........

Zur Überprüfung der Validität der signierten Zonen-Datei verwendet man aber am besten Tools.

5. DS Resource Record im Parent veröffentlichen

Wenn die Zone online geht, muss noch der DS RR im Parent eingetragen werden. Dank "smart signing" hat dnssec-signzone für uns diesen schon für den verwendeten KSK erstellt.

ls -lthr

-rw-rw-r--+ 1 root root  185 Jan 27 16:49 dsset-ws01.ws.dnssec.bayern.

Diese Datei enthält die DNS-konformen DS Einträge, die in der Parentzone eingetragen werden müssen, damit die Delegation an unseren autoritativen Nameserver anhand der dort eingetragenen KSK keyids authentiziert werden kann.

cat dsset-ws01.ws.dnssec.bayern.

ws01.ws.dnssec.bayern.    IN DS 34939 8 1 D38D1AD349474785C7CEA195B01006520105B80A
ws01.ws.dnssec.bayern.    IN DS 34939 8 2 BEB40DC948274BD637720B77694564B6C785283F1F89C3FF901466A3 B1BB5D25

Das zwei Einträge, einer für RSASHA1 und RSASHA2, die an die Parentzone übergeben werden müssen. Im Falle des LRZ-Nameservers der Zone ws.dnssec.bayern genügt RSASHA2 (also die zweite Zeile), da RSASHA1 nicht verwendet wird.

Da man aber eventuell nicht weiß, welchen Algorithmus der Nameserver der Parentzone verwendet, ist es besser beide zu übergeben!

In der Praxis kann dies auf verschiedene "out-of-band"-Arten geschehen (z.B. Email an den Administrator der Parentzone, Eintrag in einem Webformular). In diesem Tutorial ist der autoritative Nameserver dazu berechtigt per nsupdate dynamische updates in ws.dnssec.bayern vorzunehmen.

nsupdate

> server 10.156.8.23
> zone ws.dnssec.bayern
> update add ws01.ws.dnssec.bayern. 300 IN DS 34939 8 1 D38D1AD349474785C7CEA195B01006520105B80A
> update add ws01.ws.dnssec.bayern. 300 IN DS 34939 8 2 BEB40DC948274BD637720B77694564B6C785283F1F89C3FF901466A3 B1BB5D25
> send
> quit

server 10.156.8.23

stellt die Verbindung mit dem LRZ-Nameserver her, auf dem die Zone ws.dnssec.bayern verwaltet wird.

zone ws.dnssec.bayern

lässt uns die Zone ws.dnssec.bayern bearbeiten

update add ws01.ws.dnssec.bayern. 300 IN DS 34939 8 1 D38D1AD349474785C7CEA195B01006520105B80A
fügt den Eintrag ws.01.ws.dnssec.bayern

mit einer TTL von 300 Sekunden (300)

als Delegation Resource Record ("IN DS")

mit der Angabe der keyid (34939) unseres KSK

Algorithmus RSASHA (8)

RSASHA1 1

und der Signatur hinzu

Dasselbe geschieht in der zweiten Zeile für den RSASHA256 Algorithmus (2) mit der entsprechend längeren Signatur.

send

schreibt es in die Zone (da kein Fehler zurück gegeben wird, hat das geklappt).

quit

beendet nsupdate.

6. Zone veröffentlichen

Während es bis zu einer TTL, also im Falle des LRZ-Nameservers 300 Sekunden, dauert, bis die neuen DS-Einträge gültig sind, haben wir einen Moment Zeit, die Zone zu veröffentlichen.

Dazu editieren wir /etc/bind/named.conf und tragen für die Zone ws01.ws.dnssec.bayern die signierte Zonen-Datei ein:

vim /etc/bind/named.conf

zone ws01.ws.dnssec.bayern {
        type master;
        file "/etc/bind/ws01.ws.dnssec.bayern.zone.signed";
};

Dann starten wir BIND neu (es würde aber auch ein rndc reload reichen, sofern rndc-Zugriff eingerichtet ist).

/etc/init.d/bind9 restart

Mittels dig können wir nun überprüfen, ob wir eine DNSSEC-signierte authentische Antwort erhalten:

dig ws01.ws.dnssec.bayern. +dnssec

; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> ws01.ws.dnssec.bayern. +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23641
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ws01.ws.dnssec.bayern.        IN    A

;; AUTHORITY SECTION:
ws01.ws.dnssec.bayern.    184    IN    SOA    dnssec-ws01.dnssec.bayern. root.dnssec-ws01.dnssec.bayern. 1 14400 3600 1209600 300
ws01.ws.dnssec.bayern.    184    IN    RRSIG    SOA 8 4 300 20170226144918 20170127144918 45750 ws01.ws.dnssec.bayern. Um/qyvnbcrKWsragXJdoPnJrYgXpRhmjYVJKNM93z3pIRzXHTKMZhVIw jwmyoXNb7z7p87uzngjPTPnYxYUcBPgyJNfR5aa0zXDr3CRT2apIlU00 yYj6FXRs4LULEzOhvQth5oPpeM6/GFHOtZfaqaxVn0DQHxvbE5rqvfNi EHiegA4hDr15wQh1bn+IQkuEaR/3sLHX5SOd6HaZSx/CpevN629gkInU FulErVhILnhYNfyO6GCxXHHgaDZpXj+dfVjfJcDTmtWtjr1d2y5PMeK3 E4l4Vmjo2UU5/RLTkL58mlZed0pWYvSgqVUcHzToMObyw2xzDdRLu0XM WGdIbg==
ws01.ws.dnssec.bayern.    184    IN    RRSIG    NSEC 8 4 300 20170226144918 20170127144918 45750 ws01.ws.dnssec.bayern. A6J9HF8BXgruGFMu1VYFv3neP3A4HPgqMz+QJuyAegUhU4TQ1wHB/zlX lEan7qaJqwwO9qplf4wNwL1cAwf4SUWS77n12pNJmKJx6gSBSt35des4 RTrm+2Uxf27Gtv4OzZiao+NKixGhEyxbwZPo8bupNOvuoTbGOE2/DoFN nyYoXJ3hBwkMsFxmDUiHmFCBkp/g5LkBWn8vPbdV9KCvez2LDgFALs7n Esquej+5ItaMqzwglmKRKDO5xQnBJtuGer2q8vQZnB1M3JXYLq2AK+FS YrjWaGw2fVrkl+Zcbumwr0wigM0fUAC/hZxdI/7tJbZKnkOery88XL7u G0scLg==
ws01.ws.dnssec.bayern.    184    IN    NSEC    dnssec-ws01.ws01.ws.dnssec.bayern. NS SOA MX RRSIG NSEC DNSKEY

;; Query time: 4 msec
;; SERVER: 10.156.33.53#53(10.156.33.53)
;; WHEN: Fri Jan 27 17:38:24 CET 2017
;; MSG SIZE  rcvd: 777

Das ad-Flag ist gesetzt! Der LRZ-Nameserver liefert also eine DNSSEC-authentizierte Antwort zurück.

DNSViz

Schöner lässt sich das mit DNSViz.net überprüfen.

Da default für die erstellten DNSKEYs keine deactivation Daten gesetzt werden, bleibt die Zone gültig signiert. In der Praxis sollte man aber ZSKs und KSKs von Zeit zu Zeit erneuern (mehr dazu in Keyrollovers "best practices").