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.