[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                              B. Woodcock
INTERNET-DRAFT                                                    Zocalo
Expires February 2001                                         B. Manning
draft-manning-dnsext-mdns-00.txt                                     ISI
                                                             August 2000


                   Multicast Domain Name Service


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.


Abstract

   This document describes a method by which DNS resolvers may reach
   multicast-capable DNS servers which may exist within a multicast
   local scope, by issuing a single UDP query to a static multicast
   address.


Acknowledgments

   Vital contributions to this document were made by Erik Guttman, Paul
   Vixie, Dave Meyer, David Conrad, Andreas Gustafsson, Stuart
   Cheshire, Richard Ford, Tony McGregor, Stuart Kwan, Alex Hoppman and
   Peter Ford.


Woodcock & Manning                                             [Page 1]


INTERNET-DRAFT       Multicast Domain Name Service         August, 2000


Overview and rationale

   The addition of multicast capability into the DNS protocol will
   facilitate retirement of legacy protocols such as AppleTalk and
   NetBIOS and may enable the development of new methods of service
   location and ZeroConf bootstrapping.


Discussion

   This extension to the DNS protocol consists of a single change to the
   method of use, and no change whatsoever to the current format of DNS
   packets.  Specifically, this extension allows UDP DNS queries, as
   documented in RFC 1035, sections 4.1.1, 4.1.2 and 4.2.1, to be
   addressed to port 53 of statically-assigned relative offset -4 within
   the range of multicast addresses defined as "administratively scoped"
   by RFC 2365, section 9.  Within the full /8 of administratively
   scoped addresses, this corresponds to the destination address
   239.255.255.251.  Until MZAP or a similar protocol is implemented to
   allow hosts to discover the extent of the local multicast scopes
   which enclose them, it is anticipated that implementations will
   simply utilize the destination address 239.255.255.251.  Queries
   sent via multicast MUST NOT request recursion.

   In order to receive multicasted queries, DNS server implementations
   MUST listen on the -4 offset to their local scope (as above, in the
   absence of a method of determining the scope, this will be assumed to
   be relative to the full /8 allocated for administratively-scoped
   multicast use, or 239.255.255.251), and respond via ordinary unicast
   UDP to ONLY those queries for which they have a positive
   answer which originated within a locally-configured zone file.  That
   is, a server MUST NOT answer a multicasted query with cached
   information which it received from another server, nor may it request
   further resolution from other servers on behalf of a multicasted
   query.  A multicast-capable server may, however, utilize multicast
   queries to perform further resolution on behalf of queries received
   via ordinary unicast.  This is referred to as "proxy" operation.
   Multicast-enabled DNS servers MUST answer multicasted queries
   non-authoritatively.  That is, when responding to a query which was
   received via multicast, they MUST NOT include an NS record which
   contains data which resolves back to their own IP address and MUST
   NOT set the AA bit.

   Resolvers MUST anticipate receiving no replies to some multicasted
   queries, in the event that no multicast-enabled DNS server
   implementations are active within the local scope, or in the event
   that no positive responses exist to the transmitted query.
   That is, a query for the MX record for host.domain.com would go
   unanswered if no local server was able to resolve that request, if no
   MX record exists for host.domain.com, or if no local servers were
   capable of receiving multicast queries.  The resolver which initiated


Woodcock & Manning                                             [Page 2]


INTERNET-DRAFT       Multicast Domain Name Service         August, 2000


   the query MUST treat such non-response as a non-cacheable negative
   response.  Since this multicast transmission does not provide
   reliable delivery, resolvers MAY repeat the transmission of a query
   in order to assure themselves that is has been received by any hosts
   capable of answering, however any resolvers which repeat a query MUST
   increase the interval by a factor of two between each repetition.  It
   is more likely, however, that any repeated queries will be performed
   under the explicit direction of the application driving the query,
   rather than autonomously by the resolver implementation.

   It will often be the case that multicast queries will result in
   responses from multiple servers.  In the event that the multicast
   query was generated via a current API such as gethostbyname, or as
   the result of a proxy operation, the first response received must be
   passed to the requesting application or host, and all
   subsequently-received responses must be discarded.  Future
   multicast-aware APIs should anticipate receiving multiple
   independent RR-sets in response to queries.


Security Considerations

   While this extension to DNS introduces no known security problems to
   DNS or Multicast, it should be emphasized that distributed
   directories, common to other networking protocols, have not hitherto
   been widely used in the IP networking community.  Distributed
   directories do require that users and system administrators assume
   some conscious balance between the level of trust which they accord
   to the responding entities on their network, and the degree of
   credence which they pay to the responses they receive.


References

   RFC 1034: Mockapetris, P., "Domain Names - Concepts and
        Facilities", RFC 1034, November, 1987.

   RFC 1035: Mockapetris, P., "Domain Names - Implementation and
        Specification", RFC 1035, November, 1987.

   RFC 2052: Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the
        location of services (DNS SRV)", RFC 2052, October, 1996.

   RFC 2365: Meyer, D., "Administratively Scoped IP Multicast",
        RFC 2365, July, 1998.

   Handley, M., Thaler, D., "Multicast-Scope Zone Announcement
        Protocol (MZAP)", MBoneD Internet Draft, October, 1998.

   Sidhu, G.S., Andrews, R.F., and Oppenheimer, A., "Inside AppleTalk,
        Second Edition", Addison-Wesley, 1990.


Woodcock & Manning                                             [Page 3]


INTERNET-DRAFT       Multicast Domain Name Service         August, 2000


Authors' Addresses

   Bill Woodcock
   Zocalo
   2355 Virginia Street
   Berkeley, CA  94709-1315
   USA

   Phone: +1 510 540 8000
   EMail: woody@zocalo.net


   Bill Manning
   USC/ISI
   4676 Admiralty Way, #1001
   Marina del Rey, CA. 90292
   USA

   Phone: +1 310 822 1511
   EMail: bmanning@isi.edu


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared, copied,
   published and distributed, in whole or in part, without
   restriction of any kind, provided that the above copyright notice
   and this paragraph are included on all such copies and derivative
   works.  However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to the
   Internet Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which case the
   procedures for copyrights defined in the Internet Standards
   process must be followed, or as required to translate it into
   languages other than English.

   The limited permissions granted above are perpetual and will not
   be revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on
   an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.









Woodcock & Manning                                             [Page 4]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/