DNSSEC message checking

January 21, 2012

dns

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.

None