# DNSSEC message checking


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](https://github.com/miekg/godns/tree/master/examples/q).
The tool looks very much like `dig` or `drill` (from [ldns](http://www.nlnetlabs.nl/projects/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.