‹ Back
Deploy360 23 July 2013

2 DNSSEC / DANE Sessions Next Week At IETF 87 In Berlin

Dan York
By Dan YorkDirector, Online Content

IETF LogoNext week is the 87th meeting of the Internet Engineering Task Force (IETF)  in Berlin, Germany, and there will be two working groups meeting that are related to DNSSEC on the agenda:


The DNSOP (DNS Operations) Working Group will meet on Thursday, August 1, from 1520-1650 (Berlin time) in the Bellevue room.  There are 3 major items on the DNSOP agenda, but the one of strong importance related to DNSSEC is the discussion about how to communicate that there has been a change in the Key Signing Key (KSK) from a child zone up to a parent zone.  In other words, when you create a new KSK for your child zone, can we get an automated way to communicate the existence of this new KSK to the parent zone so that a DS record can be created and the global chain of trust can be updated?

Somewhat ironically, I experienced this precise issue myself last week when, during the DNSSEC Workshop at ICANN 47, a KSK on one of my personal zones expired.  The company providing DNS hosting for that domain automatically generated a new KSK, but they have no way of alerting the parent zone (.ORG in this case) that a new DS record is ready for upload.  I had to login to the web interface for my registrar and copy/paste the DS record from the web interface of my DNS hosting provider.  Meanwhile, my domain was failing validation.

There are two different proposals for mechanisms to automate this process.  Warren Kumari, Olafur Gudmundsson and George Barwood submitted draft-kumari-ogud-dnsop-cds that proposed the creation of a new “CDS” record type in DNS.  Essentially, the parent zone will periodically poll the child zones and if a new CDS record is found the parent zone will update the DS record for the zone.  Separately, Wes Hardaker developed draft-hardaker-dnsop-csync providing a similar but broader mechanism for synchronizing child and parent zones. This draft involves the creation of a “CSYNC” record type in DNS which tells the parent zone which records in the child zone need to be updated in the parent zone.  Wes originally wrote the draft to look at how to synchronize NS records and their associated A and AAAA records (what we often call “glue” records) between child and parent zones but then added support for DS and DNSKEY records to stimulate further discussion.

At DNSOP there will be a joint presentation about the two drafts with an interest in looking at “where do we go from here”.  It should be an interesting discussion and if you are unable to attend in person you can listen to the remote audio stream at the specified time.


Right after DNSOP, the DANE Working Group will meet on Thursday, August 1, from 1700-1830 (Berlin time) in the Potsdam 1 room.  With RFC 6698 now specifying the DANE protocol the WG is focused more on how DANE will be used by various services.  The agenda has not yet been posted, but there has been active discussion on the DANE mailing list about drafts relating to using DANE with email (both SMTP and S/MIME) and with voice-over-IP (SIP) as well as with OpenPGP and OTR.  As someone who sees DANE as a powerful reason to deploy DNSSEC, I’m very much looking foward to the discussion in this group and to seeing where DANE is going.

If you are unable to attend IETF 87 in person, you will be able to listen remotely to the DANE working group at its specified time.

‹ Back

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

Related articles

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...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...