Making real use of DNSSEC: DANE

By now we can safely say that DNSSEC as a standard is here to stay. It may not be pretty or completely practical, but it is possible to implement it relatively easily. DNSSEC provides a little bit more assurance on the integrity of the DNS query results. This extra assurance does enable some other interesting applications, to increase the integrity of other systems. This is done through the standard called DANE: DNS-based Authentication of Named Entities. In this post I’ll walk through a couple of examples.

**Update 23/7/2015:  **Added email TLSA record instructions

**Update 23/7/2015:  **Corrected email TLSA record instructions

TLSA records: HTTPS Certificates

The first application of DANE is in the new TLSA DNS record. This record provides information about the TLS certificate that is associated to a service at a hostname. Here is an example:

This record provides information on the service running on TCP port 443 on this host, i.e. the web service. In this case it is a service certificate (1), it must also validate the PKIX certification path, a value of 3 can be used for a self-signed certificate. The hash-value is calculated on the full certificate (0), and the type of hash is SHA-256 (1). The rest of the record is the actual hash-value. See also RFC 6698 and 7218.

The hash values can be calculated in two different ways, using the original certificate, or by connecting to the service and fetching the certificate that way.

So, this TLSA record, combined with the trust-structure in place for DNSSEC, gives you another, independent, trust-path to a certificate. It can be verified by using a browser-plugin: DNSSEC/TLSA Validator.

TLSA Records: Email TLS certificates

Of course, the same trick with HTTPS can be done for email as well. After all most email servers support TLS. The checking of certificates there is currently abysmal, TLSA seems a first way to actually do something about this.

Again these values can be generated using openssl, in a similar way as before, with a slight adaptation for smtp and starttls:

The resulting records are the following:

Then add the following to your Postfix server (I’m assuming you already have TLS running). The first line adds support for DNSSEC, the second makes your server use it opportunistically for outgoing connections, and the final one logs these attempts (look for “Verified TLS”):

For more info, see also the description by Go6lab.

**Correction: **SMTP clients don’t have a way of checking the certificate chain or presenting a user with a dialog whether to trust a certain certificate. Therefore, the use of 0 or 1 as first value is undefined. So you should use a value of 3 as first part of your TLSA record.

SSH Fingerprints: SSHFP records

An older application of a similar idea is in publishing SSH key fingerprints. This way users have a way to confirm these keys. It gives you a better idea of what is going on when you are presented with an unknown key:

These records are defined in RFC 4255, 6594 and 7479. They work a little differently from TLSA; they don’t give out the port of the SSH service:

The record in this case is just the hostname, and the value gives an indication of the algorithm used (4, Ed25519), and the hashing algorithm (1, SHA1 and 2, SHA-256). Like I mentioned above, OpenSSH supports the lookup of these fingerprints by either supplying the VerifyHostKeyDNS argument on the command-line, or by setting in your .ssh/config or even better /etc/ssh/ssh_config.

While this record helps, it still does not completely solve the situation in which you want to do a key change. When you replace the value, you are now presented with even bigger warning signs. But after local removal you at least get some assurance that the new key is probably the intended one.