The DNS ext working group started with business as usual – a run down of the status of various Internet Drafts (ID). For a complete list, see the agenda at:http://www3.ietf.org/proceedings/05nov/agenda/dnsext.htm.
Draft minutes of the working group are available here:http://www3.ietf.org/proceedings/05nov/minutes/dnsext.txt.
The mDNS ID returned to the working group. The chairs post a summary about the comments to the mailing list with a request for review.
DNS Testing
The Tahi group reported on their first interoperability testing effort. They tested one DNS client and found some bugs in the client and some bugs in the testing tool. They did not find any issues with the basic DNS specifications. The next scheduled TAHI testing event is at the end of January 2006.
NSEC3 Update
The definition of the NSEC3 records is progressing rapidly. Among the things that got discussed was whether a new record type might be needed for storing meta data. This would help to prevent collisions of hash names and legitimate zone names. A decision about this is delayed until experience is gathered from real implementations. Such experiments should take place before the document is advanced. A testing and engineering workshop might be held at the beginning of 2006.
The Big Trust Anchor Management debate
The way the trust anchor for DNSSEC in the resolver is managed is not defined, but this needs to be done. Doing things manually is error prone so people are looking into ways for automating this process. Currently there are four proposals – with IDs already written for three of them. There are various intellectual property claims to a couple of these ideas, but the strength of each individual claim is not clear. During the discussion it became evident that all solutions are struggling with at least two different problems: Initial key distribution and key roll over. The need is felt for a short requirements document. Some volunteers have stepped forward to write this within a short time frame (three months).
The Sky is falling!
The crypto algorithms used in DNSSEC come from standard sources. One of these, the SHA-1 is under attack and some weaknesses have been found. The way that DNSSEC uses SHA-1 is not affected by this weakness, so the sky is not really falling. Since there is not yet widespread deployment of DNSSEC, it is better to replace SHA-1 by SHA-256 now, just in case SHA-1 gets even more tainted in future. For this purpose a new ID will be written which will make SHA-256 mandatory to implement.
Workload Review
The chairs suggested that for a working group document to advance or to be accepted at least four or five people should have committed to review. If not, it will be dropped by the group and authors will have to do a personal submission. The room hummed consensus.
DNSOP
The WG has a new co-chair, Peter Koch, replacing David Meyer. The participants agreed to work on the document backlog one-by-one to significantly reduce the number of open and close-to-finished documents before the next meeting in Dallas. This is why no new work was adopted as WG items. For a list of current work items, see http://www3.ietf.org/proceedings/05nov/agenda/dnsop.txt
6to4 Reverse DNS Delegation
The (expired) draft-huston-6to4-reverse-dns-03.txt describes a potential mechanism for entering a description of DNS servers which provide “reverse lookup” of 6to4 addresses into the 6to4 reverse zone file and is asked by an IAB IPv6 ad-hoc to be published by the DNSOP WG. After some discussion whether the WG should publish other people’s work, it was agreed to do so. Some reviewers stepped forward.
Cross-WG review
Other WGs (e.g. ENUM, GEOPRIV, ECRIT) are increasingly asking for review of their drafts buy DNSOP (and DNSEXT), often via the IESG. As an example, the ENUM WG feels the need for clarification about ENDS(0) and volunteers were found to write such a document. Here the question was also how to communicate to both vendors and network operators that EDNS0 is a sheer necessity in today’s DNS operations, particularly needed for ENUM and DNSSEC, but considered non-optional in the general case.
The DNSOP WG minutes are available at http://www3.ietf.org/proceedings/05nov/dnsop.html
New work: AS 112 in a box
Queries to domains such as 168.192.in-addr.arpa or 8.e.f.ip6.arpa leak all over the Internet and end up at the root-servers. There is a network of volunteers (see http://www.as112.net/), operating (anycasted) domain name servers trying to answer these queries, before they hit the root servers. For a description see the http://public.as112.net/ website. The new work proposes that resolvers themselves should directly return authoritative answers for special domains.