draft-manning-multicast-dns-02.txt

bind-3.2.

   Implementors of multicast-enabled resolvers may expect the following
   results of the following query-types:

      Data                Type  Result
      
      *.in-addr.arpa      PTR   All hostnames in the local scope
      *.host.domain.com   SRV   All services on host.domain.com
      lpr.tcp.            SRV   All printers/spoolers in the local scope

   Duplicate identical records received in different responses to a
   query may be treated as a single record in the concatenation of
   responses.  It is beyond the scope of this document to suggest
   disposition of different responses which contain disagreeing pairs of
   name NAME and RDATA.

   Implementors should note that "virtual hosts" (that is, the support
   of multiple IP addresses on a single host, and the binding of
   different services to different addresses) are easily supported in
   responses to multicast queries, but should also note that one of the
   benefits afforded by the use of SRV RR-types is a reduction in the
   need for virtual hosts, since multiple named services may be bound to
   different (non-well-known) ports of the same IP address, and still be
   individually identified and differentiated.  For example, a single
   host might support one HTTP server on port 80, a second on port 8001,
   and an HTTPS server on port 443, and each could be reached via
   different name.

   Another major use of this extension to DNS is to allow bootstrapping
   machines to find local DNS servers.  It is anticipated that larger
   enterprises may in the future possess one or more fully-featured DNS
   servers which are also multicast-enabled.  Once a bootstrapping host
   has located such a server, that host need no longer use multicast at
   all.  That host may instead employ ordinary unicast DNS exactly as
   any other host would, to query those DNS servers. The servers, in
   turn, might well employ multicast queries to glean information about
   the services contained within their local scope, which information
   they might then use to respond to unicast queries (proxying, in
   effect), and cache against future need.  Note also that the ability
   to answer multicast queries would prove particularly useful to a DNS
   server which was resident on the same host as a NAT at the border of
   an enterprise which employed 10.0.0.0/8 or 169.254.0.0/16 unicast
   addresses internally.

   Implementors MAY choose to employ an optimization whereby the
   deleterious impact of large numbers of unconfigured hosts
   simultaneously attempting to locate DNS servers during the bootstrap
   process might be mitigated, and the process be made more efficient.
   Specifically, high- and low-water marks are defined for frequency of
   multicasted lookups for SRV RRs of "dns.udp.". When a
   multicast-enabled DNS server observes the frequency of such lookups
   exceeding a high-water mark (five queries per minute, perhaps), the
   server MAY begin interspersing responses transmitted via multicast,
   rather than unicast, until such time as the frequency of such lookups
   falls below a low-water mark (one query per five minutes, perhaps).
   In order for this to work, multicast-enabled resolvers would also
   need to listen on the multicast address for responses, and cache them
   briefly.  Both the server and resolver portions of this optimized
   behavior are optional, and it should be stressed that this
   optimization need not be considered by implementors of stub servers
   in devices such as printers, which do not provide generalized DNS
   services.   If DNS server implementors choose to employ multicast
   responses, they MUST interleave multicast responses with unicast
   responses in such a way that the multicast responses decrease over
   time, rather than flooding the network, in order that servers not be
   used to propagate denial-of-service attacks.  In other words, a
   reasonable approach might be while above the high-water mark to make
   the first, second, fourth, eighth, sixteenth et cetera responses for
   each RR multicast, while all inbetween would be unicast.  Note that
   this not only protects against multicast "storms," it also protects
   against the mis-match condition which occurs in the case that a
   non-optimized resolver is the presence only of optimized servers, all
   of which are temporarily in multicast-response mode.

   Implementors SHOULD also employ DNS Sec, or its equivalent, as soon
   as such technology is standardized, in order to minimize the
   possiblity of "spoofing" of information by nodes responding to
   multicast queries.


6. Use & Administration Notes Appendix

   Administrators of networks employing this protocol are advised to
   employ fully-qualified domain names (FQDNs) as their host names where
   possible, such that the dots separating portions of the name shall be
   interpreted by the stub-server implementations as subdomain
   delimiters, and shall thus serve to remove the host from the local
   view of the root domain to its correct and appropriate
   globally-unique subdomain.

   Administrators of service-providing devices, such as already-deployed
   printers, which are not capable of receiving multicast DNS queries,
   may wish to inject DNS records into a local multicast-enabled DNS
   server on behalf of those devices.  For example, an administrator
   might wish to create records of the following nature in order to make
   a non-multicast-capable laser printer visible to both multicast and
   unicast queriants:
   
      $ORIGIN .
      lpr.tcp           0  IN  SRV    0 0 515   laser2.sales.domain.com.
   
      $ORIGIN sales.domain.com.
      laser2            0  IN  A      169.254.5.28
                        0  IN  TXT    "Old Sales Dep't Laser Printer"
   
      $ORIGIN laser2.sales.domain.com.
      *                 0  IN  PTR    lpr.tcp.laser2.sales.domain.com.
      lpr.tcp           0  IN  SRV    0 0 515   laser2.sales.domain.com.
   
      $ORIGIN 5.254.169.in-addr.arpa.
      28                0  IN  PTR    laser2.sales.domain.com.

   Administrators of networks which contain either multicast-capable
   resolvers or multicast-capable DNS servers MUST employ filters
   defining a contiguous border around their enterprises and prohibiting
   passage of data to and from the 239.0.0.0/8 address space, as well as
   routing information relating to the 239.0.0.0/8 prefix or any subnet
   of it.  This is the mechanism by which RFC 2365 administrative
   scoping is enacted.  The sole exception to this rule would be any
   explicitly-configured interconnections with other specific
   enterprises between which all involved administrators wish to share a
   single browsable network space. This is anticipated to be a very
   infrequent occurrence within the current regime of network security
   policies.

References

   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.
         
Security Considerations

   While this extension to DNS introduces no new 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.  The level of
   trust traditionally assumed in distributed directory environments
   does not necessarily mix well with clear-text password transmission
   such as is still found on some IP networks, for example.


Authors' Addresses

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

   Phone: [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   EMail: [e-mail]

Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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

......

--------------1F985EC911030AB70E0CD7B9--



-- 
--bill