Network Working Group                                       Bill Manning
draft-manning-opcode-discover-02.txt                              ep.net
Expires: May 2006                                             Paul Vixie
                                                                     ISC
                                                        16 November 2005


                 DISCOVER: Supporting Multicast DNS Queries

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on XXXXXX.

   Distribution of this memo is unlimited.

Abstract

   This document describes the DISCOVER opcode, an experimental
   extension to the Domain Name System (DNS) to use multicast queries
   for resource discovery.  A client multicasts a DNS query using the
   DISCOVER opcode and processes the multiple responses that may
   result.

1. Introduction

   In the standard Domain Name System (DNS) [3] [4], queries are always
   unicast using the QUERY opcode.  The TBDS research project, funded
   under DARPA grant F30602-99-1-0523, explored the use of multicast
   DNS [3][4] queries for resource discovery.  Multicast queries may
   return multiple replies, while the standard DNS QUERY operation [5]
   expects a single reply.  Instead of extending the QUERY
   opcode, the project developed and tested a new query operation,
   DISCOVER, that is designed to accommodate multiple responses from a
   multicast query.  This memo documents the processing rules for
   DISCOVER, for possible incorporation in a future revision of the DNS
   specification.

2. DISCOVER Processing Rules

   A requester will send a DISCOVER query message to a multicast
   destination address, with some particular multicast scope.  The
   requester must be prepared to receive multiple replies from multiple
   responders, although we expect that there will be a single reply
   per responder.

   DISCOVER responses (i.e., response messages from DISCOVER queries)
   have standard Answer, Authority, and Additional sections.  For
   example, the DISCOVER response is the same as the response to a
   QUERY operation.  Zero-content answers should not be sent, to avoid
   badly formed or unfulfilled requests.  Responses should be sent to
   th unicast address of the requester, and the source address should
   reflect the unicast address of the responder.  DISCOVER responses
   may echo the request's Question section or leave it blank, just as
   for QUERY.

   DISCOVER works like QUERY, except:

	1. The Question section of a DISCOVER operation contains
	   <QNAME=zonename,QTYPE=SOA> tuples, if the section is
           present.

 	   Within TBDS, this structure was augmented with:
	   <QNAME=service,QTYPE=SRV>.  While this worked, it would be
	   cleaner to ask the SRV question in a separate pass, and any
	   future work should take this into consideration.

        2. If QDCOUNT equals 0, then only servers willing to do recursion
	   should answer; other servers must silently discard a DISCOVER 
           request with QDCOUNT equals 0. 

        3. if QDCOUNT is not equal to 0, then only servers that are 
	   authoritative for the zones named by some QNAME should answer.

     Hence, replies to DISCOVER queries will always be authoritative or
     else have RA (Recursion Available) set.

3. Using DISCOVER Queries

3.1  Performing Host Lookups

   To perform a hostname lookup using DISCOVER, a node could:

     o  Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
        ip6.arpa domain.

     o  DISCOVER whether any in-scope server(s) are authoritative for
        this zone.

                If so, query these authoritative servers for local
                in-addr/ip6 names.

     o  If not, DISCOVER whether there are recursive servers available.

                If so, query these recursive servers for local
                in-addr/ip6 names.

        The requester can determine from the replies whether there are
	any DNS servers that are authoritative (or support recursion)
	for the zone.

     o  Once the host's FQDN is known, repeat the process to
        discover the closest enclosing authoritative server for
        this local name.

     o  Cache all NS and A data learned in this process, respecting TTL's.

