For more details about DNS-related working-group meetings, refer to the minutes and Jabber notes for each meeting at www3.ietf.org/proceedings/06jul.
DNS Extensions Working Group
The DNS Extensions Working Group deals with both the details of the DNS protocol and its extensions, such as the Security Extension (DNSSEC) . The group reports progress on reducing backlog and advancing documents. To date, the Wild Card Clarify draft, which updated the wildcard definition of RFC 1034, achieved RFC status (RFC 4592: The Role of Wildcards in the Domain Name System). According to the authors, the RFC did not change the essence of the protocol; rather, it refined the definition of RFC 1034 to make it more consistent and to reflect reality.
The dynamic host client identifier draft is currently in the RFC Editor queue and the new Resource Record Type-code has been assigned by IANA (DHCID, Type-code 49). Four other documents are in IETF Last Call; two are in working group Last Call and the others are close to that stage.
NSEC3 Update
The work on NSEC3 is still progressing. A workshop where various implementations and specifications were tested was successful. Several issues were discovered in both the drafts and implementations. David Blacka presented those in detail at the IETF meeting, and a lively discussion followed that is likely to continue on the mailing list. A new workshop test is planned for September. In the meantime, a permanent testbed has been set up for the purpose of testing various ideas. Details of the efforts can be found at www.nsec3.org. Discussions will take place on the official dnsext-wg mailing list.
DNS Trust Anchor Management
A couple of competing drafts have emerged proposing a roll-over mechanism for updating the trust anchors in DNSSEC aware resolvers. Several reviews of the various methods have been published on the dnsext mailing list. A few common elements of the drafts include threshold schemata or the use of timers. The timer-based proposal seems to be the most complete, and it was agreed that the proposal should serve as the basis for further work.
DNAME Clarify Effort
Meeting participants expressed concern that RFC2672 (status: Proposed Standard) suffers from omissions and is unclear in terms of how the DNAME interacts with wildcards, EDNS0, compression and similar stuff. Plans are currently under way for the use of DNAME in a wide-scale operation, though the DNSSEC implementers expressed the need for clarification. The plan is to first collect open questions and perceived ambiguities in the DNAME specification in a separate draft and then to ask the working group for feedback in order to create resolutions that can be added to a DNAME Clarifications document. An explicit ‘non-Goal’ is the creation of a DNAME-2.
New Work: DNS Cookies
Donald Eastlake presented a proposal for a dynamic system that requires neither configuration nor set-up in order to provide weak authentication of queries and responses between servers and resolvers. It can be described as a weaker version of client authentication and is intended to greatly reduce the increasingly popular attacks that use forced source addresses. Although there was some interest in the proposal, it has not been formalised, and the community is encouraged to comment. Feedback on operational requirements will be solicited from the DNSOP WG.
Mark Andrews proposed a method for revealing zone cuts without having negative entries recorded in caches. He wrote an Internet-Draft and asked about achieving Last Call (LC) for the document. Apparently, the method has already been implemented in the latest version of bind.
Milestones
Given the catching up there has been on the backlog and the new work trickling in, there is a need to update the milestones. The chairs will prepare a draft to discuss.
DNS Operations Working Group
The DNS Operations Working Group deals with the daily dross of operating DNS. The WG does not create protocols; the participants discuss the use of protocols in practice. Work on reducing the backlog continues and there are now a couple of Internet-Drafts in Last-Call stage or close to publication, such as the DNSSEC best practices and the server id. The last extension will make it easier to maintain DNS any-cast server clusters.
Open Recursive Servers
It became increasingly popular in the past year to use public recursive name servers as amplification mechanisms in D-DOS attacks. In essence, one spoofs the address of the victim and generates, via such public name servers, massive amounts of traffic to the victim. At the request of the WG chairs, Frederico Neves and João Damas have written an I-D to document this practice for the DNS operators and there have been discussions about the trade-offs when dealing with these attacks. Solutions are being discussed, and a new version of the I-D is expected to be published soon.
Default Local Zones and AS 112
Project AS112 (www.as112.net) is a loosely organised group of volunteers who operate systems that respond to DNS queries for the reverse mapping of so-called private address space of BCP 5 (RFC 1918). These queries should never meet the public Internet. Therefore a two-stage approach for managing them was suggested. First, nameserver software vendors are encouraged to avoid leaking queries by directly answering those about local zones and, second, as a potential new WG work item, by documenting the setup of AS112 for new team members and organisations or site DNS administrators, which will reduce the pollution.
Other (Non-WG) Internet-Drafts and Discussions
Web server cookie-validation ads often make assumptions about the structure of the Top-Level-Domain (TLD) name space. As Yngve Pettersen presented, even though administrative hierarchy does not imply or follow the hierarchy of the DNS, concerns are being raised about attempts to subvert this principle. A number of suggestions were made, but no conclusions or actions were finalised.
ENUM WG
ENUM is a protocol that links the DNS with the VoIP and PSTN worlds by mapping phone numbers to services such as SIP, instant messaging, multimedia mail messages and, of course, phone calls. Defining and specifying ENUM services has been a major work item in the ENUM WG for some time, so it seems more than reasonable that the WG should now address the issue of providing guidelines and a registration template to aid future service registrants. The prospected multitude of services, and the use of the DNS NAPTR record, will lead to larger DNS responses; even more so when DNSSEC is used in combination with ENUM. Therefore, the WG is currently working on a recommendation to vendors and operators of ENUM-related name servers and clients to support the DNS EDNS0 protocol extension for larger packet sizes. There is a document collecting examples of the ways in which different implementers chose to interpret the ENUM specification. It is expected to serve as a source of information when it comes to clarifying and advancing RFC 3761, which is the big task for the ENUM WG in the next year.
Miscellaneous
The DNS is an attractive data publishing and retrieval mechanism, which explains why so many IETF working groups are working on DNS-based solutions for their particular problems. This offers ample opportunity for cross-working-group discussions that make it possible to share experiences designing DNS extensions while at the same time preserving the benefits that the DNS offers, such as scalability. The dnsext WG is working on an update to RFC 2929 that will make registration of new resource record types easier and that provides some operational and architectural guidance. This is also the intention of a draft initiated by the IAB that discusses trade-offs of several popular approaches for basing new applications on the DNS.