Rough Guide To IETF 89: DNSSEC, DANE and DNS Security Thumbnail
‹ Back
Domain Name System (DNS) 27 February 2014

Rough Guide To IETF 89: DNSSEC, DANE and DNS Security

Dan York
By Dan YorkDirector, Online Content

At IETF 89 next week in London there is a huge amount of activity related to DNSSEC, DANE and DNS security in general, largely due to three brand new working groups and two new birds-of-a-feather (BOF) sessions.

Both of the “regular” IETF working groups concerned with DNSSEC are meeting this week: DANE and DNSOP. The DANE Working Group meets on Thursday morning with its focus on how to use the DANE protocol to add more security to the TLS/SSL infrastructure of the Internet. The DANE WG agenda is addressing topics such as:

  • Using DANE to secure email and IM communication
  • Operational guidance on implementing DANE TLSA records
  • Using DANE with protocols such as OpenPGP and IPSEC

Given that DANE is also being considered in a variety of other working groups and discussions as a means to better secure Internet connections, I expect this meeting to be a well-attended session.

On Friday morning the DNS Operations (DNSOP) Working Group has a very packed agenda with the biggest DNSSEC-related piece being the drafts around how to deal with the critical issue of the uploading of DS records from DNS operators to registries. There will also be a summary of the DNSE BOF and a discussion of a new draft around DNSSEC Validator requirements. For those interested in the operational aspects of DNS this will be a must-attend session.

Unfortunately, meeting at the same exact time on Friday morning as DNSOP will be the brand new Using TLS in Applications (UTA) Working Group that has as a primary goal to deliver a set of documents that are “go to” security guides aimed at helping developers add TLS support into their applications. While the UTA agenda has no direct mention of DNSSEC or DANE, both have been brought up within UTA discussions as a mechanism to add further security to TLS connections and our interest is certainly in seeing how or if DNSSEC / DANE can help.

On this general topic of TLS, certificates and DANE, we’re also going to be attending the new Public Notary Transparency (trans) Working Group on Wednesday that is looking at how to update the experimental RFC 6962, “Certificate Transparency,” to reflect recent implementation and deployment experience. The goal here is to provide a mechanism to create cryptographically verifiable logs that can be used in detecting misuse of website certificates. Our particular interest is that part of the charter is to ensure that this mechanism can work in the presence of DANE records in addition to regular web certificate-based systems.

Another very important addition to IETF 89 is the new EPP Extensions (eppext) Working Group that is focused on documenting extensions to the Extensible Provisioning Protocol (EPP) that is used primarily for communication between domain name registrars and top-level domain (TLD) registries as well as DNS operators. We’re most interested in draft-ietf-eppext-keyrelay that defines a mechanism for securely relaying DNSSEC keys between DNS operators. The primary benefit of this will be the secure transfer of a DNSSEC-signed domain from one DNS operator to another.

There are two new “BoF” sessions at IETF 89 related to DNS and the “DNSE” BOF has our greatest attention. The full name is “Encryption of DNS requests for confidentiality” and the focus is on exploring what can be done to ensure confidentiality of DNS requests from sniffing. While DNSSEC ensures the integrity of DNS requests, it does nothing to protect DNS packets from sniffing. The DNSE BoF will use draft-bortzmeyer-dnsop-dns-privacy and draft-koch-perpass-dns-confidentiality as starting points to explore what can be done for DNS confidentiality and to identify the best path for moving that work forward within the IETF.

The second BoF is Domain Boundaries (dbound) which is looking at how domain names – and perhaps more importantly subsequent levels of domain names – are used to infer relationships and security settings. This group is meeting to understand if there is sufficient interest to undertake work within the IETF and how best to do so. My interest is in understanding how this may fit into the other DNS security components of the work we are doing such as DNSSEC and DANE.

Finally, rounding out the DNS work next week, the Extensions for Scalable DNS Service Discovery (dnssd) Working Group is meeting on Monday to continue their discussions about how DNS-SD (RFC6763) and mDNS (RFC6762) can be used beyond the local network. The idea is if you think about how you easily “discover” a printer on your local network – imagine if you could do that across a wider network. For instance, maybe in your neighbor’s or a parent’s home (assuming he/she let you). As I wrote about for IETF 88, our interest here is in understanding how this is done while ensuring the security of the DNS requests – and where DNSSEC may or may not fit into the picture.

We’ll also finish out the week with a breakfast meeting Friday morning with people involved in the DNSSEC Coordination effort (and anyone can join the mailing list) where we’ll have some conversation and food before heading off to the DNSOP and/or UTA working groups.

All in all it’s going to be a VERY busy week for those of us interested in DNS security!

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups and BoFs at IETF 89:

To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

10 March 2021

Internet Society Joins Leading Internet Advocates to Call on ISPs to Commit to Basic User Privacy Protections

Mozilla, the Electronic Frontier Foundation, and the Internet Society call on AT&T, T-Mobile, and Verizon to commit to limiting...

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Join the conversation with Internet Society members around the world