DISCOVER: Supporting Multicast DNS Queries
draft-manning-opcode-discover-07

Versions: 00 01 02 03 04 05 06 07 rfc6804                               
IETF Individual Submission                                 Bill Manning
draft-manning-opcode-discover-01.txt                             ep.net
                                                             Paul Vixie
                                                                    ISC
                                                            02 Jun 2005


                       Supporting unicast replies
                   to multicast queries in the DNS or
                        DISCOVER opcode defined

   This document is an Internet-Draft and is subject to all provisions of
   Section 10 of RFC2026 except that the right to produce derivative works
   is not granted.

   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 December 3, 2005.

Distribution of this memo is unlimited.

Abstract

   The QUERY opcode in the DNS is designed for unicast environments.
   With the development of multicast capabilities in the DNS, it is
   desirable to have a more robust opcode for server interactions since a
   single request may generate replies from multiple responders. So
   DISCOVER is defined to deal with replies from multiple responders.

   As such, this document documents experimental extensions the core DNS
   specifications that were made during the TBDS effort, to allow clients
   to have a method for coping with replies from multiple responders. Use
   of this new opcode may facilitate DNS operations in modern networking
   topologies. A prototype of the DISCOVER opcode was developed during
   the TBDS project (1999-2000), funded under DARPA grant F30602-99-1-0523.

Introduction

   When exploring multicast as a viable means for DNS service discover
   as part of TBDS project (1999-2000), funded under DARPA grant
   F30602-99-1-0523, it became apparent that the original DNS op-code,
   QUERY[5] was designed such that a single response was expected. In
   a multicast environment, it was possible that multiple replies were
   not only possible but to be expected.  Instead of modifying the
   QUERY opcode, we have developed and tested a new opcode, here-in
   called DISCOVER, which is designed to accommodate multiple responses.
   The full processing rules used by TBDS are documented here for possible
   incorporation in a future revision of the DNS specification.

   This draft was originally submitted for consideration in 2q2000.

Method:

        DISCOVER works like QUERY except:

        1. it can be sent to a broadcast or multicast destination. QUERY
           isn't defined for non-unicast, and arguably shouldn't be.

        2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
           tuples. Within TBDS, we  tried to augment this structure as
           follows: <QNAME=service,QTYPE=SRV>.
           While this worked for our purposes in the TBDS project, it is           cleaner to place the SRV question in a separate pass and any
           future work should take this into consideration.

        3. if QDCOUNT equals 0 then only servers willing to do recursion
           should answer. Other servers must silently discard the DISCOVER
           request.

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

        5. responses may echo the request's Question section or leave it
           blank, just like QUERY.

        6. responses have standard Answer, Authority, and Additional
           sections e.g. the response is the same as that to a QUERY. It is
           desirable that zero content answers not be sent to avoid badly
           formed or unfulfilled requests. Responses should be sent to the
           unicast address of the requester and the source address should
           reflect the unicast address of the responder.

   Example usage for gethostby{name,addr}-style requesters:

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

        DISCOVER whether anyone in-scope is authoritative for this zone.

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

        If not, DISCOVER whether there are recursive servers available.

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

        So, a node will issue a multicast request with the DISCOVER opcode
        at some particular multicast scope.  Then determine, from the
        replies, whether there are any DNS servers which are authoritative
        (or support recursion) for the zone. Replies to DISCOVER requests
        MUST set the Recursion Available (RA) flag in the DNS message
        header.

        It is important to recognize that a requester must be prepared to
        receive multiple replies from multiple responders. We expect that
        there will be a single response per responder.

        Once one learns a host's FQDN by the above means, repeat the
        process for discovering the closest enclosing authoritative server
        of such local name.

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

   The TBDS project usage for SRV requesters is described in the section below.  The sequence of steps describes the basic algorithm used by TBDS
code to request and process multiple replies within an IP multicast domain.

        Do the gethostbyaddr() and gethostbyname() on one's own link-local
        address, using the above process.

        Assume that the closest enclosing zone for which an authority
        server
        answers an in-scope DISCOVER packet is "this host's parent domain".

        Compute the SRV name as _service._transport.*.parentdomain.

   This is a change to the definition as defined in RFC 1034. A wildcard label ("*") in the QNAME used in a DNS message with op-code DISCOVER should
be evaluated with special rules.  The wildcard matches 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.'  In this particular case, we suggest
the following considerations be made:

   getservbyname() can be satisfied by issuing a request with
   this computed SRV name.  This structure can be
   populated by values returned from a request 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.

        We then send SRV query for this name to discovered local authoritative servers.

     DISCOVER usage for disconnected networks with no authoritative servers
can be extrapolated with the following conditions being met:

        Hosts should run a "stub server" which acts as though its FQDN
is a zone name.  Computed SOA gives the host's FQDN as MNAME, "." as the
ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE and
the other SOA timers.  Compute NS as the host's FQDN.  Compute the glue as
the host's link-local address. Or Hosts may run a "DNS stub server" which
acts as though its FQDN is 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, either in the gethostbyname() or SRV cases
described above.  Note that stub servers only answer with  zone names which
exactly match QNAME's, not with zone names which are owned by QNAME's.

   The main deviation from the DNS[3][4] model is that a host (like, say, a
printer offering LPD services) has a DNS server which answers
authoritatively for something which hasn't been delegated to it.  However,
the only way that such DNS servers can be discovered is with a new opcode,
DISCOVER, which is explicitly defined to discover undelegated zones for
tightly scoped purposes.  Therefore this isn't officially a violation of
DNS's  coherency principles. In some cases a responder to DISCOVER may not
be traditional DNS software, it could be special purpose software.

IANA Considerations

        As a new opcode, the IANA will need to assign a numeric value
        for the memnonic. The last OPCODE assigned was "5", for UPDATE.
        Test implementations have used OPCODE "6".  Op-codes 0 - 2
        were defined in RFC 1035, section 4.1.1, op-code 3 is listed
        as IANA reserved, op-code 4 is defined in RFC 1996 and op-code
        5 is defined in RFC 2136. op-code 1 has been retired with the
        publication of RFC 3425.

Security Considerations

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

Attribution

        This material was generated in discussions on the mdns mailing
        list hosted by Zocalo in March 2000. Updated by discussion 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.


References

[1]  Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
        draft-ietf-dnsext-mdns-00.txt, November 2000. Expired

[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
        draft-manning-dnsext-mdns-00.txt,  August 2000.  Expired.

[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 - defined in section 3.7, 4.3, and section 5 of RFC 1034 and
        in section 4.1.1 of RFC 1035.


Author's Address

   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.