diff options
Diffstat (limited to 'doc/dns-minutes-93nov.txt')
| -rw-r--r-- | doc/dns-minutes-93nov.txt | 267 |
1 files changed, 0 insertions, 267 deletions
diff --git a/doc/dns-minutes-93nov.txt b/doc/dns-minutes-93nov.txt deleted file mode 100644 index aa028020..00000000 --- a/doc/dns-minutes-93nov.txt +++ /dev/null @@ -1,267 +0,0 @@ - -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 - |