Random DNSSEC / DANE / TLSA resources and infos

Having recently thrown the switch on DNSSEC and DANE/TLSA for a couple of domains, here are some random infos.

DNSSEC

The setup of DNSSEC with Bind9 (Debian package bind9) is pretty well covered in various HowTos, so I won't repeat them here. One rather official one is at https://dlv.isc.org/about/using ("ISC does BIND" may sound like a movie title to you, but it's not).

Generating the needed keys might be a bit cumbersome, so I'd suggest using the DNSSEC-Tools from http://www.dnssec-tools.org/ (Debian package dnssec-tools) and their command zonesigner1. donutsd and rollerd are also nice helper apps to keep things working after initial setup2.

ISC's DLV (DNSSEC Look-aside Validation Registry) is also a good place to go if your ISP or domain registrar doesn't allow to add the necessary records to the TLD of your domain.

If your TLD even supports DNSSEC can be seen at http://stats.research.icann.org/dns/tld_report/

Once you've configured everything it's time to test your DNSSEC-enabled domain, a good and very visual validator is at http://dnsviz.net/ (the only one who checks DLV as well), another one is at http://dnssec-debugger.verisignlabs.com/

Of course, you can also check for yourself using dig (package dnsutils on Debian) or unbound's drill (package ldnsutils). For this you'll have to fetch the root TLD DNSSEC keys first as a trust anchor. Unfortunately the 2 tools use different defaults locations: dig uses /etc/trusted-key.key (or searches for the file in the current directory), drill searches for /etc/unbound/root.key. Either way, to fetch them, use

dig +dnssec +nocomments +nostats +nocmd +noquestion -t dnskey . > trusted-key.key
# for DLV use (even tho I still couldn't validate a DLV-only domain)
dig +dnssec +nocomments +nostats +nocmd +noquestion -t dnskey dlv.isc.org >> trusted-key.key

The +dnssec won't of course do any good unless your resolving nameservers (in /etc/resolv.conf) are already DNSSEC-enabled, but it won't hurt either.

Afterwards, assuming you have placed the trusted keys so that dig/drill can find them, you can use

dig +topdown +sigchase +multiline -ta <yourdomain>

or

drill -V 5 -s -S <yourdomain>

for really verbose validation of the whole chain of certificates from the root TLD down to your DNS zone. BTW, even ISC suggests using drill (see https://lists.isc.org/pipermail/bind-users/2012-May/087779.html and the follow up), and even current dig on Debian sid shows the "We are in a Grand Father Problem: See 2.2.1 in RFC 3568" error when validating TLDs.

Browser extension to check both DNSSEC and TLSA: https://www.dnssec-validator.cz/

DANE/TLSA

First off, the TLSA resource record (RR) types are rather new, so if your tools (host, dig, bind) don't work with it, use the alternative TYPE52 RR type.

Creating the necessary hash from a certificate is easy. There are various RR type decisions to make when creating the TLSA record, depending on how the trust should be established, if public key or whole certificate is verified  against the TLSA record and if the TLSA has the full certificate/public key present or just a hash (see the full spec at http://tools.ietf.org/html/rfc6698#section-2 and reading section 1 is probably a good idea as well).

So, I chose to use "3 0 1" for these type fields, and to create the needed sha256 hash3 I used

openssl x509 -in <path-to-certificate> -outform der | sha256sum

You can also leave the hard work to Shumon Huque's https://www.huque.com/bin/gen_tlsa generator. Also, be sure to take a look at his domain stats at http://www.huque.com/app/dnsstat/ and other offerings.

Once you've published that newly created TLSA record inside your DNSSEC-signed zone you can validate your setup, either

Browser extension to check both DNSSEC and TLSA: https://www.dnssec-validator.cz/

Various

1 On Debian wheezy, the package dnssec-tools is somewhat broken, it munges your SOA entry regarding the nameserver if it contains a digit while updating the zone serial, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702956 and the upstream https://www.dnssec-tools.org/trac/ticket/152 bug reports. I used the version in Debian sid on wheezy without a problem. And this will be needed on jessie too, because the package has been removed from testing a while ago, because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754704 and the upstream bug https://www.dnssec-tools.org/trac/ticket/185 (both of which don't seem to be taken care of, oh well).

2 donuts/donutsd from DNSSEC-Tools seems to have problems with TLSA RRs, or rather the libnet-dns-perl package on wheezy has, reporting the following error:

Net::DNS::typesbyname() argument (TLSA) is not TYPE### at /usr/lib/perl5/Net/DNS.pm line 206

It only got added to Net::DNS in 0.69 (wheezy is at 0.66), but it's an easy enough change, so I just added the needed RR type 52, here's the diff: (note: you'll have to re-apply if the Debian package gets updated, or use dpkg-divert)

--- /usr/lib/perl5/Net/DNS.pm.orig      2015-01-27 11:13:38.198400626 +0100
+++ /usr/lib/perl5/Net/DNS.pm   2015-01-27 11:14:16.601877626 +0100
@@ -160,6 +160,7 @@ use Carp;
     'DHCID'     => 49,      # RFC4701
     'NSEC3'     => 50,      # RFC5155
     'NSEC3PARAM' => 51,     # RFC5155
+    'TLSA'      => 52,      # RFC6698
 # 52-54 are unassigned
     'HIP'       => 55,      # RFC5205
     'NINFO'     => 56,      # non-standard                                     NOT IMPLEMENTED

3 Replace with sha512sum for a sha512 hashing. Both tools are part of coreutils, so no need to rely on openssl being recent enough to expose the needed subcommands. Besides you can't even check in openssl's manpage for "dgst" beforehand because it's outdated even on recent versions.

Recent articles about DNSSEC and DANE

These 2 blog posts are not exactly arguing pro-adoption:

http://sockpuppet.org/blog/2015/01/15/against-dnssec/

https://www.imperialviolet.org/2015/01/17/notdane.html