3.2 Performing Service Lookups

   To lookup a service name using DISCOVER, the following steps may be
   used:

     o  Use DISCOVER as outlines in Section 3.1 to perform
	gethostbyaddr() and then gethostbyname() on one's own
	link-local address.  This gives a list of local authoritative
        servers.

     o  Assume that the closest enclosing zone for which an
        authoritative server responds to an in-scope DISCOVER message is
        this host's "parent domain", and compute the SRV name as

	       _service._transport.*.parentdomain.

	This is a change to the definition as defined in RFC 1034 [3].
	A wildcard label ("*") in the QNAME used in a DNS message with
	op-code DISCOVER should be evaluated with special rules: the
	wildcardshould match any label for which the DNS server data is
	authoritative.  For example 'x.*.example.com.' would match
	'x.y.example.com.' and 'x.yy.example.com.', provided that the
	server was authoritative for 'example.com.'

     o  Finally, send a SRV query for this SRV name to the discovered
        local authoritative servers, to complete the getservbyname() call.
        
	This call returns a structure that can be populated by response
	values, as follows:

        s_name    The name of the service, "_service" without the
                  preceding underscore.

        s_aliases The names returned in the SRV RRs in replies
                  to the query.

        s_port    The port number in the SRV RRs replies to the
                  query.  If these port numbers disagree - one
                  of the port numbers is chosen, and only those
                  names which correspond are returned.

        s_proto   The transport protocol from named by the
                  "_transport" label, without the preceding
                  underscore.


3.3  Using DISCOVER for Disconnected Names

   DISCOVER allows discovery of a host (for example, a printer offering
   LPD services) whose DNS server answers authoritatively for a domain
   name that hasn't been delegated to it, but is defined within some
   local scope.  Since DISCOVER is explicitly defined to discover
   undelegated zones for tightly-scoped queries, this behavior isn't a
   violation of DNS's coherency principles.   Note that a responder to
   DISCOVER might not be traditional DNS software, it could be
   special-purpose software.

   DISCOVER usage for disconnected networks with no authoritative
   servers can be achieved using the following conditions.

          o Hosts run a "stub server" that acts as though its FQDN
            were a zone name.

          o The computed SOA gives the host's FQDN as the MNAME, "." as
	    the ANAME, seconds-since-1Jan2000 as the SERIAL, and low
	    constants for EXPIRE and the other SOA timers.

          o  NS is used as the host's FQDN.

          o  The glue is computed as the host's link-local address, or
 	     hosts may run a  "DNS stub server" that acts as though its
	     FQDN were a zone name.
        
   The rules governing the behavior of this stub server are given 
   elsewhere [1] [2].

   Such stub servers should answer DISCOVER packets for its zone, and
   will be found by the iterative "discover closest enclosing authority
   server" by DISCOVER clients, in either the gethostbyname() or SRV
   cases described above.  Note that stub servers answer only with
   zone names which exactly match QNAME's, not with zone names which
   are owned by QNAME's.

4. IANA Considerations

   The IANA will need to assign a numeric value for the DISCOVER opcode.

5. Security Considerations

   No new security considerations are known to be introduced with a new
   DNS query operation.  However, using multicast for service discovery
   has the potential for denial of service from flooding attacks.  It
   may also be possible to enable deliberate misconfiguration of
   clients simply by running a malicious DNS server that falsely claims
   to be authoritative for delegations.  One possible way to mitigate
   this threat is to use credentials, such as CERT resource records
   within an RR set.  The TBDS project took this approach.  TBDS did
   not directly utilize DNSSEC and so possible interactions with
   DNSSEC aware/capable servers are unknown.

6. Acknowledgments

   This material was generated in discussions on the mdns maili
   list hosted by Zocalo in March 2000 and updated by discussions in 	
   September/October 2003 on a closed mailing list.  David Lawrence, 
   Scott Rose, Stuart Cheshire, Bill Woodcock, Erik Guttman were 
   active contributors. Suzanne Woolf was part of the original
   implementation team and an invaluable sanity checker.

7. References

[1]  Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
        Work in Progress, November 2000.

[2]  Woodcock, B., Manning, B., "Multicast Domain Name Service",
        Work in Progress, August 2000.

[3]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
        RFC 1034, November 1987.

[4]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
        RFC 1035, November 1987.

[5]  QUERY opcode -- defined in section 3.7, 4.3, and section 5 of RFC
	1034 and in section 4.1.1 of RFC 1035.


Authors' Addresses

   Bill Manning
   PO 12317
   Marina del Rey, CA. 90295

   Paul Vixie
   950 Charter Street
   Redwood City, CA 94063


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

