Our colleague Jan Žorž from the Deploy360 team was asked to present during the DNS/DNSSEC sessions during APRICOT 2017 last week, and this provides us with the opportunity to highlight a few of the other presentations there.
If you need to make the technical and/or business case for deploying DNSSEC, then you can do worse than check out the excellent presentation from Jim Reid (RTFM). In particular, he dispels some of the myths surrounding the size of zone files, CPU loads, traffic levels and key rollover, whilst covering some of the tools that can be used to manage and debug DNSSEC installations. It’s pretty in-depth and covers quite a few aspects of running DNSSEC, but it’s maybe worth highlighting some of the guides and tools mentioned.
For those looking for guidance on issues such as key selection and signature duration, NIST report 800-81-2 is recommended, whilst RFC 6841 is suggested as a starting point for a DNSSEC policy/practice statement. When it comes to troubleshooting though, then DNSSEC drill from NLnet Labs can be used to validate domains, show which key algorithms and lengths are used, pinpoint stale keys and signatures, and identify DS record and KSK mismatches. ISC also has a similar tool called delv included with BIND 9.10 and above distributions, whilst DNSVIZ also offers a web-based visualisation tool that allows you to type in a domain name and check whether it validates correctly, although it uses its own resolver.
Jim said one of big drivers of DNSSEC could be DANE, especially with the emergence of Let’s Encrypt and the IETF’s ACME standards that are promoting the use of TLS. DANE can address the issue of third-party trust as it allows digital certificates to be DNS and signed with DNSSEC, enabling end users to validate that the correct certificate is being used.
This led into Jan’s presentation where he explained how he’d deployed and tested DANE in the Go6lab. As well as demonstrating that deployment can be straightforward, it also showed that nearly 70% of all attempted SMTP sessions with the top million Alexa domains were encrypted with TLS. 41% of these used a certificate from a trusted CA, 17% used an untrusted certificate, whilst 11% was opportunist and unsigned, but it does illustrate the potential opportunities for DANE. The other important point to make is that DANE is particularly useful for non-web applications such as SMTP (e-mail) and XMPP (Jabber) where it is difficult to visually identify the validity of a certificate.
On a practical level, DNSSEC has recently been implemented in Vietnam, and Nguyen Trung Keen (VNNIC) provided an overview of DNSSEC deployment on .vn. This had been planned for two years, with the necessary infrastructure being installed at two separate sites. The key signing ceremony had taken place on 20 December 2016, with the DS record for .vn being activated in the root zone on 31 December 2016.
The next stages were sign the second level domains (e.g. com.vn, net.vn), as well as open a testbed to allow registrars to add and update signed domains for their customers. A training programme was also planned during 2017 to encourage ISPs, DNS hosting providers and other DNS owners to deploy DNSSEC. So the message is that DNSSEC is becoming increasingly available and you need to think about implementing it.
And just in case you haven’t yet heard the news, Rick Lamb (ICANN) discussed ICANN’s plans to roll the Root Zone DNSSEC Key Signing Key during the second-half of 2017. ICANN in its role as the IANA Functions Operator, manages the Key Signing Key (KSK) used to sign the Root Zone Signing Key (ZSK) which is managed by VeriSign and changed every quarter. The current KSK has been used since the Root Zone was first signed in 2010, it’s good practice to change keys, and ICANN wish to try this exercise under normal rather than emergency conditions (such as a key compromise).
The rollover plan is outlined in five documents, with a view to generating the new KSK in the 4th quarter of 2016, adding it to the root zone on 11 July 2017 (in parallel with the old KSK), and then signing the DNSKEY RRset starting from 11 October 2017. The old KSK will be revoked on 11 January 2018, but will remain in the root zone.
The DNS/DNSSEC session was held in two parts, and both are available on YouTube. Whilst not directly DNSSEC-related, you might also want to check out the other presentation from Jim Reid (RTFM) on Using ~300 Billion DNS Queries to Analyse the TLD Name Collision Problem in Session 2.
If this inspires you to deploy DNSSEC, then please see our Start Here page for more information!