contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt

   1
   2 IETF DNSEXT WG                                             Bill Manning
   3 draft-dnsext-opcode-discover-02.txt                              ep.net
   4                                                              Paul Vixie
   5                                                                     ISC
   6                                                             13 Oct 2003
   7
   8
   9                          The DISCOVER opcode
  10
  11 This document is an Internet-Draft and is subject to all provisions of
  12 Section 10 of RFC2026.
  13
  14 Comments may be submitted to the group mailing list at "mdns@zocalo.net"
  15 or the authors.
  16
  17 Distribution of this memo is unlimited.
  18
  19 Internet-Drafts are working documents of the Internet Engineering Task
  20 Force (IETF), its areas, and its working groups.  Note that other groups
  21 may also distribute working documents as Internet-Drafts.
  22
  23 Internet-Drafts are draft documents valid for a maximum of six months and
  24 may be updated, replaced, or obsoleted by other documents at any time.  It
  25 is inappropriate to use Internet-Drafts as reference material or to cite
  26 them other than as "work in progress."
  27
  28    The list of current Internet-Drafts can be accessed at
  29    http://www.ietf.org/ietf/1id-abstracts.txt
  30
  31    The list of Internet-Draft Shadow Directories can be accessed at
  32    http://www.ietf.org/shadow.html.
  33
  34 The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  36 document are to be interpreted as described in RFC 2119
  37
  38 0. Abstract:
  39
  40    The QUERY opcode in the DNS is designed for unicast. With the
  41    development of multicast capabilities in the DNS, it is desireable
  42    to have a more robust opcode for server interactions since a single
  43    request may generate replies from multiple responders. So DISCOVER
  44    is defined to deal with replies from multiple responders.
  45
  46    As such, this document extends the core DNS specifications to allow
  47    clients to have a method for coping with replies from multiple
  48    responders. Use of this new opcode may facilitate DNS operations in
  49    modern networking topologies. A prototype of the DISCOVER opcode
  50    was developed during the TBDS project (1999-2000), funded under DARPA
  51    grant F30602-99-1-0523.
  52
  53 1. Introduction:
  54
  55    This document describes an experimental extension to the DNS to receive
  56    multiple responses which is the likely result when using DNS that has
  57    enabled multicast queries.  This approach was developed as part of the
  58    TBDS research project, funded under DARPA grant F30602-99-1-0523.  The
  59    full processing rules used by TBDS are documented here for possible
  60    incorporation in a future revision of the DNS specification."
  61
  62 2. Method:
  63
  64         DISCOVER works like QUERY except:
  65
  66         1. it can be sent to a broadcast or multicast destination. QUERY
  67            isn't defined for non-unicast, and arguably shouldn't be.
  68
  69         2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
  70            tuples. TBDS tried to augment this structure as follows:
  71            <QNAME=service,QTYPE=SRV>. While this worked for our purposes in
  72            TBDS, it is cleaner to place the SRV question in a separate pass.
  73
  74         3. if QDCOUNT equals 0 then only servers willing to do recursion should
  75            answer. Other servers must silently discard the DISCOVER request.
  76
  77         4. if QDCOUNT is not equal to 0 then only servers who are authoritative
  78            for the zones named by some QNAME should answer.
  79
  80         5. responses may echo the request's Question section or leave it blank,
  81            just like QUERY.
  82
  83         6. responses have standard Answer, Authority, and Additional sections.
  84            e.g. the response is the same as that to a QUERY. It is desireable
  85            that zero content answers not be sent to avoid badly formed or
  86            unfulfilled requests. Responses should be sent to the unicast
  87            address of the requester and the source address should reflect
  88            the unicast address of the responder.
  89
  90    Example usage for gethostby{name,addr}-style requestors:
  91
  92         Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
  93         ip6.arpa domain.
  94
  95         DISCOVER whether anyone in-scope is authoritative for this zone.
  96
  97                 If so, query these authoritative servers for local
  98                 in-addr/ip6 names.
  99
 100         If not, DISCOVER whether there are recursive servers available.
 101
 102                 If so, query these recursive servers for local
 103                 in-addr/ip6 names.
 104
 105         So, a node will issue a multicast request with the DISCOVER opcode at
 106         some particular multicast scope.  Then determine, from the replies,
 107         whether there are any DNS servers which are authoritative (or support
 108         recursion) for the zone. Replies to DISCOVER requests MUST set the
 109         Recursion Available (RA) flag in the DNS message header.
 110
 111         It is important to recognize that a requester must be prepared to
 112         receive multiple replies from multiple responders. We expect that
 113         there will be a single response per responder.
 114
 115         Once one learns a host's FQDN by the above means, repeat the process
 116         for discovering the closest enclosing authoritative server of such
 117         local name.
 118
 119         Cache all NS and A data learned in this process, respecting TTL's.
 120
 121    TBDS usage for SRV requestors:
 122
 123         Do the gethostbyaddr() and gethostbyname() on one's own link-local
 124         address, using the above process.
 125
 126         Assume that the closest enclosing zone for which an authority server
 127         answers an in-scope DISCOVER packet is "this host's parent domain".
 128
 129         Compute the SRV name as _service._transport.*.parentdomain.
 130
 131         This is a change to the definition as defined in RFC 1034.
 132         A wildcard label ("*") in the QNAME used in a DNS message with
 133         opcode DISCOVER SHOULD be evaluated with special rules.  The
 134         wildcard matches any label for which the DNS server data is
 135         authoritative.  For example 'x.*.example.com.' would match
 136         'x.y.example.com.' and 'x.yy.example.com.' provided that the
 137         server was authoritative for 'example.com.'  In this particular
 138         case, we suggest the follwing considerations be made:
 139
 140    getservbyname() can be satisfied by issuing a request with
 141    this computed SRV name.  This structure can be
 142    populated by values returned from a request as follows:
 143
 144         s_name    The name of the service, "_service" without the
 145                   preceding underscore.
 146         s_aliases The names returned in the SRV RRs in replies
 147                   to the query.
 148         s_port    The port number in the SRV RRs replies to the
 149                   query.  If these port numbers disagree - one
 150                   of the port numbers is chosen, and only those
 151                   names which correspond are returned.
 152         s_proto   The transport protocol from named by the
 153                   "_transport" label, without the preceding
 154                   underscore.
 155
 156         Send SRV query for this name to discovered local authoritative servers.
 157
 158      Usage for disconnected networks with no authoritative servers:
 159
 160         Hosts should run a "stub server" which acts as though its FQDN is a
 161         zone name.  Computed SOA gives the host's FQDN as MNAME, "." as the
 162         ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
 163         and the other timers.  Compute NS as the host's FQDN.  Compute the
 164         glue as the host's link-local address. Or Hosts may run a
 165         "DNS stub server" which acts as though its FQDN is a zone name.  The
 166         rules governing the behavior of this stub server are given elsewhere
 167         [1] [2].
 168
 169         Such stub servers should answer DISCOVER packets for its zone, and
 170         will be found by the iterative "discover closest enclosing authority
 171         server" by DISCOVER clients, either in the gethostbyname() or SRV
 172         cases described above.  Note that stub servers only answer with
 173         zone names which exactly match QNAME's, not with zone names which
 174         are owned by QNAME's.
 175
 176    The main deviation from the DNS[3][4] model is that a host (like, say, a
 177    printer offering LPD services) has a DNS server which answers authoritatively
 178    for something which hasn't been delegated to it.  However, the only way that
 179    such DNS servers can be discovered is with a new opcode, DISCOVER, which
 180    is explicitly defined to discover undelegated zones for tightly scoped
 181    purposes.  Therefore this isn't officially a violation of DNS's coherency
 182    principles. In some cases a responder to DISCOVER may not be traditional
 183    DNS software, it could be special purpose software.
 184
 185 3. IANA Considerations
 186
 187         As a new opcode, the IANA will need to assign a numeric value
 188         for the memnonic. The last OPCODE assigned was "5", for UPDATE.
 189         Test implementations have used OPCODE "6".
 190
 191 4. Security Considerations
 192
 193         No new security considerations are known to be introduced with any new
 194         opcode, however using multicast for service discovery has the potential
 195         for denial of service, primarly from flooding attacks. It may also be
 196         possible to enable deliberate misconfiguration of clients simply by
 197         running a malicious DNS resolver that claims to be authoritative for
 198         things that it is not. One possible way to mitigate this effect is by
 199         use of credentials, such as CERT resource records within an RR set.
 200         The TBDS project took this approach.
 201
 202 5. Attribution:
 203
 204         This material was generated in discussions on the mdns mailing list
 205 hosted by Zocalo in March 2000. Updated by discussion in September/October
 206 2003.  David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
 207 Erik Guttman, Bill Manning and Paul Vixie were active contributors.
 208
 209 6. Author's Address
 210
 211    Bill Manning
 212    PO 12317
 213    Marina del Rey, CA. 90295
 214    +1.310.322.8102
 215    bmanning@karoshi.com
 216
 217    Paul Vixie
 218    Internet Software Consortium
 219    950 Charter Street
 220    Redwood City, CA 94063
 221    +1 650 779 7001
 222    <vixie@isc.org>
 223
 224 7. References
 225
 226 Informational References:
 227
 228 [1]  Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
 229         draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
 230
 231 [2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
 232         draft-manning-dnsext-mdns-00.txt,  August 2000.  Expired.
 233
 234 Normative References:
 235 [3]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
 236         RFC 1034, November 1987.
 237 [4]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
 238         RFC 1035, November 1987
 239
 240         ----------------------------EOL-----------------------
 241