DNSSEC key rollover
The main subject on the agenda during the DNS Extensions (DNSEXT) meeting was automated DNSSEC key rollover. There are different views on how important the existence of such a mechanism is for initial DNSSEC deployment.
There are also competing drafts (and methods) to do key rollover for DNSSEC for the roots. The plan is to advance one of them. Meanwhile the main differences between the various methods will be documented and published in order to get the discussion started. While technical solutions have been specified, there exist IPR claims (a patent has been filed in Israel) which make further work on the two existing Internet-Drafts troublesome.
There was also a non-IETF meeting of several TLDs on Tuesday where Bill Manning presented his Client Authenticated DNS Request (CADR) system which should enable TLD managers to securely (and, hopefully, quickly) change their TLD’s delegation information (name server names and addresses).
The prototype combines DNSSEC technology and a secured website to convey authenticated information to IANA. Currently the system has technical restrictions and also implies policy changes, so it is unclear how things will proceed.
There is progress on the definition of the new NSEC record and there is even the possibility of code for real testing within a couple of months. The fact that with this proposal the Opt-In proposal pops up again is something that might be cause for quite some discussion.
The desire was expressed not to repeat the whole discussion. The chairs urged to leave out political arguments which made the previous debate ugly.
Server Identification extension
With the deployment of anycast for nameservers, there is a need to have an identification of which server actually answered the question. This would help debugging of anycast systems. Progress was made on the way this should develop and a new ID by Rob Austein is expected.
Domain Name System (DNS) IANA Considerations
To help experimenting with new RR types in DNS, Donald Eastlake proposed some policy rules for IANA to register these RR types. RFC 2929 Early Allocation for RRs (RFC 4020) is felt to be too strict. Policy being policy, this of course caused a lot of discussion. A new and less controversial ID is expected to be published soon.
TAHI Test tool set
There was a small presentation of an effort to do conformance testing (www.tahi.org). There is some overlap with the French group doing DNS infrastructure testing (www.idsa.prd.fr/index.php?lang=en) and both groups promise to work together.
Best Current Practice for TLD Zones
During the DNSOPS WG meeting Kurtis Lindqvist presented a draft which was trying to address best practices for TLD zones. It triggered a lot of discussion since it compares running TLDs to the proverbial blind man describing an elephant.
Just what is involved? Is it running the name servers? Is it the registry, the Whois server, etc? Is it all of these or just some of them? Also, this might be taken as a requirements document to dictate on technical grounds political decisions in places such as, and not limited to, ICANN, ITU, WSIS, UN, OECD, Governments etc. This was of course not the purpose, but one never knows what will happen. The document will be split in, at least, two parts.
One part on “how to run nameservers”, which is in itself not a trivial problem statement. For the “how to run a TLD registry” documents there will be some discussions with various groups (including ISOC) in order to define the scope of such a document. This is needed in order to avoid treading into level 9 space.
Note: This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects a personal perspective on some current highlights.