CURRENT_MEETING_REPORT_ Reported by Rob Austein/Epilogue Technology Minutes of the Domain Name System Working Group (DNS) Documents Three new DNS-related Informational RFCs have come out recently. RFC 1535 (also known as ``the EDU.COM emergency RFC'') details problems with a widely-used but ill-advised DNS search heuristic, and proposes a solution. RFC 1536 details common DNS implementation errors, with proposed solutions; this document was accepted as a DNS Working Group project at the 27th IETF (Amsterdam), completed, and accepted on the mailing list. RFC 1537 details common DNS configuration errors; while it was never formally accepted as a DNS Working Group document, it was reviewed by the working group members. These three RFCs are closely related and cross-reference each other, so, on advice of the RFC Editor, the DNS Working Group Chair approved ``fast track'' publication of these documents on behalf of the Working Group. If anybody has serious problems with these documents, blame it on the Chair. Dave Perkins reported on the current status of the DNS MIB documents on behalf of the Network Management Area Directorate (NMDIR). Basically, there are no remaining hard problems, just some remaining detail work. One of the authors, Rob Austein, has received a detailed list of remaining concerns, none of which appear to be show-stoppers. It should be possible to get these documents out the door before the 29th IETF in Seattle. Dave pointed out two design issues that are not objections but of which he thinks the DNS Working Group should be aware: 1. Due to SNMP protocol limitations, the length limits on DNS names used as indices to ``conceptual tables'' in the MIBs will be shorter than the DNS name length limit of 255 octets. Based on analysis of current usage, this should not be a problem, so we'll flag it with a warning statement in the document but otherwise leave it alone. 2. The most recent versions of the documents (not yet released as Internet-Drafts) use the SNMPv2 SMI rather than the SNMPv1 SMI, in order to clear up some problems with unsigned 32-bit integers. NMDIR wants to be sure that the DNS Working Group realizes that this means only SNMPv2-capable implementations will be able to use these MIBs. DNS Security Sub-Group James Galvin gave a report on the meeting held by the DNS Security ``sub-group'' (a spin off from the DNS Working Group at the 26th IETF in Columbus). The DNS Security design team of the DNS Working Group met for one morning at the Houston IETF. The discussion began with a call for threats that the members of the group were most concerned about. The list included the following: o disclosure of the data - some expressed a desire to be able to encrypt the data in responses o modification of the data o masquerade of the origin of the data o masquerade of a secondary - some expressed a desire to be able to reliably identify both peers in a zone transfer; this would provide the basis for controlling access to zone transfers During the discussion of these threats it was agreed to accept the following assumptions: 1. DNS data is ``public'' 2. backward/co-existence compatibility is required With respect to the first, accepting it set aside any further discussion of the threat of disclosure of the data. The second assumption is included explicitly to remind everyone that we do not want parallel DNS systems in the Internet. In addition, it was explicitly agreed that we would not address authentication of secondaries or access control issues. Thus, the current list of desired security services is: o data integrity o data origin authentication It was noted that a digital signature mechanism would support the desired services. The meeting continued with a brainstorming period during which the desired functional requirements of a secure DNS were collected. This list does not represent mandatory functionality but, rather, it is desired functionality. It was agreed that this list was subject to discussion on the mailing list for a period of time that would conclude on November 30. The requirements are listed here in no particular order. o sites must be able to support at least their internal users in the presence of external network failures o it should be possible for a site to pre-configure other authoritative servers without having to query the ``system'' to find the server o it should be possible to request services only from security enhanced servers, only from non-security enhanced servers, or to indicate that either is acceptable o it should be possible to recognize security enhanced responses o it should be possible to assign cryptographic keys (make use of the security services) to leaf nodes in the DNS tree, i.e., fully qualified domain names o it should be possible to not trust secondary servers o a mechanism must exist for revoking cryptographic keys that works within the DNS time-to-live framework o security services should be supported with no additional DNS queries beyond what would be required if security was not supported o it must be possible to ensure that cached data expires according to its TTL The meeting concluded with agreement on the following three milestones. 1. The desired functional requirements are to be reviewed and agreed upon by November 30. 2. Strawman proposals that meet as many of the desired requirements as possible are due by January 31, 1994. 3. The group would produce a single, draft proposal at the next IETF meeting, March 1994. The DNS Security effort will be spun off as a separate working group in the Service Applications Area (SAP), as soon as James can get the charter approved. The DNS Security mailing list is dns-security@tis.com; requests to subscribe should be sent to dns-security-request@tis.com. Discussion of the incremental zone transfer protocol (draft-ietf-dns-ixfr-00.txt) was deferred because none of the authors were present at the meeting. Comments on this draft should be sent to the authors and/or the Namedroppers mailing list. DNS Efforts to Support SIPP Sue Thomson gave a brief report on current DNS efforts to support SIPP (the merger of the SIP and PIP proposals). See the latest version of the Internet-Draft, draft-ietf-sip-sippdns-nn.txt, for details. DNS Reliability Issues - Boeing Ed King gave a presentation on DNS reliability issues in Boeing's production environment. Ed has to support DNS on a corporate network with thousands of subnets and DNS software from many vendors in a production environment that never shuts down and where an interruption to DNS services due to a power hit can leave hundreds of engineers sitting idle waiting for their workstations to finish booting. Much of the problem is that each vendor has their own slightly different (and often more than slightly broken) interface between DNS, local host tables, and the vendor's own pet name resolution mechanism. Replacing or repairing all the DNS software in an environment isn't economically feasible, so the most constructive approach seems to be to write a ``DNS Requirements'' document to use as a reference when pressuring vendors to fix their DNS implementations. The DNS portion of the Host Requirements documents (RFC 1123 section 6.1) and the newly published DNS ``Common Errors'' Informational RFCs are good starting points, but companies like Boeing need a document that has the force of a standard and that goes into more detail on interface design issues than Host Requirements does. No definite decision was reached as a result of Ed's presentation, but watch Namedroppers for further discussion and probably a call to form a working group. DNS Support for DHC and Mobile Hosts Masataka Ohta gave a presentation on a possible way to implement some of the DNS support needed for dynamic host configuration and mobile hosts. The presentation went into more detail than there is room for in these minutes, so expect to see a summary of this on the Namedroppers list. The Future of the DNS Working Group Dave Crocker spoke about the future of the DNS Working Group. As has been discussed at previous meetings, the DNS Working Group as currently organized doesn't really fit well into the current IETF organizational framework. Accordingly, Dave asks that DNS reorganize itself more along the current IETF pattern. The proposal is to move the ``permanent'' functions of the DNS Working Group (DNS oversight within the IETF, mostly) into the SAP Area Directorate, that Dave will be forming ``Real Soon Now,'' while reincarnating specific closed-ended tasks as separate working groups within the SAP Area. The SAP Area Directorate will hold open meetings at regular intervals, so that there will still be a forum for overall DNS design work. For formal purposes, the current DNS Working Group will probably be retroactively construed as having been the DNS MIB Working Group, and will be closed down as soon as the DNS MIB documents hit the streets. As a practical matter, and in the Chair's opinion, the current DNS Working Group will effectively reconstitute itself as the attendees of the DNS portion of the SAP Area Directorate open meetings. Dave expects to have the reorganization completed by the 29th IETF in Seattle. The discussion that followed Dave's statement made it clear that there are people with strong feelings on both sides of this issue (keep the DNS Working Group as it is versus reorganize per Dave's plan). Unless somebody feels strongly enough about this to make a formal appeal, the reorganization will probably go through. Attendees Steve Alexander stevea@lachman.com Garrett Alexander gda@tycho.ncsc.mil Robert Austein sra@epilogue.com Anders Baardsgaad anders@cc.uit.no Alireza Bahreman bahreman@bellcore.com William Barns barns@gateway.mitre.org Stephen Crocker crocker@tis.com Donald Eastlake dee@skidrow.lkg.dec.com Havard Eidnes havard.eidnes@runit.sintef.no Erik Fair fair@apple.com Roger Fajman raf@cu.nih.gov Patrik Faltstrom paf@nada.kth.se Antonio Fernandez afa@thumper.bellcore.com James Fielding jamesf@arl.army.mil James Galvin galvin@tis.com Chris Gorsuch chrisg@lobby.ti.com Ronald Jacoby rj@sgi.com Rick Jones raj@cup.hp.com Charlie Kaufman kaufman@zk3.dec.com Elizabeth Kaufman kaufman@biomded.med.yale.edu Stephen Kent kent@bbn.com Edwin King eek@atc.boeing.com Paul Lambert paul_lambert@email.mot.com Walter Lazear lazear@gateway.mitre.org Lars-Johan Liman liman@ebone.net John Linn linn@security.ov.com Jun Matsukata jm@eng.isas.ac.jp Paul Mockapetris pvm@darpa.mil Sath Nelakonda sath@lachman.com Masataka Ohta mohta@cc.titech.ac.jp Michael Patton map@bbn.com Jon Postel postel@isi.edu Jeffrey Schiller jis@mit.edu Richard Schmalgemeier rgs@merit.edu Michael St. Johns stjohns@arpa.mil John Stewart jstewart@cnri.reston.va.us Theodore Ts'o tytso@mit.edu Walter Wimer walter.wimer@andrew.cmu.edu David Woodgate David.Woodgate@its.csiro.au Weiping Zhao zhao@nacsis.ac.jp