Debuggen von DNSSEC

Bei der Konfiguration einer durch DNSSEC authentifizierten Zone auf einem autoritativen Server gibt es einige Fallstricke. Daher ist es wichtig, bei Debuggen systematisch vorzugehen. Der Fehler muss aber nicht immer notwendigerweise an DNSSEC liegen, daher betrachten wir auch einige herkömmliche BIND-Fehler.


Debugging Workflow

Wenn man seine Zone auf dem Nameserver debuggen will, sollte man von der grundlegenden Konfiguration (BIND selbst), der unsignierten Zone hin zu den DNSSEC-spezifischen Einstellungen gehen. Das ist in dem folgenden Ablauf dargestellt:


Am Ende, wenn man alle Debugging-Schritte durchgeführt hat, und die aufgetretenen Fehler behoben wurden, sollte man mit DNSViz eine korrekte mit DNSSEC-signierte Zone präsentiert bekommen.


Debugging Tools im Detail

Die im obigen Ablaufdiagramm verwendeten Kommandozeilentools schauen wir uns mit Beispielausgaben im Detail an. Der Fehler muss nicht unbedingt an DNSSEC liegen, daher ist es auch wichtig, die unsignierten Zonen und die BIND-Konfiguration selbst zu überprüfen.

named-checkconf

named-checkconf liest die Konfigurationsdatei von BIND und überprüft sie auf Syntaxfehler. Wird es ohne Argumente aufgerufen, wird die Datei named.conf im Verzeichnis /etc/bind/ gelesen.


named-checkconf [-t directory] {filename}

Die man-Seite zu named-checkconf listet optionale Parameter, um ein anderes Verzeichnis, in dem gesucht wird, oder einen anderen Namen der Konfigurationsdatei anzugeben.

named-checkonf liefert keine Ausgabe zurück, wenn keine Fehler gefunden wurden.


Beispiel: Syntaxfehler in "allow-transfer", fehlender Strichpunkt bei IPs

named-checkconf

/etc/bind/named.conf:14: unknown option 'allow-transfe'

/etc/bind/named.conf:39: missing ';' before '127.0.0.1'

named-checkzone

named-checkzone prüft die Zonendatei auf syntaktische Fehler. Dazu muss der Zonename als Origin und die Datei mit den Einträgen der zu prüfenden Zone angegeben werden.

named-checkzone <zone> <zonefile>


Beispiel: RR-Typ "AAA" statt "AAAA"

named-checkzone ws04.ws.dnssec.bayern /etc/bind/ws04.ws.dnssec.bayern.zone
/etc/bind/ws04.ws.dnssec.bayern.zone:19: unknown RR type 'AAA'
zone ws04.ws.dnssec.bayern/IN: loading from master file /etc/bind/ws04.ws.dnssec.bayern.zone failed: unknown class/type
zone ws04.ws.dnssec.bayern/IN: not loaded due to errors.

ldns-verify-zone

ldns-verify-zone <zonefile> prüft die DNSSEC-signierte Zone auf DNSSEC-spezifische Fehler. Wenn die Zone korrekt signiert ist, liefert der Aufruf mit der Zonendatei als Parameter "Zone is verified and complete" zurück.

Sollten Fehler gefunden werden, werden diese aufgelistet und das Ergebnis "There were errors in the zone" ausgegeben.


Beispiel: ZSK aus der signierten Zone gelöscht

ldns-verify-zone /etc/bind/ws04.ws.dnssec.bayern.zone.signed

