draft-manning-multicast-dns-02.txt

bind-3.2.

Network Working Group                                        B. Woodcock
Request for Comments: nnnn                                        Zocalo
Category: Experimental                                        B. Manning
                                                                     ISI
                                                             August 2000


                Multicast Discovery of DNS Services
                  draft-manning-multicast-dns-02.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026 except that the right 
   to produce derivative works is not granted.  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."

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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

1. Introduction

   This document describes a minimal extension to the method of a DNS
   query which allows unconfigured hosts to locate a local DNS server,
   or in the absence of a DNS server to nonetheless identify some
   local network services.

2. Acknowledgments

   Vital contributions to this document were made by Paul Vixie, Dave
   Meyer, Stuart Cheshire, Richard Ford, Tony McGregor, Erik Guttman,
   Benard Aboba, and Peter Ford.  Thanks also to Alex Hoppman for
   discussion of text-encoding methods.
   
3. Overview and rationale

   This experimental extension to DNS is intended to provide a bootstrap
   mechanism whereby unconfigured devices may find a local DNS server
   and begin using it to perform the usual name resolution and service
   lookup functions.  This need is particularly acute in the absence of
   a DHCP server.
   
   Secondarily, it is anticipated that device vendors may implement the
   server (query-receiving) portion of this extension, in order to
   render unconfigured devices which may lack an out-of-band
   configuration interface such as a screen or keyboard discoverable on
   the local network.  For example, if a newly-purchased laser printer
   or router were connected to a network, this extension would allow a
   system administrator to use the DNS to discover the IP address which
   the device had selected or been DHCP-assigned, and begin
   communicating with it through the network.
   
   A tertiary objective of this extension is to make possible the
   deprecation of the AppleTalk protocol, which has been prolonged as a
   means of providing support for "network browsing."

4. 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 -2 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.253.  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.253.
   
   In order to receive multicasted queries, DNS server implementations
   MUST listen on the -2 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.253), and respond via ordinary unicast
   UDP to ONLY those queries for which they have or can find a positive
   non-null answer.  Multicast-enabled DNS servers MUST answer
   multicasted queries non-authoritatively.  That is, when responding to
   a query which was received via multicast, they MAY NOT include an NS
   record which contains data which resolves back to their own IP
   address.

   Resolvers SHOULD be liberal in their acceptance of wildcard queries.
   That is, resolvers should anticipate receiving queries which will
   contain the asterisk character in any position within the query's
   data field. For example, a query for SRV RRs with data
   "afp.tcp.*.domain.com." would match "afp.tcp.server.domain.com." but
   not match "afp.tcp.".  A query for "afp.tcp.*" would match both,
   since the asterisk should be interpreted as matching zero or more
   characters within the RR data.
   
   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 non-null 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
   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 reveived by any hosts
   capable of answering, however any resolvers which repeat a query MUST
   increase the interval between such repetitions exponentially over
   time.
   
   Resolvers MUST also anticipate receiving multiple replies to the same
   multicasted query, in the event that several multicast-enabled DNS
   servers receive the query and respond with valid answers.  When this
   occurs, the responses MAY first be concatenated, and then treated in
   the same manner that multiple RRs received from the same server
   would, ordinarily.


5. Implementation Notes Appendix
   
   It is anticipated that a major use of this extension to DNS will be
   for the replacement of the AppleTalk Name Binding Protocol (NBP)
   "distributed database," and the implementation of a similar service
   within other operating systems and on other platforms.  Such use
   implies the existence of "stub DNS servers" on each participating
   host, each containing only local information in its served zones, but
   not to the exclusion of data which other servers may assert within
   the same zones.
   
   The following rather complex example shows the format by which an
   implementor could assert the local information possessed by any
   Macintosh in zones served by a stub DNS server on that host:

      $ORIGIN .
      @ SOA . . 1998082701 0 0 0 0
                           0  IN  NS     dns.udp.
      Jasons-Mac           0  IN  A      169.254.101.218
                           0  IN  HINFO  Macintosh-G3-400  MacOS-8.6
                           0  IN  LOC    37 52 N 122 20 W
                           0  IN  RP     .  owner-name.Jasons-Mac.
      Jasons-Hard-Disk     0  IN  A      169.254.101.218
                           0  IN  TXT    "UTF8-encoded service-name"
      Print-Spooler        0  IN  A      169.254.101.218
                           0  IN  TXT    "UTF8-encoded service-name"
      dns.udp              0  IN  SRV    0 0 53    Jasons-Mac.
      afp.tcp              0  IN  SRV    0 0 548   Jasons-Hard-Disk.
      lpr.tcp              0  IN  SRV    0 0 515   Print-Spooler.
      http.tcp             0  IN  SRV    0 0 80    www.jasonco.com.
      https.tcp            0  IN  SRV    0 0 443   secure.jasonco.com.
   
      $ORIGIN jasonco.com.
      www                  0  IN  A      169.254.101.218
                           0  IN  TXT    "UTF8-encoded service-name"
      secure               0  IN  A      169.254.101.218
                           0  IN  TXT    "UTF8-encoded service-name"
   
      $ORIGIN Jasons-Mac.
      dns.udp              0  IN  SRV    0 0 53    Jasons-Mac.
      owner-name           0  IN  TXT    "Jason A. Luser"
      *                    0  IN  PTR    afp.tcp.Jasons-Mac.
                           0  IN  PTR    lpr.tcp.Jasons-Mac.
                           0  IN  PTR    http.tcp.Jasons-Mac.
      afp.tcp              0  IN  SRV    0 0 548   Jasons-Hard-Disk.
      lpr.tcp              0  IN  SRV    0 0 515   Print-Spooler.
      http.tcp             0  IN  SRV    0 0 80    www.jasonco.com.
   
      $ORIGIN 101.254.169.in-addr.arpa.
      218                  0  IN  PTR    Jasons-Mac.

   Windows and Unix hosts are possessed of many of the same, or
   analogous, types of local information, and similar examples could be
   constructed around hypothetical hosts of those types.  A much 
   simpler example featuring a laser printer follows, in section 6 of
   this document.

   Note that in translating service and device names from high-bit-depth
   character sets such as Unicode to DNS-compliant hostnames, a
   character-mapping must occur, whereby spaces are mapped to hyphens,
   punctuation other than periods is removed, and plain characters are
   substituted for their accented equivalents. Implementors MUST perform
   a uniqueness check, in order to guarantee that no other device within
   the local multicast scope has already asserted a claim to the DNS
   name which their device wishes to employ.  Uniqueness checks at
   service-registration time must be somewhat more strict than their
   historical AppleTalk equivalents, comparing names which have already
   been converted to their DNS-compliant state (containing only a-z,
   A-Z, 0-9, and the hyphen character, and starting with a letter rather
   than a hyphen or number), and must treat upper and lower-case as
   equivalent.  Note that periods in device and service names shall be
   preserved and used to establish subdomains within the stub DNS
   server's dataset.  The high-bit-depth names are made available to
   queriants in the form of UTF8-encoded RDATA in TXT RRs included as
   Additional Information (as described in RFC 1035, sections 4.1
   through 4.1.3) appended to any A RR response.