Taking Advantage of DNSSEC

According to measurements by APNIC’s Geoff Huston currently 16 percent of Swiss Internet users use a DNSSEC validating DNS resolver. If you want to benefit from the added security with DNSSEC in your network then I suggest you enable DNSSEC validation in your network as well. SurfNet published a deployment guide recently that takes BIND 9.x, Unbound and Microsoft Windows Server 2012 into account.

Enabling DNSSEC validation on your DNS resolvers is one simple step and it protects you from DNS Cache Poisoning. However, if it were only for this, then the DNSSEC protocol complexity would come at a high cost for only providing this one benefit. In fact, DNSSEC is much more than only a protection from Cache Poisoning. It’s a new PKI in DNS and if you have signed your zone and are already validating then you can take advantage of that PKI. Some use cases are described below but there are many more ideas which are currently discussed.

SSHFP
A simple straightforward use case is to add SSH host fingerprints (SSHFP record, RFC 4255, RFC 6594) to your zone. The advantage is that you no longer need to rely on manual host authentication and secondly, if you change the SSH key of the host and update its SSHFP record nobody is being prompted with a SSH fingerprint warning.

Creating the SSHFP records with ‘ssh-keygen’:
ssh-keygen -r host.switch.ch
host.switch.ch IN SSHFP 1 1 e237e7293bdba76791bd26bc78ceee4d849a46eb
host.switch.ch IN SSHFP 1 2 10b3ac95b13d12b274e04d44edccfea079f98a1bb09dcd8df5a626879966fdc6
host.switch.ch IN SSHFP 2 1 a9e476c830bead9ae69e78e8bb075b5822bd1b17
host.switch.ch IN SSHFP 2 2 b051952173768aa3873ba97418a1bd9de2099523c5fd8ceaeb031edea5d3cf0c
host.switch.ch IN SSHFP 3 1 2dc55592c06c3e0690642832378f77421dbd275b
host.switch.ch IN SSHFP 3 2 baee9008caad669ba6def3f6cbf6320669a3e8cf269b4440e8091c1e71dfaddf

Next, you need to configure your SSH client to set VerifyHostKeyDNS=yes. You can add this to your local configuration (~/.ssh/config) or as a ssh command option with: ssh -o VerifyHostKeyDNS=yes host.switch.ch. The latter is also useful for debugging when you want to set VerifyHostKeyDNS to ‘ask’.

A more detailed tutorial has been posted by Tony Finch.

DANE
DANE, the DNS-Based Authentication of Named Entities (RFC 6698) is one of the key forces in pushing DNSSEC. Using DANE you can validate X.509 certificates tied to TLS using DNSSEC lookups (TLSA record). You can use it to create SSL certificate pinning for your web server certificate. Or what has recently made headlines in Germany (heise.de: BUND, Posteo) is that you can use it to secure communications between SMTP mail servers. Another advantage of DANE is that no certificate revocation list (CRL/OCSP) is required anymore to revoke a certificate. You would just replace the TLSA record. This is big news as some web browsers such as Google Chrome already abandoned CRL/OCSP verification.

Currently, web browsers do not support validation of TLSA records so you need to install an add-on. The DNSSEC/TLSA Validator from nic.cz is an excellent choice and is available for Internet Explorer, Mozilla Firefox, Google Chrome and Opera.

From a MTA perspective, currently only Postfix (v2.11) supports TLSA. However, support in Exim is in development.

You can add the TLSA record with the hash or the full X.509 certificate. TLSA can also be used to validate self-signed certificates or certificates from a specific certificate authority (e.g. QuoVadis, Comodo, CACert …).

Creating the TLSA record hash with ‘openssl’:
openssl s_client -connect presunto.switch.ch:25 -starttls smtp | openssl x509 -outform DER | openssl sha256
depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2
verify error:num=19:self signed certificate in certificate chain
verify return:0
250 HELP
(stdin)= 9d1c86ab1168cb3834c64f8bff10c15c75ca7dd6c1c3b6587a6d66f35e7cc949

The TLSA record could look as following:
_25._tcp.presunto.switch.ch. 3600 IN TLSA 3 0 1 ( 9d1c86ab1168cb3834c64f8bff10c15c75ca7dd6c1c3b6587a6d66f35e7cc949 )

In Postfix you would enable TLSA validation as following:
shell> postconf -e "smtpd_use_tls = yes"
shell> postconf -e "smtp_dns_support_level = dnssec"
shell> postconf -e "smtp_tls_security_level = dane"

Carsten Strotmann recently posted a more detailed tutorial (German) on how to add TLSA records for DANE to a zone signed by BIND 9.

DNSSEC is the future
SSHFP and DANE were only two use cases of the new PKI in DNS. DKIM for your eMail (RFC 6376) is another one. If you follow the development and adoption of DNSSEC it becomes very clear that it will become the foundation for secure communication in the Internet. I hope this blog post convinces you to learn more about DNSSEC and also motivates you to take advantage of the new PKI in DNS.