Next 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:
DNSOP
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.
DANE
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.