Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6804.
Author Bill Manning
Last updated 2012-08-28 (Latest revision 2012-08-23)
RFC stream Independent Submission
Formats
IETF conflict review conflict-review-manning-opcode-discover, conflict-review-manning-opcode-discover, conflict-review-manning-opcode-discover, conflict-review-manning-opcode-discover, conflict-review-manning-opcode-discover, conflict-review-manning-opcode-discover
Additional resources
Stream ISE state (None)
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state Became RFC 6804 (Historic)
Telechat date (None)
Responsible AD Russ Housley
Send notices to bmanning@ISI.EDU, paul@vix.com, rfc-ise@rfc-editor.org
RFC Editor RFC Editor state ISR-AUTH
Details
draft-manning-opcode-discover-06
Internet Draft                                              Bill Manning
draft-manning-opcode-discover-06.txt
Expires: 29 january 2013                                  23 august 2012
Intendend Status: Historical

                 DISCOVER: Supporting Multicast DNS Queries

   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 29 january 2013.

   Distribution of this memo is unlimited.

IETF Legal Notices

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This Internet-Draft is submitted in full conformance with the provisions 
   of BCP 78 and BCP 79.
  
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

     "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."

     "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, THE
      IETF TRUST 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."

     "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."

Abstract

   This document describes the DISCOVER opcode, an experimental
   extension to the Domain Name System (DNS) to use multicast queries
   for resource discovery. This opcode was tested in experiments run 
   during 1995 and 1996 for the TBDS project. TBDS was the first known
   use of multicast transport for DNS.  A client multicasts a DNS 
   query using the DISCOVER opcode and processes the multiple responses 
   that may result.

1. Introduction

   The TBDS project developed extensions to existing network services to enable     
   application client and server software to become more resilient to changes in 
   topology by dynamically sensing changes and switching between client/server 
   and peer-peer methods for both end-system-to-server and server-to-server  
   communications.

   The first existing network service to be investigated was the Domain Name 
   Systems (DNS) which is used to map symbolic Internet names to numeric Internet 
   addresses. Based upon a hierarchical tree structure, the DNS relies upon 
   uninterrupted connectivity of nodes to a special set of static, manually 
   configured root servers. To improve the robustness and availability of the DNS 
   service, TBDS developed and defined enhancements that enable nodes to map names 
   to numbers without the need for uninterrupted connectivity to the Internet 
   root servers. These techniques were automated, allowing transition between 
   connected and unconnected operations to done without direct human intervention.

   These enhancements to DNS server code based on the open source BIND to support
   reception and processing of multicast packets.

    Proof of concept modifications to BIND 8.1.2 were made to show multicast 
    awareness could be added to BIND. An analysis was made of the existing DNS 
    code deployment and the schedule of new feature deployment so that we could
    synchronize TBDS with a more appropriate code base. Testing identified a 
    race condition due to overloading the semantics of the DNS Opcode that was 
    used to communicate to servers.

    This race condition was explored within the IETF in our use of existing 
    DNS Opcodes. Discussion within the team and with others in the IETF led to 
    the idea that we needed a new Opcode that would not overload the semantics
    of existing Opcodes. The original design specification presumes that few 
    clients exist  that would share common DNS data. To correct this problem a 
    new Opcode was designed to disambiguate TBDS requests from normal nameserver 
    requests. 

   In the standard Domain Name System(DNS)[1][2], queries are always
   unicast using the QUERY opcode. The TBDS research project[4], funded
   under DARPA grant F30602-99-1-0523, explored the use of multicast
   DNS [1][2] queries for resource discovery by autonomous, mobile nodes
   in disconnected networks.  The operations model is covered in the TBDS
   documentation. Multicast queries may return multiple replies, while the 
   standard DNS QUERY operation [3] expects a single reply.  Instead of 
   extending the QUERY opcode, the project developed and tested a new query 
   operation, DISCOVER, that was designed to accommodate multiple responses 
   from a multicast query. The ability to accept multiple replies provides
   a basis for discrimination of Man In The Middle attacks, which succeed by
   being the first to respond. Use of DISCOVER requires the use of caching 
   in the receiver, so the ephemeral nature of stub resovlvers is precluded.
  
   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 outlined 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 [1].
        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 authoritative 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 server 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
   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 that use DISCOVER should anticipate receiving 
   multiple independent RR-sets in response to queries and using external
   heristics for selecting the most appropriate RR-set.

   Such 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

   At such time as this idea might be considered for a future addition to 
   the DNS protocol, the IANA would need to assign a value for the opcode.

5. Security Considerations

   The following paragraph on security considerations was written very early 
   in the use and exploration of IP multicast and as such, represents a fairly 
   naive view on the type and scope of exploits that are enabled through the 
   use of IP multicast.  A more up to date understanding of multicast security
   considerations may be found in RFC 5294.
   
   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. How to 
   scope multicast is not part of the DISCOVER processing rules.  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 mailing
   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. Funding for 
   the RFC Editor function is currently provided by the Internet Society.

7. References

Normative:

[1]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
        RFC 1034, November 1987.
[2]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
        RFC 1035, November 1987.

Informative:

[3]  QUERY opcode -- defined in section 3.7, 4.3, and section 5 of RFC
        1034 and in section 4.1.1 of RFC 1035.
[4]  Manning, B., "TBDS - Topology Based Domain Search.", Project Final
        Report, http://www.dtic.mil/docs/citations/ADA407598

Authors' Addresses

   Bill Manning
   PO 12317
   Marina del Rey, CA. 90295