Dive into delv: DNSSEC Validation

If you’re into DNSSEC, you’ll probably have to troubleshoot or at least to verify it. While there are some good online tools such as DNSViz, there is also a command-line tool to test DNSSEC signatures onsite: delv.

delv will send to a specified name server all queries needed to fetch and validate the requested data; this includes the original requested query, subsequent queries to follow CNAME or DNAME chains, and queries for DNSKEY, DS and DLV records to establish a chain of trust for DNSSEC validation. It does not perform iterative resolution, but simulates the behavior of a name server configured for DNSSEC validating and forwarding.

Citing the manpage again:

By default, responses are validated using built-in DNSSEC trust anchor for the root zone (“.”). Records returned by delv are either fully validated or were not signed. If validation fails, an explanation of the failure is included in the output; the validation process can be traced in detail. Because delv does not rely on an external server to carry out validation, it can be used to check the validity of DNS responses in environments where local name servers may not be trustworthy.
This blogpost is part of a series about DNSSEC. Refer to this list for all articles.

Without any options, delv outputs the A record and the corresponding RRSIG (if present), while it fully validates the DNSSEC signature. A simple call looks like this, while for IPv6 addresses you have to specify the type with AAAA. Note the “fully validated” line since the following hostnames are DNSSEC signed:

For hostnames that aren’t signed, delv outputs this “unsigned answer”:

Traces

Now, this is what delv is about: a couple of trace options:

Note: Unlike dig, which does iterative DNS queries when using the +trace option, delv always uses the given recursive DNS server for each of its queries.

+rtrace

Just to list all queried RRs; no further DNSSEC details:

+mtrace

Caution: Same as rtrace but with the full content of all RRs:

+vtrace

Here we go: Tracing the validation process with many additional notes on how this process occurs. A DNSSEC signed hostname looks like this:

An unsigned hostname like this:

And finally, a failure in DNSSEC:

Uh. What has happened? My recursive DNS server *does* DNSSEC validation as well, hence delve is unable to query it for falsified records. Unluckily, you can’t set the cd bit (checking disabled) for delv requests. (Why?!? This would be that useful for troubleshooting!)

Hence we must use a non-validating recursive DNS server to test with, like the second one from Quad9: 2620:fe::10 respectively 9.9.9.10.

Depending on the failure, delv gives you appropriate notes, such as “insecurity proof failed” [corresponding DNSViz breakdown]:

or “RRSIG has expired” [corresponding DNSViz breakdown]:

or “RRSIG failed to verify” [corresponding DNSViz breakdown]:

Thanks to Carsten Strotmann for his great DNSSEC test hostnames at dnssec.works!

Happy DNSSECing. ;) And merry Christmas. Christ is born <- that’s what Christmas is all about!

Leave a Reply

Your email address will not be published. Required fields are marked *