Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/dns/dns-minutes-93nov.txt

Text File | 1994-02-08 | 12KB | 268 lines

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
[e-mail]; requests to subscribe should be sent to
[e-mail].

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          [e-mail]
Garrett Alexander        [e-mail]
Robert Austein           [e-mail]
Anders Baardsgaad        [e-mail]
Alireza Bahreman         [e-mail]
William Barns            [e-mail]
Stephen Crocker          [e-mail]
Donald Eastlake          [e-mail]
Havard Eidnes            [e-mail]
Erik Fair                [e-mail]
Roger Fajman             [e-mail]
Patrik Faltstrom         [e-mail]
Antonio Fernandez        [e-mail]
James Fielding           [e-mail]
James Galvin             [e-mail]
Chris Gorsuch            [e-mail]
Ronald Jacoby            [e-mail]
Rick Jones               [e-mail]
Charlie Kaufman          [e-mail]
Elizabeth Kaufman        [e-mail]
Stephen Kent             [e-mail]
Edwin King               [e-mail]
Paul Lambert             [e-mail]
Walter Lazear            [e-mail]
Lars-Johan Liman         [e-mail]
John Linn                [e-mail]
Jun Matsukata            [e-mail]
Paul Mockapetris         [e-mail]
Sath Nelakonda           [e-mail]
Masataka Ohta            [e-mail]
Michael Patton           [e-mail]
Jon Postel               [e-mail]
Jeffrey Schiller         [e-mail]
Richard Schmalgemeier    [e-mail]
Michael St.  Johns       [e-mail]
John Stewart             [e-mail]
Theodore Ts'o            [e-mail]
Walter Wimer             [e-mail]
David Woodgate           [e-mail]
Weiping Zhao             [e-mail]