idnits 2.17.1 draft-manning-opcode-discover-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 261 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 34 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 118: '...lies to DISCOVER requests MUST set the...' RFC 2119 keyword, line 145: '... opcode DISCOVER SHOULD be evaluated w...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (24 May 2004) is 7277 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-47) exists of draft-ietf-dnsext-mdns-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsext-mdns (ref. '1') -- Possible downref: Normative reference to a draft: ref. '2' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Idividual Submission Bill Manning 2 draft-manning-opcode-discover-00.txt ep.net 3 Paul Vixie 4 ISC 5 24 May 2004 7 The DISCOVER opcode 9 This document is an Internet-Draft and is subject to all provisions of 10 Section 10 of RFC2026 except that the right to produce derivative works 11 is not granted. 13 Comments may be submitted to the group mailing list at "mdns@zocalo.net" 14 or the authors. 16 Distribution of this memo is unlimited. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months and 23 may be updated, replaced, or obsoleted by other documents at any time. It 24 is inappropriate to use Internet-Drafts as reference material or to cite 25 them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 34 NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 38 0. Abstract: 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. 46 As such, this document documents experimental extends the core DNS 47 specifications to allow clients to have a method for coping with 48 replies from multiple responders. Use of this new opcode may 49 facilitate DNS operations in modern networking topologies. A prototype 50 of the DISCOVER opcode was developed during the TBDS project (1999- 51 2000), funded under DARPA grant F30602-99-1-0523. This draft was 52 originally submitted for consideration in 2q2000. 54 1. Introduction: 56 This document describes an experimental extension to the DNS to receive 57 multiple responses which is the likely result when using DNS that has 58 enabled multicast queries. This approach was developed as part of the 59 TBDS research project, funded under DARPA grant F30602-99-1-0523. The 60 full processing rules used by TBDS are documented here for possible 61 incorporation in a future revision of the DNS specification." 63 2. Method: 65 DISCOVER works like QUERY except: 67 1. it can be sent to a broadcast or multicast destination. QUERY 68 isn't defined for non-unicast, and arguably shouldn't be. 70 2. the Question section, if present, has 71 tuples. TBDS tried to augment this structure as follows: 72 . While this worked for our purposes in 73 TBDS, it is cleaner to place the SRV question in a separate 74 pass. 76 3. if QDCOUNT equals 0 then only servers willing to do recursion 77 should 78 answer. Other servers must silently discard the DISCOVER 79 request. 81 4. if QDCOUNT is not equal to 0 then only servers who are 82 authoritative 83 for the zones named by some QNAME should answer. 85 5. responses may echo the request's Question section or leave it 86 blank, 87 just like QUERY. 89 6. responses have standard Answer, Authority, and Additional 90 sections. 91 e.g. the response is the same as that to a QUERY. It is 92 desireable 93 that zero content answers not be sent to avoid badly formed or 94 unfulfilled requests. Responses should be sent to the unicast 95 address of the requester and the source address should reflect 96 the unicast address of the responder. 98 Example usage for gethostby{name,addr}-style requestors: 100 Compute the zone name of the enclosing in-addr.arpa, ip6.int, or 101 ip6.arpa domain. 103 DISCOVER whether anyone in-scope is authoritative for this zone. 105 If so, query these authoritative servers for local 106 in-addr/ip6 names. 108 If not, DISCOVER whether there are recursive servers available. 110 If so, query these recursive servers for local 111 in-addr/ip6 names. 113 So, a node will issue a multicast request with the DISCOVER opcode 114 at 115 some particular multicast scope. Then determine, from the replies, 116 whether there are any DNS servers which are authoritative (or 117 support 118 recursion) for the zone. Replies to DISCOVER requests MUST set the 119 Recursion Available (RA) flag in the DNS message header. 121 It is important to recognize that a requester must be prepared to 122 receive multiple replies from multiple responders. We expect that 123 there will be a single response per responder. 125 Once one learns a host's FQDN by the above means, repeat the 126 process 127 for discovering the closest enclosing authoritative server of such 128 local name. 130 Cache all NS and A data learned in this process, respecting TTL's. 132 TBDS usage for SRV requestors: 134 Do the gethostbyaddr() and gethostbyname() on one's own link-local 135 address, using the above process. 137 Assume that the closest enclosing zone for which an authority 138 server 139 answers an in-scope DISCOVER packet is "this host's parent domain". 141 Compute the SRV name as _service._transport.*.parentdomain. 143 This is a change to the definition as defined in RFC 1034. 144 A wildcard label ("*") in the QNAME used in a DNS message with 145 opcode DISCOVER SHOULD be evaluated with special rules. The 146 wildcard matches any label for which the DNS server data is 147 authoritative. For example 'x.*.example.com.' would match 148 'x.y.example.com.' and 'x.yy.example.com.' provided that the 149 server was authoritative for 'example.com.' In this particular 150 case, we suggest the follwing considerations be made: 152 getservbyname() can be satisfied by issuing a request with 153 this computed SRV name. This structure can be 154 populated by values returned from a request as follows: 156 s_name The name of the service, "_service" without the 157 preceding underscore. 158 s_aliases The names returned in the SRV RRs in replies 159 to the query. 160 s_port The port number in the SRV RRs replies to the 161 query. If these port numbers disagree - one 162 of the port numbers is chosen, and only those 163 names which correspond are returned. 164 s_proto The transport protocol from named by the 165 "_transport" label, without the preceding 166 underscore. 168 Send SRV query for this name to discovered local authoritative 169 servers. 171 Usage for disconnected networks with no authoritative servers: 173 Hosts should run a "stub server" which acts as though its FQDN is a 174 zone name. Computed SOA gives the host's FQDN as MNAME, "." as the 175 ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for 176 EXPIRE 177 and the other timers. Compute NS as the host's FQDN. Compute the 178 glue as the host's link-local address. Or Hosts may run a 179 "DNS stub server" which acts as though its FQDN is a zone name. 180 The 181 rules governing the behavior of this stub server are given 182 elsewhere 183 [1] [2]. 185 Such stub servers should answer DISCOVER packets for its zone, and 186 will be found by the iterative "discover closest enclosing 187 authority 188 server" by DISCOVER clients, either in the gethostbyname() or SRV 189 cases described above. Note that stub servers only answer with 190 zone names which exactly match QNAME's, not with zone names which 191 are owned by QNAME's. 193 The main deviation from the DNS[3][4] model is that a host (like, say, a 194 printer offering LPD services) has a DNS server which answers 195 authoritatively 196 for something which hasn't been delegated to it. However, the only 197 way that 198 such DNS servers can be discovered is with a new opcode, DISCOVER, which 199 is explicitly defined to discover undelegated zones for tightly scoped 200 purposes. Therefore this isn't officially a violation of DNS's 201 coherency 202 principles. In some cases a responder to DISCOVER may not be traditional 203 DNS software, it could be special purpose software. 205 3. IANA Considerations 207 As a new opcode, the IANA will need to assign a numeric value 208 for the memnonic. The last OPCODE assigned was "5", for UPDATE. 209 Test implementations have used OPCODE "6". 211 4. Security Considerations 213 No new security considerations are known to be introduced with 214 any new 215 opcode, however using multicast for service discovery has the 216 potential 217 for denial of service, primarly from flooding attacks. It may also 218 be 219 possible to enable deliberate misconfiguration of clients simply by 220 running a malicious DNS resolver that claims to be authoritative 221 for 222 things that it is not. One possible way to mitigate this effect 223 is by 224 use of credentials, such as CERT resource records within an RR set. 225 The TBDS project took this approach. 227 5. Attribution: 229 This material was generated in discussions on the mdns mailing list 230 hosted by Zocalo in March 2000. Updated by discussion in September/October 231 2003. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock, 232 Erik Guttman, Bill Manning and Paul Vixie were active contributors. 234 6. Author's Address 236 Bill Manning 237 PO 12317 238 Marina del Rey, CA. 90295 240 Paul Vixie 241 950 Charter Street 242 Redwood City, CA 94063 244 7. References 246 Informational References: 248 [1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS", 249 draft-ietf-dnsext-mdns-00.txt, November 2000. Expired 251 [2] Woodcock, B., Manning, B., "Multicast Domain Name Service", 252 draft-manning-dnsext-mdns-00.txt, August 2000. Expired. 254 Normative References: 255 [3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 256 RFC 1034, November 1987. 257 [4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 258 RFC 1035, November 1987