Error: No keys with the keytag and algorithm from the RRSIG found for ws04.ws.dnssec.bayern.    NS
Error: No keys with the keytag and algorithm from the RRSIG found for ws04.ws.dnssec.bayern.    SOA
Error: Bogus DNSSEC signature for ws04.ws.dnssec.bayern.    DNSKEY
Error: No keys with the keytag and algorithm from the RRSIG found for ws04.ws.dnssec.bayern.    DNSKEY
Error: No keys with the keytag and algorithm from the RRSIG found for ws04.ws.dnssec.bayern.    NSEC
Error: No keys with the keytag and algorithm from the RRSIG found for ws04.ws.dnssec.bayern.ws04.ws.dnssec.bayern.    MX
Error: No keys with the keytag and algorithm from the RRSIG found for ws04.ws.dnssec.bayern.ws04.ws.dnssec.bayern.    NSEC
Error: No keys with the keytag and algorithm from the RRSIG found for dnssec-ws04.ws04.ws.dnssec.bayern.    A
Error: No keys with the keytag and algorithm from the RRSIG found for dnssec-ws04.ws04.ws.dnssec.bayern.    AAAA
Error: No keys with the keytag and algorithm from the RRSIG found for dnssec-ws04.ws04.ws.dnssec.bayern.    NSEC
Error: No keys with the keytag and algorithm from the RRSIG found for _25._tcp.dnssec-ws04.ws04.ws.dnssec.bayern.    TLSA
Error: No keys with the keytag and algorithm from the RRSIG found for _25._tcp.dnssec-ws04.ws04.ws.dnssec.bayern.    NSEC
There were errors in the zone


Alternativ kann auch das BIND-eigene dnssec-verify verwendet werden, dem aber der Zonenname als "origin mitgegeben werden muss - sofern der Filename nicht dem Zonennamen entspricht.

dnssec-verify -o <ZONENNAME> <ZONENDATEI>


Beispiel: dnssec-verify -o ws04.ws.dnssec.bayern /etc/bind/ws04.ws.dnssec.bayern.zone.signed

Loading zone 'ws04.ws.dnssec.bayern' from file '/etc/bind/ws04.ws.dnssec.bayern.zone.signed'
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


Beispiel: NSEC-RR manuell gelöscht

dnssec-verify -o ws04.ws.dnssec.bayern /etc/bind/ws04.ws.dnssec.bayern.zone.signed

Loading zone 'ws04.ws.dnssec.bayern' from file '/etc/bind/ws04.ws.dnssec.bayern.zone.signed'
dnssec-verify: fatal: No valid NSEC/NSEC3 chain for testing


Zonentransfer vom autoritativen Nameserver / SOA

Dann kann man testen, welche Zone ausgeliefert wird, wenn man über einen Zonentransfer (axfr) die Zone auf dem autoritativen Nameserver erfrägt. Die zurück gelieferte Zone sollte Signaturen (RRSig) für alle ResourceRecordSets (RRSet) haben. Dies erforderte aber, dass der anfragende Resolver zu einem Zonentransfer berechtigt ist (allow-transfer in /etc/bind/named.conf)


dig axfr ws04.ws.dnssec.bayern @::1

; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> axfr ws04.ws.dnssec.bayern @::1
;; global options: +cmd
ws04.ws.dnssec.bayern.    300    IN    SOA    dnssec-ws04.dnssec.bayern. root.dnssec-ws04.dnssec.bayern. 9 14400 3600 1209600 300
ws04.ws.dnssec.bayern.    300    IN    RRSIG    SOA 8 4 300 20170421171032 20170322171032 59895 ws04.ws.dnssec.bayern. aigHkvwB8ezKeJiveXfqoDYHJFwaLkgSIrtFrXYxiBr57E81fJGMD9jw cQJHje+FpIs9bv6HDO5LMvlruaJCwOvFgxyFW57hrf0oAHk2KU42pbga 0l8zZRQG6iawiic+COA3gC2Mhr5XmE4rL5HGoOyS6IrvdpfRFx7Ti7D1 /zHUZCrSS50JXCQdP2Dg8PqZLURHxM30N7Uv1YZLA+BiaqzV2+XsI+JA sq4rn4xMhOUtxdFbNs/ZtWGaFwl51MWX1wyUHjV5XQNAPDT0xTpzLsXC 3cpNZ6XGLPBe6fqU8QXM+ZVeuwULfYTFWxpvs/roYnZ13/Zp4TRJWIdu C2pt/w==
ws04.ws.dnssec.bayern.    300    IN    NS    dnssec-ws04.dnssec.bayern.
ws04.ws.dnssec.bayern.    300    IN    RRSIG    NS 8 4 300 20170421171032 20170322171032 59895 ws04.ws.dnssec.bayern. Pdr5Hiw+tJgAxZHh10uoNmQeCyw5xBqEN5YfNWke48FEwBmii32W97PK YXad8u0fCC4UkUEguPBsCp2djmAPP30wGZr7z0gzhYDnkCpIKdOXYrUk J1nZUONNelqI0lnHKav9xiKtEqM+zk+gScjBJLtL20iLOXOBUbe6LBYy E1QmaNh6MVdIYtZt1OKIc0TnLdf81LFBb35rtHstVRhJNIosKX37uVnx GMtUi4uiy/pU3eq1NTaK3uk8z5Aq2JEjUgbq87E5MDoCeXFItP8tPJmH 7CZ3TC+V22fPgAdykeeXSrx9KjbxwpIC4pi/UBwSz0kBdQJWum5OkEbz EdDlRA==
ws04.ws.dnssec.bayern.    300    IN    A    138.246.99.209
ws04.ws.dnssec.bayern.    300    IN    RRSIG    A 8 4 300 20170421171032 20170322171032 59895 ws04.ws.dnssec.bayern. LQlzLfYiyXV+pZzjdaOygZv1DI0Jl+qGLjzoSil2fORe+3Ry9xrCJful ZQEPVQX1+TZVzZzyHyJvuEuc2837/vDUq747qXFhQoMk9wP7N3EsPEK/ UoBgrK/vUASv6TGn4La0trnJE5NEAnGEf7GngZN/tZ9j81ZjOu4+3DAl cOOiseGVeq2tskh+qQpEJmGmMLEEZh6bseHLdQThAdsmzc7pXxFAnDlW 2GN9SoldjzlBIryWaIyUfy+eiaW/uPw9/E7pf9NIrAMLUjtwfxwiE618 q7GEyfh0kMP1DP798zViA10+nUWOLVU9GOXl//6hS8bL5gBZUbj2fFR+ CtkHFQ==
ws04.ws.dnssec.bayern.    300    IN    AAAA    2001:4ca0:800:2:250:56ff:fe8f:64d2
ws04.ws.dnssec.bayern.    300    IN    RRSIG    AAAA 8 4 300 20170421171032 20170322171032 59895 ws04.ws.dnssec.bayern. hwln0sYIkGv2ontVZmMuXS10pI42m55TKG/N89eiEAH/XmmkJvGIgyPn dSDET5tEOxJoN33oRX2cPjqtzo/KlQTYYGS7xD5TiosDJUckhhXKTeuX BReCKIOsUECaTKnVhx9L9pn8jlUU4nnt7Giq74UadWrbRz3hXC68fIx1 RKVKb5LPZyvFU8KpSvHOrxL20DtT1SlF4h6cl7vhlIH6vcYbRgcYrdlg Hb44iuUKFP9CoBrjiSBfbUwY5xfq7EwRIdJl3HbQA216javSVv707kbe h2zOzfIZXJdw8jMKyzdtO19TuwMoSpsju9iBOEVQn1L2YjufEbP8y1fL 6iK6gQ==
ws04.ws.dnssec.bayern.    300    IN    NSEC    ws04.ws.dnssec.bayern.ws04.ws.dnssec.bayern. A NS SOA AAAA RRSIG NSEC DNSKEY

[...]


Dies erforderte aber, dass der anfragende Resolver zu einem Zonentransfer berechtigt ist (allow-transfer { localhost; ::1; } etc. in /etc/bind/named.conf).


SOA ResourceRecord mit OARC-Nameserver

Ist ein Zonentransfer nicht erlaubt, kann man auch testweise den SOA-ResourceRecord zurückgeben lassen.

