Main menu

You are here

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.

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

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.

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

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)

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.