DNS Future Work BOF (DNSFUTUR) Reported by Rob Austein/Epilogue These minutes are based on notes taken by Walt Wimer and Ed King. For those who had not noticed, the DNS Working Group is now officially dead. This BOF was a reading of its ``last will and testament.'' The Namedroppers mailing list is still alive, although it was experiencing several distinct technical problems for a while. It has been moved to a new host, with aliases left behind. The discussion list is now Namedroppers@internic.net. To subscribe or unsubscribe send mail to Namedroppers-Request@internic.net Completed Tasks The following tasks of the former DNS Working Group are either complete or close enough that there is no longer need for a working group to get them finished: o DNS MIB documents: These have been approved for Proposed Standard by the IESG and are currently in the RFC mill. o ``Load Balancing'' effort: The Internet-Draft is now out. Since this is intended for publication as an Informational RFC and requires no protocol changes, the remaining issues, if any, can be settled without needing a working group. o DNS support for IDPR: This went to Last Call for Proposed Standard but was withdrawn at the author's request when Last Call review turned up problems. After talking to the IDPR and SDR people that wanted this support, the plan is to replace the draft with two new drafts: 1. ``How Not To Do DNS support for IDPR,'' which will document both the proposed mechanism and its known flaws. This will be submitted to the RFC Editor with a request to publish it as either an Informational RFC or perhaps a Historic RFC, since we know that we do not ever want to make this particular mechanism a standard. 2. ``DNS Support for SDR,'' which will document the simpler case of SDR support, where the major problems with the original draft are not relevant. This will be transferred to the SDR Working Group. ``Big Zone'' The chair had been under the mistaken impression that the ``big zone'' issue had died off due to working group apathy. Some twenty minutes of discussion on this topic proved otherwise. The following appear to have been the key points from the discussion, as recorded by our valiant correspondent when he was not ducking to escape the flamethrowers: o The ``big zone'' issue is really two separate issues: 1. Technical issues of how to maintain a large zone. 2. Exhaustion of the ``good'' parts of the DNS namespace. o Issue (1), while real, is not the major problem. We know roughly how to deal with this (incremental zone transfer or FTPing ``diff'' files or something similar) and we are working on the details. o Issue (2) is the hard problem. There are only so many three letter DNS names in the .com zone. First-come first-served was a viable answer when the Internet was just a bunch of nerds, but is unlikely to be a legally defensible answer in the future when the Internet is a ``real'' global service. o Making the DNS names longer makes the users unhappy. There are already known cases of sites where the users prefer to type IP addresses rather than DNS names, because the names are too long. o Ultimately, we need a real White Pages service, not to replace the DNS, but to provide a different set of services using the DNS as an underlying global indexing system. With such a service, it might be practical to relax the human-readability constraints on DNS names somewhat. o Geographically-based names, while still popular in some quarters, are highly controversial and lead to a group of related problems. E.g., what happens if you move, do you have to change your name? What if you are an organization with no well-defined location? o We need to agree on a list of requirements and at least somewhat on their ranking before we can design or evaluate a solution. Somewhere around this point our correspondent's pencil was hit by a stray missile, and the chair decreed that the BOF should move on to other topics. Discussion on this subject is strongly encouraged, and should be conducted on the bigz@rice.edu mailing list. Tasks Still Needing Work The following is a list of the tasks that the former DNS Working Group had undertaken and still need work, or that would have been brought to the DNS Working Group for work at the 29th IETF if the working group had not been killed: 1. ``Incremental Zone Transfer'' draft: The BOF agreed that getting this done was the number one priority for future work. Some of the underlying mechanisms needed here (e.g., timestamps) may be sufficiently close to those needed by the DNS Security work that it would be a good idea to coordinate with that group to avoid wasted effort. 2. ``DNS Requirements'' document: This is to replace/augment section 6.1 of RFC 1123, incorporating recent work such as the series of Informational RFCs issued last year, and trying real hard to provide a tool that customers could use as a checklist item when trying to obtain a decent DNS implementation from their vendors. The BOF agreed that this was a worthwhile task, provided that suitably motivated volunteers and a chair could be found. 3. ``DNS, subnet masks, and CIDR'' document: There is a lot of confusion about using the IN-ADDR.ARPA tree with (sub)network masks that are not aligned on an 8-bit boundary. This has been discussed on Namedroppers, on and off, for years. Somebody really should write it all up, probably as an Informational RFC. 4. Dynamic Update mechanism(s): The last attempt to do this, via SNMP and the DNS MIBs, was (correctly) punted because the security model was bogus. The issue has not gone away. There are really two issues lurking here: (a) A protocol/mechanism for changing DNS data on the fly, with a suitable security architecture and so forth. (b) Fast convergence of DNS data, better than the loose controls provided by the current TTL and caching models. Opinions vary about whether or not these issues are implicitly related. These issues are pretty clearly at least somewhat intertwined with both the incremental zone transfer mechanism and the DNS Security effort. While it is neither necessary nor desirable to hold up all of these efforts while trying to come up with a monolithic solution, it would be a good idea to avoid gratuitous conflicts, too. 5. ``Operational Guidelines'' document: RFCs 1032 and 1033, while better than nothing, do not fully cover the topic. The last time this issue came up in the DNS Working Group, nobody was interested in attempting to write a better document, so we punted in favor of telling people to read the O'Reilly ``DNS and BIND'' book. This still leaves something to be desired, so, given a motivated volunteer, there is still a document to be written. 6. Intermittent or partitioned networks and DNS access: Several problems that appear on the surface to be unrelated have a common thread: (a) Nameservers on the ``wrong'' side of dialup SLIP connections or otherwise only intermittently connected to the main Internet. (b) Nameservers on the ``wrong'' side of firewalls or unreachable due to policy routing. Problem (a) is potentially tied in with (1) and (4b), above, since it would be much easier to handle zone transfers if the primary could tell the secondary ``hey, I'm available now.'' Problem (b) is either a configuration error or an intentional policy, so either this is covered by tasks (2) and (5) or is the unavoidable consequence of a decision that is outside of our scope of concern. The BOF determined that tasks (1), (4), and (6a) were sufficiently interrelated that they should be undertaken by a single technically oriented Working Group, which would need to coordinate with the DNS Security working group. Randy Bush volunteered to chair this group. The BOF determined that task (2) should have its own working group. Ed King volunteered to chair this group. The BOF determined that task (3) does not appear to need a working group. Mike Patton volunteered to write the document. The BOF determined that task (5) does not appear to need a working group. Ruediger Volk volunteered to write the document. Incremental Zone Transfer Draft Having finished reading the will, the rest of the BOF was devoted to discussion of the incremental zone transfer draft and related issues. o Several people had sent comments about the current draft to the authors but felt that, in retrospect, the whole community should have been involved in the discussion. The BOF agreed that the authors of any such comments should resubmit the comments to Namedroppers, and that any future discussion should take place either there or on some dedicated mailing list if the signal-to-noise ratio on namedroppers get too high. o Jon Postel (one of the authors of the current IXFR draft) pointed out that the current IXFR draft both proposes some general purpose extensions to the DNS architecture and makes use of those extensions to provide the IXFR service. It may be appropriate to separate these two topics into two distinct papers. o The current IXFR draft requires (or at least strongly suggests) that the primary DNS name servers keep track of the state of the secondary name servers. Some people think this is a bad idea; some people do not believe that the primaries should even have to know about all their secondaries. o The current IXFR draft does not clearly distinguish between protocol operations and a suggested implementation. Worse, the draft recommends discarding an old, but still valid copy of a zone, before obtaining a new one for reasons that turn out to depend on assumptions about design bugs in the implementation. This needs to be fixed. o The current IXFR draft has the primary server knowing about its secondaries for two distinct purposes: to send NOTIFY messages, and to determine when the primary can discard incremental change information (what the draft calls ``zombie records''). Some people think that these mechanisms should be de-coupled; that is, that the change information should not necessarily be discarded just because all the secondary servers on the notification list have picked up their updates, because there may be other secondary servers, authoritative or not, which for some reason do not want or cannot receive notifications. o As part of the discussion of extensions to the DNS architecture, the subject of UDP packet sizes came up. Given that the world has changed significantly since the DNS was designed, it may make sense to reexamine the recommended maximum packet size. The DNS Security Working Group is running into this same issue. The real issue here is not packet size per se but message truncation and lossy fragmentation. As a rough guide, it would be useful to find out what the real MTUs are that are in common use on the Internet today. The IETF mailing list might be a good place to ask about this. It would be nice to make use of path MTU discovery in DNS, but the use of UDP as a transport protocol and DNS traffic patterns combine to make this a non-trivial problem. However, a site that is organized to use one or two caching ``super-resolvers'' for all outside queries might be able to do something useful with path MTU discovery in the super-resolvers. Firewalled systems that only allow a few resolvers to transit the firewall are another case that might naturally lend itself to path MTU discovery. o If/when a dynamic update mechanism falls out of this work, it may be possible to use it to perform load balancing tasks. Whether or not this would be a desirable thing to do is a question we probably cannot answer until we know how dynamic update works. Having thus completed, transferred, or punted the obligations of the former DNS Working Group, the DNSFUTUR BOF declared victory and went home. Attendees Mark Allyn allyn@netcom.com Robert Austein sra@epilogue.com Randy Bush randy@psg.com Terry Davis tld5032@commanche.ca.boeing.com Donald Eastlake dee@lkg.dec.com Duane Harkness duaneh@atc.boeing.com Charlie Kaufman kaufman@zk3.dec.com Hiroshi Kawazoe kawazoe@trl.ibm.co.jp Edwin King eek@atc.boeing.com Kim Morla kmorla@pucp.edu.pe Masataka Ohta mohta@cc.titech.ac.jp Michael Patton map@bbn.com Jon Postel postel@isi.edu Robert Reschly reschly@brl.mil Ruediger Volk rv@informatik.uni-dortmund.de