idnits 2.17.1 draft-manning-opcode-discover-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 412 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 53 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** There are 27 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 295: '...nt via multicast MUST NOT request recu...' RFC 2119 keyword, line 298: '... MUST listen on the -4 offset to the...' RFC 2119 keyword, line 304: '... is, a server MUST NOT answer a mult...' RFC 2119 keyword, line 310: '...bled DNS servers MUST answer multicast...' RFC 2119 keyword, line 312: '... multicast, they MUST NOT include an N...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 121 has weird spacing: '...s exist that ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Duplicate reference: RFC1035, mentioned in '3', was also mentioned in '2'. -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Bill Manning 2 draft-manning-opcode-discover-07.txt 3 Expires: 17 february 2013 17 september 2012 4 Intendend Status: Historical 6 DISCOVER: Supporting Multicast DNS Queries 8 Internet-Drafts are working documents of the Internet Engineering 9 Task Force (IETF), its areas, and its working groups. Note that 10 other groups may also distribute working documents as Internet- 11 Drafts. 13 Internet-Drafts are draft documents valid for a maximum of six months 14 and may be updated, replaced, or obsoleted by other documents at any 15 time. It is inappropriate to use Internet-Drafts as reference 16 material or to cite them other than as "work in progress." 18 The list of current Internet-Drafts can be accessed at 19 http://www.ietf.org/ietf/1id-abstracts.txt. 21 The list of Internet-Draft Shadow Directories can be accessed at 22 http://www.ietf.org/shadow.html. 24 This Internet-Draft will expire on 17 february 2013. 26 Distribution of this memo is unlimited. 28 IETF Legal Notices 30 Copyright (c) 2012 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This Internet-Draft is submitted in full conformance with the provisions 34 of BCP 78 and BCP 79. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. 43 "This document is subject to the rights, licenses and restrictions 44 contained in BCP 78, and except as set forth therein, the authors 45 retain all their rights." 47 "This document and the information contained herein are provided on an 48 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 49 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 50 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 51 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 52 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 53 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 54 FOR A PARTICULAR PURPOSE." 56 "The IETF takes no position regarding the validity or scope of any 57 Intellectual Property Rights or other rights that might be claimed 58 to pertain to the implementation or use of the technology described 59 in this document or the extent to which any license under such 60 rights might or might not be available; nor does it represent that 61 it has made any independent effort to identify any such rights. 62 Information on the procedures with respect to rights in RFC 63 documents can be found in BCP 78 and BCP 79." 65 "Copies of IPR disclosures made to the IETF Secretariat and any 66 assurances of licenses to be made available, or the result of an 67 attempt made to obtain a general license or permission for the use 68 of such proprietary rights by implementers or users of this 69 specification can be obtained from the IETF on-line IPR repository 70 at http://www.ietf.org/ipr." 72 "The IETF invites any interested party to bring to its attention any 73 copyrights, patents or patent applications, or other proprietary 74 rights that may cover technology that may be required to implement 75 this standard. Please address the information to the IETF at 76 ietf-ipr@ietf.org." 78 Abstract 80 This document describes the DISCOVER opcode, an experimental 81 extension to the Domain Name System (DNS) to use multicast queries 82 for resource discovery. This opcode was tested in experiments run 83 during 1995 and 1996 for the TBDS project. This project is no longer 84 active and there are no current plans to restart. TBDS was the first known 85 use of multicast transport for DNS. A client multicasts a DNS 86 query using the DISCOVER opcode and processes the multiple responses 87 that may result. 89 1. Introduction 91 The TBDS project developed extensions to existing network services to enable 92 application client and server software to become more resilient to changes in 93 topology by dynamically sensing changes and switching between client/server 94 and peer-peer methods for both end-system-to-server and server-to-server 95 communications. 97 The first existing network service to be investigated was the Domain Name 98 Systems (DNS) which is used to map symbolic Internet names to numeric Internet 99 addresses. Based upon a hierarchical tree structure, the DNS relies upon 100 uninterrupted connectivity of nodes to a special set of static, manually 101 configured root servers. To improve the robustness and availability of the DNS 102 service, TBDS developed and defined enhancements that enable nodes to map names 103 to numbers without the need for uninterrupted connectivity to the Internet 104 root servers. These techniques were automated, allowing transition between 105 connected and unconnected operations to done without direct human intervention. 107 These enhancements to DNS server code based on the open source BIND to support 108 reception and processing of multicast packets. 110 Proof of concept modifications to BIND 8.1.2 were made to show multicast 111 awareness could be added to BIND. An analysis was made of the existing DNS 112 code deployment and the schedule of new feature deployment so that we could 113 synchronize TBDS with a more appropriate code base. Testing identified a 114 race condition due to overloading the semantics of the DNS Opcode that was 115 used to communicate to servers. 117 This race condition was explored within the IETF in our use of existing 118 DNS Opcodes. Discussion within the team and with others in the IETF led to 119 the idea that we needed a new Opcode that would not overload the semantics 120 of existing Opcodes. The original design specification presumes that few 121 clients exist that would share common DNS data. To correct this problem a 122 new Opcode was designed to disambiguate TBDS requests from normal nameserver 123 requests. 125 In the standard Domain Name System(DNS)[1][2], queries are always 126 unicast using the QUERY opcode. The TBDS research project[4], funded 127 under DARPA grant F30602-99-1-0523, explored the use of multicast 128 DNS [1][2] queries for resource discovery by autonomous, mobile nodes 129 in disconnected networks. The operations model is covered in the TBDS 130 documentation. Multicast queries may return multiple replies, while the 131 standard DNS QUERY operation [3] expects a single reply. Instead of 132 extending the QUERY opcode, the project developed and tested a new query 133 operation, DISCOVER, that was designed to accommodate multiple responses 134 from a multicast query. The ability to accept multiple replies provides 135 a basis for discrimination of Man In The Middle attacks, which succeed by 136 being the first to respond. Use of DISCOVER requires the use of caching 137 in the receiver, so the ephemeral nature of stub resovlvers is precluded. 139 This memo documents the processing rules for DISCOVER, for possible incorporation 140 in a future revision of the DNS specification. 142 2. DISCOVER Processing Rules 144 A requester will send a DISCOVER query message to a multicast 145 destination address, with some particular multicast scope. The 146 requester must be prepared to receive multiple replies from multiple 147 responders, although we expect that there will be a single reply 148 per responder. 150 DISCOVER responses (i.e., response messages from DISCOVER queries) 151 have standard Answer, Authority, and Additional sections. For 152 example, the DISCOVER response is the same as the response to a 153 QUERY operation. Zero-content answers should not be sent, to avoid 154 badly formed or unfulfilled requests. Responses should be sent to 155 th unicast address of the requester, and the source address should 156 reflect the unicast address of the responder. DISCOVER responses 157 may echo the request's Question section or leave it blank, just as 158 for QUERY. 160 DISCOVER works like QUERY, except: 162 1. The Question section of a DISCOVER operation contains 163 tuples, if the section is 164 present. 166 Within TBDS, this structure was augmented with: 167 . While this worked, it would be 168 cleaner to ask the SRV question in a separate pass, and any 169 future work should take this into consideration. 171 2. If QDCOUNT equals 0, then only servers willing to do recursion 172 should answer; other servers must silently discard a DISCOVER 173 request with QDCOUNT equals 0. 175 3. if QDCOUNT is not equal to 0, then only servers that are 176 authoritative for the zones named by some QNAME should answer. 178 Hence, replies to DISCOVER queries will always be authoritative or 179 else have RA (Recursion Available) set. 181 3. Using DISCOVER Queries 183 3.1 Performing Host Lookups 185 To perform a hostname lookup using DISCOVER, a node could: 187 o Compute the zone name of the enclosing in-addr.arpa, ip6.int, or 188 ip6.arpa domain. 190 o DISCOVER whether any in-scope server(s) are authoritative for 191 this zone. 193 If so, query these authoritative servers for local 194 in-addr/ip6 names. 196 o If not, DISCOVER whether there are recursive servers available. 198 If so, query these recursive servers for local 199 in-addr/ip6 names. 201 The requester can determine from the replies whether there are 202 any DNS servers that are authoritative (or support recursion) 203 for the zone. 205 o Once the host's FQDN is known, repeat the process to 206 discover the closest enclosing authoritative server for 207 this local name. 209 o Cache all NS and A data learned in this process, respecting TTL's. 211 3.2 Performing Service Lookups 213 To lookup a service name using DISCOVER, the following steps may be 214 used: 216 o Use DISCOVER as outlined in Section 3.1 to perform 217 gethostbyaddr() and then gethostbyname() on one's own 218 link-local address. This gives a list of local authoritative 219 servers. 221 o Assume that the closest enclosing zone for which an 222 authoritative server responds to an in-scope DISCOVER message is 223 this host's "parent domain", and compute the SRV name as 225 _service._transport.*.parentdomain. 227 This is a change to the definition as defined in RFC 1034 [1]. 228 A wildcard label ("*") in the QNAME used in a DNS message with 229 op-code DISCOVER should be evaluated with special rules: the 230 wildcardshould match any label for which the DNS server data is 231 authoritative. For example 'x.*.example.com.' would match 232 'x.y.example.com.' and 'x.yy.example.com.', provided that the 233 server was authoritative for 'example.com.' 235 o Finally, send a SRV query for this SRV name to the discovered 236 local authoritative servers, to complete the getservbyname() call. 238 This call returns a structure that can be populated by response 239 values, as follows: 241 s_name The name of the service, "_service" without the 242 preceding underscore. 244 s_aliases The names returned in the SRV RRs in replies 245 to the query. 247 s_port The port number in the SRV RRs replies to the 248 query. If these port numbers disagree - one 249 of the port numbers is chosen, and only those 250 names which correspond are returned. 252 s_proto The transport protocol from named by the 253 "_transport" label, without the preceding 254 underscore. 256 3.3 Using DISCOVER for Disconnected Names 258 DISCOVER allows discovery of a host (for example, a printer offering 259 LPD services) whose DNS server answers authoritatively for a domain 260 name that hasn't been delegated to it, but is defined within some 261 local scope. Since DISCOVER is explicitly defined to discover 262 undelegated zones for tightly-scoped queries, this behavior isn't a 263 violation of DNS's coherency principles. Note that a responder to 264 DISCOVER might not be traditional DNS software, it could be 265 special-purpose software. 267 DISCOVER usage for disconnected networks with no authoritative 268 servers can be achieved using the following conditions. 270 o Hosts run a "stub authoritative server" that acts as though 271 its FQDN were a zone name. 273 o The computed SOA gives the host's FQDN as the MNAME, "." as 274 the ANAME, seconds-since-1Jan2000 as the SERIAL, and low 275 constants for EXPIRE and the other SOA timers. 277 o NS is used as the host's FQDN. 279 o The glue is computed as the host's link-local address, or 280 hosts may run a "DNS stub server" that acts as though its 281 FQDN were a zone name. 283 The rules governing the behavior of this server consists of a 284 single change to the method of use, and no change whatsoever to the 285 current format of DNS packets. Specifically, this extension allows 286 UDP DNS queries, as documented in RFC 1035, sections 4.1.1, 4.1.2 and 287 4.2.1, to be addressed to port 53 of statically-assigned relative 288 offset -4 within the range of multicast addresses defined as 289 "administratively scoped" by RFC 2365, section 9. Within the full 290 /8 of administratively scoped addresses, this corresponds to the 291 destination address 239.255.255.251. Until MZAP or a similar protocol 292 is implemented to allow hosts to discover the extent of the local 293 multicast scopes which enclose them, it is anticipated that 294 implementations will simply utilize the destination address 295 239.255.255.251. Queries sent via multicast MUST NOT request recursion. 297 In order to receive multicasted queries, DNS server implementations 298 MUST listen on the -4 offset to their local scope (as above, in the 299 absence of a method of determining the scope, this will be assumed to 300 be relative to the full /8 allocated for administratively-scoped 301 multicast use, or 239.255.255.251), and respond via ordinary unicast 302 UDP to ONLY those queries for which they have a positive 303 answer which originated within a locally-configured zone file. That 304 is, a server MUST NOT answer a multicasted query with cached 305 information which it received from another server, nor may it request 306 further resolution from other servers on behalf of a multicasted 307 query. A multicast-capable server may, however, utilize multicast 308 queries to perform further resolution on behalf of queries received 309 via ordinary unicast. This is referred to as "proxy" operation. 310 Multicast-enabled DNS servers MUST answer multicasted queries 311 non-authoritatively. That is, when responding to a query which was 312 received via multicast, they MUST NOT include an NS record which 313 contains data which resolves back to their own IP address and MUST 314 NOT set the AA bit. 316 Resolvers MUST anticipate receiving no replies to some multicasted 317 queries, in the event that no multicast-enabled DNS server 318 implementations are active within the local scope, or in the event 319 that no positive responses exist to the transmitted query. 320 That is, a query for the MX record for host.domain.com would go 321 unanswered if no local server was able to resolve that request, if no 322 MX record exists for host.domain.com, or if no local servers were 323 capable of receiving multicast queries. The resolver which initiated 324 the query MUST treat such non-response as a non-cacheable negative 325 response. Since this multicast transmission does not provide 326 reliable delivery, resolvers MAY repeat the transmission of a query 327 in order to assure themselves that is has been received by any hosts 328 capable of answering, however any resolvers which repeat a query MUST 329 increase the interval by a factor of two between each repetition. It 330 is more likely, however, that any repeated queries will be performed 331 under the explicit direction of the application driving the query, 332 rather than autonomously by the resolver implementation. 334 It will often be the case that multicast queries will result in 335 responses from multiple servers. In the event that the multicast 336 query was generated via a current API such as gethostbyname, or as 337 the result of a proxy operation, the first response received must be 338 passed to the requesting application or host, and all 339 subsequently-received responses must be discarded. Future 340 multicast-aware APIs that use DISCOVER should anticipate receiving 341 multiple independent RR-sets in response to queries and using external 342 heristics for selecting the most appropriate RR-set. 344 Such servers should answer DISCOVER packets for its zone, and 345 will be found by the iterative "discover closest enclosing authority 346 server" by DISCOVER clients, in either the gethostbyname() or SRV 347 cases described above. Note that stub servers answer only with 348 zone names which exactly match QNAME's, not with zone names which 349 are owned by QNAME's. 351 4. IANA Considerations 353 At such time as this idea might be considered for a future addition to 354 the DNS protocol, the IANA would need to assign a value for the opcode. 356 5. Security Considerations 358 The following paragraph on security considerations was written very early 359 in the use and exploration of IP multicast and as such, represents a fairly 360 naive view on the type and scope of exploits that are enabled through the 361 use of IP multicast. A more up to date understanding of multicast security 362 considerations may be found in RFC 5294[3]. 364 No new security considerations are known to be introduced with a new 365 DNS query operation. However, using multicast for service discovery 366 has the potential for denial of service from flooding attacks. How to 367 scope multicast is not part of the DISCOVER processing rules. It 368 may also be possible to enable deliberate misconfiguration of 369 clients simply by running a malicious DNS server that falsely claims 370 to be authoritative for delegations. One possible way to mitigate 371 this threat is to use credentials, such as CERT resource records 372 within an RR set. The TBDS project took this approach. TBDS did 373 not directly utilize DNSSEC and so possible interactions with 374 DNSSEC aware/capable servers are unknown. 376 6. Acknowledgments 378 This material was generated in discussions on the mdns mailing 379 list hosted by Zocalo in March 2000 and updated by discussions in 380 September/October 2003 on a closed mailing list. David Lawrence, 381 Scott Rose, Stuart Cheshire, Bill Woodcock, Erik Guttman were 382 active contributors. Suzanne Woolf was part of the original 383 implementation team and an invaluable sanity checker. Funding for 384 the RFC Editor function is currently provided by the Internet Society. 386 7. References 388 Normative: 390 [1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 391 RFC 1034, November 1987. 392 [2] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 393 RFC 1035, November 1987. 394 [3] Savola, P., Lingard, J. "Host Threats to Protocol Independent Multicast (PIM)", 395 RFC 5294, August 2008 396 Informative: 398 [3] QUERY opcode -- defined in section 3.7, 4.3, and section 5 of RFC 399 1034 and in section 4.1.1 of RFC 1035. 400 [4] Manning, B., "TBDS - Topology Based Domain Search.", Project Final 401 Report, http://www.dtic.mil/docs/citations/ADA407598 403 Authors' Addresses 405 Bill Manning 406 PO 12317 407 Marina del Rey, CA. 90295