CURRENT_MEETING_REPORT_ Reported by Rob Austein/Epilogue Technology Minutes of the Domain Name System Working Group (DNS) The meeting opened with a few comments by the Chair regarding the future of the Working Group. In brief, the Working Group has been in existence for a long time, with ill-defined goals and an odd mixture of tasks. Some of the Working Group's tasks are of an ongoing nature, some are very specific with definite goals and milestones. As currently organized, the Working Group does not fit well into the IETF administrative structure. At some point in the relatively near future it may be necessary to restructure the Group to address this problem. The Chair will be working with the Director of the new IETF Service Applications Area to address this issue. Given the state of flux that the IESG and the IETF itself were in at the time of the Working Group meeting, the Working Group decided to spin off a few well-defined tasks to ``sub-groups'' but otherwise leave the current DNS Working Group structure unchanged. Whether the ``sub-groups'' would be full-fledged IETF working groups or just subcommittees of the DNS Working Group was left unspecified; the organizers of the three sub-groups spun off at this meeting all subsequently expressed a distinct preference for being subcommittees rather than independent working groups. The next item of business was to dispose of some old tasks that were still listed on the Group's Charter. The following tasks were removed from the task list: 1. Discussion of adding a Responsible Person RR. 2. Discussion of adding network naming capability to the DNS. 3. Implementation catalogue for DNS software. 4. Writing a ``DNS operators guide''. Tasks (1) and (2) were done years ago and published in RFCs 1183 and 1101, respectively. Task (3) was killed for lack of any volunteers who care about it enough to write it; if such a volunteer exists, that person should just write the document, we don't need a group effort to do this. The Group also briefly discussed writing a ``DNS Operators guide'', Task (4). Since both RFCs 1032-1033 and an O'Reilly Associates book exist on the subject, the Group felt that writing such a document would be a waste of time. Stuart Vance agreed to write a one-page document referring readers to the O'Reilly Associates book; if there are other published documents on this subject, whether commercial or free, please announce them on the Namedroppers list for possible mention in Stuart's reference. 1 Next on the Agenda were the three tasks that were felt by the Group to be of sufficient interest to form a subgroup to work on each task. Each task was discussed for long enough to air some of the issues that needed to be addressed, then the Chair called for someone willing to organize a subgroup willing to attack the problem and report back. 1. Scaling problems of ``big zones'', particularly the .COM zone. The Working Group has been kicking this problem around for a year without much progress. Discussion was limited to a summary of the problem by Mike St. Johns and to new suggestions by the Working Group. One-line summary: some of the first-level DNS zones are approaching the size of the old NIC HOSTS.TXT file, which leads to various technical and political problems. Please see the Minutes of previous DNS Working Group meetings for background on this discussion. John Romkey pointed out that, as the Internet grows and more hosts are registered in the DNS, it will be increasingly hard to maintain any kind of obvious correlation between DNS names and ``real'' names. All the proposed ``solutions'' to the .COM zone problem will exacerbate this situation; the only exception is the ``XYZCORP.X.COM'' partitioning scheme, which, while ugly, is at least obvious. In the long run we need a solution to the problem of unintuitive names in the DNS. Whatever solution we pick for the .COM zone should be chosen with this in mind, so that we don't make the problem worse. Bill Manning agreed to lead a subgroup to investigate the problem and report back. The subgroup's mailing list is ``bigz@rice.edu'', send mail to ``bigz-request@rice.edu'' to join the list. 2. DNS security. The Working Group heard a report from Steve Crocker, Director of the IETF Security Area. There are really two tasks under discussion. (a) The first security task is bulletproofing the DNS so that it cannot be spoofed without ability to spoof IP addresses; this is, essentially, Paul Mockapetris's ``Just As Good As IP'' security mechanism, as described by Paul at the ``DNS-II'' BOF held at the 25th IETF in Washington DC. This level of security could also be described as ``robustness,'' that is, implementation of Paul's techniques would help defend the global DNS database against some of the accidental spoofing that has happened over the years. This is primarily an implementation issue, and wheels are already rolling to get this mechanism into a near-future release of BIND. Watch the namedroppers list for announcements. (b) The second security task is specifying a mechanism by which RRs could be accompanied by digital signature information for authentication. Both for backwards compatibility with existing DNS software and in order to avoid running afoul of U.S. export 2 controls on cryptographic software, this signature must be an optional mechanism, added in such a way that non-players can ignore it and still comply with the DNS protocols. The general idea is to define a new RR type, the RDATA portion of which would be used to contain the digital signature. James Galvin agreed to lead a subgroup to work on this project and report back to the Working Group. The subgroup's mailing list is ``dns-security@tis.com'', send mail to ``dns-security-request@tis.com'' to join the list. 3. Load balancing. This task has been with the Working Group for a long time. At the time of this meeting there were at least four mechanisms proposed to solve some aspect of the ``load balancing'' problem, some already in widespread use, one requiring no protocol changes at all. Tom Brisco and Stuart Vance agreed to lead a subgroup to investigate this problem and document their conclusions. The subgroup's mailing list is ``dns-wg-lb@ns1.rutgers.edu'', send mail to ``dns-wg-lb-request@ns1.rutgers.edu'' to join the list. Next, the Working Group heard a report on the current status of the DNS MIB from Frank Kastenholz, representing the IETF Network Management Directorate. In brief, the DNS MIB has been stalled since the 25th IETF for two reasons: 1. The Network Management Area Directorate has been busy with the emerging SNMPv2 specification and suffered some disorganization due to the abrupt resignation of its Area Director, and 2. The DNS MIB presents some non-trivial problems, because there are some cases where the ``SNMP way'' and the ``DNS way'' of doing things are diametrically opposed. Problem (1) is already being repaired: a new Area Director for Network Management was elected two days after the DNS Working Group meeting, and the SNMPv2 specification is on its way out the door. Problem (2) will be addressed by Frank (representing the Network Management Area Directorate) and the authors of the DNS MIB. Frank suggested that the DNS Working Group consider whether or not SNMP was really the right tool for all of the management tasks addressed by the DNS MIB, and for the proposed dynamic update mechanism (dynamic creation and deletion of RRs via a network protocol); it's possible that extensions to the DNS protocol might be more appropriate for some of these tasks. James Galvin pointed out a counter-argument: if DNS management is not done via SNMP, the extended DNS protocol would need to duplicate much of the mechanism of SNMP, including the security features. The Working Group decided to press ahead with cleaning up the 3 DNS MIB, given that we've already spent so much time on it. Next, Susan Thomson gave a presentation on DNS support for PIP. The presentation was basicly the same material covered in the PIP-DNS Internet-Draft (``draft-ietf-pip-dns-00.txt''). The Group discussed three problems with the PIP-DNS proposal: 1. The PIP-DNS proposal creates two new semi-wildcard QTYPEs (the PIP document calls these ``special-purpose query types''). Semi-wildcard QTYPEs have known problems when combined with DNS caching algorithms, as documented in RFC-973, page 4, ``MD and MF replaced by MX''. The Working Group recommended that the PIP Group redesign their proposal to get rid of the semi-wildcard QTYPEs. 2. The proposed BBD (BackBone Descriptor) RR format defined a one-octet field to select the character set used in the variable length text portions of the RR. The Working Group recommended that this be eliminated and that the variable length text portions of the RR be limited to the NETASCII character set. 3. PIP includes a mechanism by which a PIP implementation can know that it needs to get a fresh copy of an RR. The PIP implementors would like to have a way to speed propagation of fresh information when this happens. Discussion of this subject on the Namedroppers list suggests that one way to accomplish this would be the addition of an RR timestamping mechanism to the DNS. To date we do not know how to add such timestamps without an incompatible change to the DNS protocols, so we may not be able to help the PIP implementors here. This issue was left open, due to time pressure at the Working Group meeting. There was a brief discussion of the proposed X.400 ``temporary'' routing mechanism (using the DNS to replace X.400 routing tables). Those members of the Working Group who had read the proposal felt that it was seriously flawed and could not be implemented as specified. Rob Austein and Jon Postel volunteered to meet with the authors of the proposal in order to find the right answer to this problem. Said meeting took place two days later, and resulted in a better solution, to be documented by Claudio Allocchio, one of the authors of the original proposal. At this point, having run out of time and having covered all the major items on the Agenda, the meeting was adjourned. Attendees N. Akiko Aizawa akiko@nacsis.ac.jp Philip Almquist almquist@jessica.stanford.edu Randall Atkinson atkinson@itd.nrl.navy.mil Robert Austein sra@epilogue.com David Battle battle@cs.utk.edu David Bolen db3l@ans.net 4 Erik-Jan Bos erik-jan.bos@surfnet.nl David Bridgham dab@epilogue.com Thomas Brisco brisco@pilot.njin.net Sandy Bryant slb@virginia.edu Henry Clark henryc@oar.net Wayne Clark wclark@cisco.com David Conklin conklin@jvnc.net Stephen Crocker crocker@tis.com John Curran jcurran@nic.near.net Chas DiFatta chas@cmu.edu James Galvin galvin@tis.com Richard Graveman rfg@ctt.bellcore.com Steven Hubert hubert@cac.washington.edu Daniel Karrenberg daniel@ripe.net Frank Kastenholz kasten@ftp.com David Katinsky dmk@pilot.njin.net Kenneth Key key@cs.utk.edu John Klensin klensin@infoods.unu.edu John Linn linn@gza.com Daniel Long long@nic.near.net Steven Lunt lunt@bellcore.com Paul Lustgraaf grpjl@iastate.edu Bruce Mackey brucem@cinops.xerox.com Bill Manning bmanning@sesqui.net Clifford Neuman bcn@isi.edu William Nowicki nowicki@legato.com Masataka Ohta mohta@cc.titech.ac.jp Andrew Partan asp@uunet.uu.net Brad Passwaters bjp@sura.net Michael Patton map@bbn.com John Penners jpenners@advtech.uswest.com Jon Postel postel@isi.edu Robert Reschly reschly@brl.mil John Romkey romkey@asylum.sf.ca.us Jon Saperia saperia@lkg.dec.com Carl Schoeneberger 70410.3563@Compuserve.com Tim Seaver tas@concert.net Allyson Showalter allyson@nsipo.arc.nasa.gov Michael St. Johns stjohns@darpa.mil Martha Steenstrup msteenst@bbn.com Bernhard Stockman boss@ebone.net Susan Thomson set@bellcore.com L. Stuart Vance vance@tgv.com Ruediger Volk rv@informatik.uni-dortmund.de Chuck Warlick warlick@theophilis.nsfc.nasa.gov Jane Wojcik jwojcik@bbn.com 5