When using dig to debug DNS/DNSSEC errors, you (I have the need, I'm assuming you
have it too) often want to know:
- Are the signatures in the message correct?
- Does the NSEC3 authenticated denial of existence proof look OK? (this is a work-in-progress)
With dig this is next to impossible, because we humans can not validate RSA signatures,
nor hash names for NSEC3 validation.
This is why I added a little feature to q, the query-tool found in godns.
The tool looks very much like dig or drill (from ldns).
Normal query
Querying for the MX records of miek.nl, works (and looks) just like using dig:
% q @open.nlnetlabs.nl mx miek.nl
;; opcode: QUERY, status: NOERROR, id: 41714
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;miek.nl. IN MX
;; ANSWER SECTION:
miek.nl. 345600 IN MX 20 mail.atoom.net.
miek.nl. 345600 IN MX 40 mx-ext.tjeb.nl.
;; AUTHORITY SECTION:
miek.nl. 345600 IN NS ext.ns.whyscream.net.
miek.nl. 345600 IN NS open.nlnetlabs.nl.
miek.nl. 345600 IN NS omval.tednet.nl.
miek.nl. 345600 IN NS elektron.atoom.net.
DNSSEC query
With the -dnssec option you request DNSSEC records and the
-short option shortens long signatures and other records deemed too long.
% q -dnssec -short @open.nlnetlabs.nl mx miek.nl
;; opcode: QUERY, status: NOERROR, id: 54058
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 1
;; QUESTION SECTION:
;miek.nl. IN MX
;; ANSWER SECTION:
miek.nl. 345600 IN MX 20 mail.atoom.net.
miek.nl. 345600 IN MX 40 mx-ext.tjeb.nl.
miek.nl. 345600 IN RRSIG MX 8 2 345600 19700101000000 19700101000000 12051 miek.nl. ...
;; AUTHORITY SECTION:
miek.nl. 345600 IN NS ext.ns.whyscream.net.
miek.nl. 345600 IN NS open.nlnetlabs.nl.
miek.nl. 345600 IN NS omval.tednet.nl.
miek.nl. 345600 IN NS elektron.atoom.net.
miek.nl. 345600 IN RRSIG NS 8 2 345600 19700101000000 19700101000000 12051 miek.nl. ...
;; ADDITIONAL SECTION:
;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: do; udp: 4096
But now the question remains, are those signatures valid? With the -check option you instruct q to go fetch the
DNSKEYs (from the same server + port) and validate the signatures and RRSet with that key. The output you then get,
looks like this:
% q -check -dnssec -short @open.nlnetlabs.nl mx miek.nl
;+ Secure signature, miek.nl. RRSIG(MX) validates RRSet with DNSKEY miek.nl./12051
;+ Secure signature, miek.nl. RRSIG(NS) validates RRSet with DNSKEY miek.nl./12051
;; opcode: QUERY, status: NOERROR, id: 53642
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 1
;; QUESTION SECTION:
;miek.nl. IN MX
;; ANSWER SECTION:
miek.nl. 345600 IN MX 20 mail.atoom.net.
miek.nl. 345600 IN MX 40 mx-ext.tjeb.nl.
miek.nl. 345600 IN RRSIG MX 8 2 345600 19700101000000 19700101000000 12051 miek.nl. ...
;; AUTHORITY SECTION:
miek.nl. 345600 IN NS ext.ns.whyscream.net.
miek.nl. 345600 IN NS open.nlnetlabs.nl.
miek.nl. 345600 IN NS omval.tednet.nl.
miek.nl. 345600 IN NS elektron.atoom.net.
miek.nl. 345600 IN RRSIG NS 8 2 345600 19700101000000 19700101000000 12051 miek.nl. ...
;; ADDITIONAL SECTION:
;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: do; udp: 4096
I think this is considered a #win.
2 comments
% ./q -check -dnssec miek2.nl @ns1.nic.nl
;+ Secure signature, nl. RRSIG(SOA) validates RRSet with DNSKEY nl./48855
;+ Secure signature, 9tm2flpfkak9i60k1jq8jmtmhg4ogq7u.nl. RRSIG(NSEC3) validates RRSet with DNSKEY nl./48855
;+ Secure signature, 2sni0boual7uh2afn1am5fkhf7u6qmg4.nl. RRSIG(NSEC3) validates RRSet with DNSKEY nl./48855
;+ Secure signature, qiv9ald2jqodv0dbhs4j7s1rod1g8ebv.nl. RRSIG(NSEC3) validates RRSet with DNSKEY nl./48855
;+ Correct authenticated denial of existence (NSEC3)
;; opcode: QUERY, status: NXDOMAIN, id: 15506
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
...
...
