On the Internet, the Domain Name System (DNS) performs the critical role of translating human-readable domain names into the underlying IP addresses needed by computers to connect. The challenge is that attackers can subvert and modify DNS messages with the result that users and applications can be directed to wrong (and potentially malicious) sites. In response to this threat, the IETF community created DNS Security Extensions (DNSSEC), which is now being deployed across the Internet. Several Working Groups (WGs) and BoFs will take place at IETF 88 in Vancouver next week to discuss issues related to DNSSEC, DANE, and DNS.
Since IETF 87 in Berlin, one big step forward for DNSSEC was that the DNSEXT Working Group concluded its work and closed down. This was in recognition that the standardization of DNSSEC is now finished and the protocol now moves more into the operationalization and deployment phase of its existence.
To that end, the primary focus of DNSSEC discussion at IETF 88 will be in the DNS Operations (DNSOP) Working Group on the afternoon of Tuesday, November 5th. A key point of discussion will be around how we can automate the transfer of new DNSSEC key information from a domain (a “child” zone) up to the parent zone (typically a top-level domain (TLD)). Right now when a new key is generated in the zone, there is a critical process of uploading a Delegation Signer (DS) record or a DNSKEY record up to the parent zone to ensure that the “global chain of trust” remains intact for that domain. Unfortunately, right now this often involves some type of manual process, which might even be a copy-and-paste between web interfaces of a DNS operator and a domain registrar.
One solution (http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds) proposes the creation of a new set of records that would trigger an update to the parent zone. A similar proposal (http://tools.ietf.org/html/draft-hardaker-dnsop-csync) looks at a more generic solution to signal to a parent zone which records in a child zone need to be uploaded to the parent zone. As these solutions require polling by the parent zone operator, there are concerns about how these may work and the DNSOP discussion should be a lively one.
Another presentation in the DNSOP Working Group will be around a draft (http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase) outlining how the increased deployment of DNSSEC-validating DNS resolvers is raising the number of DS queries to TLD registries – and offering several suggestions as to how that increase might be reduced.
Continuing on the operational theme, two other drafts (http://tools.ietf.org/html/draft-wouters-edns-tcp-keepalive and http://tools.ietf.org/html/draft-wouters-edns-tcp-chain-query) will be discussed looking at ways to streamline the communication from DNS resolvers to DNS servers to speed up the process of DNSSEC validation and to reduce the number of queries used in the process.
The DANE Working Group will not be meeting at IETF 88 as the group’s work is progressing on the mailing lists and face-to-face time was not required. However, given the general concerns about hardening the Internet against pervasive monitoring, I expect that the DANE protocol (RFC 6698) will probably be mentioned in working groups such as Web PKI Operations (WPKOPS) and even in the larger Perpass BoF around Internet hardening.
On the general topic of DNS, a final IETF 88 session worth mentioning is the DNS-SD Extensions (DNSSD) Working Group. This group is looking at how DNS service discovery mechanisms such as DNS-SD (RFC6763) and mDNS (RFC6762) can be extended beyond a simple home environment or single local area network (LAN). As groups such as the Homenet WG explore multi-link home networks and as industry groups working on “Internet of Things” sensor networks explore wide area routing, they are looking to use these DNS service discovery protocols for “zero configuration” of services. Imagine that you might want your laptop or mobile phone to easily connect from your home network to a printer in the home of another family member – how do you do that while ensuring that the connections are authorized and secure?
The good news with DNSSEC/DANE is that we’re now spending time within the IETF on getting these protocols widely deployed and removing any remaining technical roadblocks. The discussions at IETF 88 should be quite productive and I expect we’ll see solid progress coming out of these meetings.
P.S. For more information about DNSSEC and DANE and how you can get them deployed in your networks and domains, please see our Deploy360 site:
http://www.internetsociety.org/deploy360/dnssec/
http://www.internetsociety.org/deploy360/resources/dane/
Related Working Groups at IETF 88:
- dnsop (DNS Operations) WG
Agenda: https://datatracker.ietf.org/meeting/88/agenda/dnsop/
Charter: https://datatracker.ietf.org/wg/dnsop/charter/
(5 November 2013, 1420-1550)
- dnssd (DNS-SD Extensions) WG
Agenda: https://datatracker.ietf.org/meeting/88/agenda/dnssd/
Charter: https://datatracker.ietf.org/group/dnssd/about/
(8 November 2013, 1120-1220, 1230-1330)
- wpkops (Web PKI Operations) WG
Agenda: https://datatracker.ietf.org/meeting/88/agenda/wpkops/
Charter: https://datatracker.ietf.org/wg/wpkops/charter/
(7 November 2013, 1520-1720)
- perpass (Handling Pervasive Monitoring in the IETF) BOF
Agenda: https://datatracker.ietf.org/meeting/88/agenda/perpass/
(6 November 2013, 1300-1530)
IEFT 88 Rough guide:
- A Close Encounter of the Standards Kind – Internet Society Rough Guide to IETF 88
- Rough Guide to IETF 88: Routing Resilience
- Rough Guide to IETF 88: Scalability and Performance
- Rough Guide to IETF 88: All About IPv6
- Rough Guide to IETF 88: DNSSEC, DANE and DNS
- Rough Guide to IETF 88: Trust, Identity, and Privacy