dig SOA ws04.ws.dnssec.bayern

; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> SOA ws04.ws.dnssec.bayern
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50349
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ws04.ws.dnssec.bayern.        IN    SOA

;; ANSWER SECTION:
ws04.ws.dnssec.bayern.    201    IN    SOA    dnssec-ws04.dnssec.bayern. root.dnssec-ws04.dnssec.bayern. 9 14400 3600 1209600 300

;; AUTHORITY SECTION:
ws04.ws.dnssec.bayern.    265    IN    NS    dnssec-ws04.dnssec.bayern.

;; ADDITIONAL SECTION:
dnssec-ws04.dnssec.bayern. 300    IN    A    138.246.99.209
dnssec-ws04.dnssec.bayern. 3600    IN    AAAA    2001:4ca0:800:2:250:56ff:fe8f:64d2

;; Query time: 4 msec
;; SERVER: 10.156.33.53#53(10.156.33.53)
;; WHEN: Mon Mar 27 16:28:31 CEST 2017
;; MSG SIZE  rcvd: 161


AD flag

Das AD flag (authenticated data) wird nur bei der Abfrage eines Nameservers gesetzt, der nicht für die Zone autoritativ ist. Das AA (authoritative answer) und AD schließen sich gegenseitig aus.

dig SOA ws04.ws.dnssec.bayern @::1

; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> SOA ws04.ws.dnssec.bayern @::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52360
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1



Um eine "externe Sicht" auf die eigene Zone zu erhalten, kann man die OARC-Resolver abfragen unter 184.105.193.73 und 184.105.193.74.
dig SOA ws04.ws.dnssec.bayern @184.105.193.73 +dnssec

Dies sollte den SOA mit den Signaturen zurück liefern, mit dem AD Flag. Ist das AD Flag nicht gesetzt, liegt ein DNSSEC-Fehler vor.


Delegated Signer

In der DNSSEC-Validierungskette muss auch die Delegation auf den autoritativen Nameserver korrekt sein. Dazu muss der RSA-2-Hash im DS auf die ID des aktuellen Key-Signing Key verweisen, und dessen public key hash eingetragen sein.

dig DS <zone> @<nameserver> liefert alle vorhandenen DS-Einträge des Parent, die auf die Zone <zone> verweisen, entscheidend ist der RSA-2 Hash.


Beispiel:

dig DS ws04.ws.dnssec.bayern +short

58429 8 2 B2EDD20FBAC7E1D32B67751218A3560613CF063B093483B77670BF5A 3BE4F9C4
58429 8 1 3ED230D434F3D954D023911ABB1A57BFB47C693B


Dies vergleicht man dann mit der Key ID des KSK in der signierten Zonendatei.

fgrep KSK /etc/bind/ws04.ws.dnssec.bayern.zone.signed

                    ) ; KSK; alg = RSASHA256; key id = 58429



DNSViz

Stimmt bisher alles mit der DNSSEC-Konfiguration, kann man sich von dnsviz eine graphische Ausgabe der Vertrauenskette, den Schlüsseln und den wichtigsten (SOA, Zonen-A/AAAA, NS, MX) damit signierten Einträgen ausgeben lassen.

dnsviz probe <zone> | dnsviz graph -Tpng > zone.png


Beispiel:

dnsviz probe -R A,AAAA,NS,MX ws04.ws.dnssec.bayern | dnsviz graph -Tpng > ws04.png

Analyzing ws04.ws.dnssec.bayern
Analyzing ws.dnssec.bayern
Analyzing dnssec.bayern
Analyzing bayern
Analyzing .

Im Graphen lassen sich dann Delegationsfehler, oder fehlende/verwaiste Schlüssel usw. finden. Eine korrekte signierte Zone ergibt folgendes Bild (wobei die übergeordneten Zonen abgeschnitten sind):


"Men and Mice" hat eine Seite mit einer ausführlichen Liste weiterer Kommandzeilentools zur Überprüfung von DNSSEC.