idnits 2.17.1 draft-ietf-dnsext-mdns-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 expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 317 has weird spacing: '...The mechanism...' == Line 376 has weird spacing: '...imed to perta...' == Line 420 has weird spacing: '...>, and expir...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 16, 2000) is 8561 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 (-04) exists of draft-aboba-dhc-mini-01 -- Possible downref: Normative reference to a draft: ref. '3' Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group Levon Esibov 3 INTERNET-DRAFT Bernard Aboba 4 Category: Standards Track Dave Thaler 5 Microsoft 6 November 16, 2000 8 Multicast DNS 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet- Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2000). All Rights Reserved. 32 Abstract 34 Today, with the rise of home networking, there are an increasing number 35 of small networks operating without a DNS server. In order to allow DNS 36 name resolution in such environments, the use of a multicast DNS is 37 proposed. 39 1. Introduction 41 Multicast DNS enables DNS name resolution in the scenarios when 42 conventional DNS name resolution is not possible. Namely, when there are 43 no DNS servers available on the network or available DNS servers do not 44 provide name resolution for the names of the hosts on the local 45 network. The latter case, for example, corresponds to a scenario when a 46 home network that doesn't have a DNS server is connected to the Internet 47 through an ISP and the home network hosts are configured with the ISP's 48 DNS server for the name resolution. The ISP's DNS server provides the 49 name resolution for the names registered on the Internet, but doesn't 50 provide name resolution for the names of the hosts on the home network. 52 This document discusses multicast DNS, an extension to the DNS protocol 53 which consists of a single change to the method of use, and no change to 54 the format of DNS packets. 56 Discovery of the services in general as well as discovery of the DNS 57 servers in particular using multicast DNS is left outside of the scope 58 of this document. 60 Name resolution over non-multicast capable media is left outside of the 61 scope of this document. 63 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 64 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 65 described in [1]. 67 2. Name resolution using Multicast DNS 69 This extension to the DNS protocol consists of a single change to the 70 method of use, and no change whatsoever to the current format of DNS 71 packets. Namely, this extension allows multicast DNS queries to be sent 72 to and received on port 53 using the LINKLOCAL addresses [2] for IPv4 73 and IPv6 (below in this text referred as LINKLOCAL address), which are 74 yet to be assigned by IANA. LINKLOCAL addresses are used to prevent 75 propagation of the multicast DNS traffic across the routers that may 76 cause network flooding. Propagation of the multicast DNS packets within 77 the boundaries is considered sufficient to enable DNS name resolution, 78 since the expectation is that if a network has a router, then this 79 router can function as a mini-DHCP server, as described in [3], and a 80 DNS proxy, possibly implementing dynamic DNS. Thus there is not expected 81 to be a need for use of multicast DNS in networks with multiple 82 segments. 84 2.1 Behavior of the sender and responder 86 For the purpose of this document a device that sends a multicast query 87 is called a "sender", while a device that listens to (but not 88 necessarily responds to) a multicast query is called "responder". A 89 device configured to be a "responder" may also be a "sender". A device 90 configured to not be a "responder" cannot be a "sender". 92 A sender sends multicast DNS query for any legal Type of resource record 93 (e.g. A, PTR, etc�) for a name within the ".local.arpa." domain to the 94 LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a 95 responder receives a query with the header containing RD set bit, the 96 responder MUST ignore the RD bit. 98 If the multicast query is not positively resolved ("positively resolved" 99 refers in this document to the response with the RCODE set to 0) during 100 a limited amount of time, then a sender MAY repeat the transmission of a 101 query in order to assure themselves that the query has been received by 102 a host capable of responding to the query. Repetition MUST NOT be 103 attempted more than 5 times, and the repetition SHOULD NOT be repeated 104 more often than once per 0.1 seconds to reduce the unnecessary network 105 traffic. Retry intervals SHOULD be exponentially increased. 107 A responder listens on port 53 on the LINKLOCAL address. Responders MUST 108 respond to multicast queries to those and only those names for which 109 they are authoritative. As an example, computer 110 "host.example.com.local.arpa." is authoritative for the domain 111 "host.example.com.local.arpa.". When such host receives a multicast DNS 112 query for an A record for the name "host.example.com.local.arpa." it 113 responds with an A record(s) that contains its IP address(es) in the 114 RDATA of the record. 115 In conventional DNS terminology a DNS server authoritative for a zone is 116 authoritative for all the domain names under the zone root except for 117 the branches delegated into separate zones. Contrary to conventional DNS 118 terminology, a responder is authoritative only for the zone root. For 119 example the host "host.example.com.local.arpa." is not authoritative for 120 the name "child.host.example.com.local.arpa." unless the host is 121 configured with multiple names, including "host.example.com.local.arpa." 122 and "child.host.example.com.local.arpa.". The purpose of such limitation 123 of the name authority scope of a responder is to prevent complication 124 that could be caused by coexistence of two or more devices with the 125 names representing child and parent (or grandparents) nodes in the DNS 126 tree, for example, "host.example.com.local.arpa." and 127 "child.host.example.com.local.arpa.". In this example (unless this 128 limitation introduced) the multicast query for an A record for the name 129 "child.host.example.com.local.arpa." would cause two authoritative 130 responses: name error received from "host.example.com.local.arpa.", and 131 requested A record - from "child.host.example.com.local.arpa.". To 132 prevent such ambiguity, we could propose to implement multicast enabled 133 devices to perform a dynamic update of the parent (or grandparent) zone 134 with a delegation to a child zone, in this example a host 135 "child.host.example.com.local.arpa." would send a dynamic update for 136 the NS and glue A record to the "host.example.com.local.arpa.", but this 137 approach significantly complicates implementation of the multicast DNS 138 and would not be acceptable for a lightweight devices. 140 The response to the multicast query is composed in exactly the same 141 manner as in case of a response to the unicast DNS query as specified 142 in [4]. Responders MUST never respond using cached data, and the AA 143 (Authoritative Answer) bit MUST be set. The response is sent to the 144 sender via unicast. If a TC (truncation) bit is set in the response, 145 then the sender MAY use the response if it contains all necessary 146 information, or the sender MAY discard the response and resend the query 147 over TCP or using EDNS0 with larger window using unicast address of the 148 responder. The RA (Recursion Available) bit in the header of the 149 response MUST NOT be set. Even if the RA bit is set in the response 150 header, the sender MUST ignore it. The responder MUST set the Hop Limit 151 field in IPv6 header and TTL field in IPv4 header of all responses to 152 the multicast DNS query to 255. The sender MUST verify that the Hop 153 Limit field in IPv6 header and TTL field in IPv4 header of each response 154 to the multicast DNS query is set to 255. If it is not, then sender MUST 155 ignore such response. 157 The responder should use a pre-configured TTL [5] value in the records 158 returned in the multicast DNS query response. Due to the TTL 159 minimalization necessary when caching an RRset, all TTLs in an RRset 160 MUST be set to the same value. 162 The responder includes in the additional and authority section of the 163 response the same records, as a DNS server would insert in the response 164 to the unicast DNS query. 166 Sender MUST anticipate receiving no replies to some multicasted queries, 167 in the event that no responders are available within the multicast 168 scope, or in the event that no positive non-null responses exist to the 169 transmitted query. 171 If no positive response is received, a resolver treats it as a response 172 that no records of the specified type and class for the specified name 173 exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT 174 exceed 5 seconds. 176 Sender MUST anticipate receiving multiple replies to the same 177 multicasted query, in the event that several multicast DNS enabled 178 computers receive the query and respond with valid answers. When this 179 occurs, the responses MAY first be concatenated, and then treated in the 180 same manner that multiple RRs received from the same DNS server would, 181 ordinarily. 183 3. Usage model 185 A device configured to be a "responder" may also be a "sender". A device 186 configured to not be a "responder" cannot be a "sender". 188 Multicast DNS usage is determined by the domain search configuration as 189 well as by special treatment of the ".local.arpa." namespace. Any 190 device whose domain search configuration contains ".local.arpa." domain 191 is configured to behave as "responder". A device configured to be a 192 "responder" may also be a "sender". A device cannot be configured to 193 behave as one (i.e. sender or responder), but not another. The sender 194 treats queries for ".local.arpa." as a special case. The domain search 195 list can be configured manually or automatically via a DHCP option. 197 A sender MUST NOT send a unicast query for names ending with the 198 ".local.arpa." suffix except in the case when a sender repeats a query 199 over TCP after it received a response to the previous multicast query 200 with TC bit set or unless sender's cache contains NS resource record 201 that enables sender to send a query directly to the devices 202 authoritative for the name in query. 204 It is not expected that a device "host.example.com." will be manually 205 configured to have additional name "host.example.com.local.arpa." when 206 it is configured to use multicast DNS. Instead, a responder with a name 207 "host.example.com." configured with ".local.arpa." suffix in its domain 208 search configuration is authoritative for the name 209 "host.example.com.local.arpa.". I.e. when responder with the name 210 "host.example.com." receives an A type query for the name 211 "host.example.com.local.arpa." it authoritatively responds to the query. 213 If ".local.arpa" is not in the domain search list, then multicast DNS 214 MUST NOT be used by a device. This implies that the device will neither 215 listen on the DNS LINKLOCAL multicast address, nor will it send queries 216 to that address. An auto-configured host will typically have 217 ".local.arpa" first in its search list so that it will be enabled to 218 use mDNS. Typically an enterprise host will not have ".local.arpa" in 219 its search list at all so that it will not use mDNS. 221 The same device may use multicast DNS queries for the name resolution of 222 the names ending with ".local.arpa.", and unicast DNS queries for name 223 resolution of all other names. When a DNS client is requested by a user 224 or application to perform a name resolution of a dot-terminated name 225 that contains a ".local.arpa" suffix, a query for such name MUST be 226 multicasted and such name should not be concatenated with any suffix. 228 If a DNS server is running on a device, the device MUST NOT listen for 229 the multicast DNS queries, to prevent a device from listening on port 53 230 and intercepting DNS queries directed to a DNS server. A DNS server may 231 listen and respond to the multicast queries. A DNS server by default 232 doesn't listen to the multicast DNS queries. Presence of the 233 ".local.arpa." in the domain search list doesn't affect the 234 configuration on the DNS server. 236 4. Sequence of events 238 The sequence of events for usage of multicast DNS is as follows: 240 1. If a sender needs to resolve a query for a name 241 "host.example.com.local.arpa", then it sends a multicast query to the 242 LINKLOCAL multicast address. 244 2. A responder responds to this query only if it is authoritative 245 for the domain name "host.example.com.local.arpa". The responder sends 246 a response to the sender via unicast over UDP. 248 3. Upon the reception of the response the sender verifies that the Hop 249 Limit field in IPv6 header or TTL field in IPv4 header (depending on 250 used protocol) of the response is set to 255. If it is, then sender 251 uses and caches the returned response. If not, then the sender ignores 252 the response and continues waiting for the response. 254 5. Name conflicts 256 It is required to verify the uniqueness of the host DNS name when a host 257 boots, when its name is changed, or when it is configured to use 258 multicast DNS (such as when the domain search option is changed to 259 include ".local.arpa."). 261 A gratuitous name resolution query SHOULD be done to check for a name 262 conflict. This is done by having the resolver send a multicast query for 263 a SOA type query for its own name (i.e. for the name it is authoritative 264 for). If the query is not positively resolved then host assumes 265 authority for the name. If the query is positively resolved, then the 266 host should verify that the computer name specified in the RDATA of the 267 SOA record in the answer section of the response is its own computer 268 name. If the host verifies it, then it assumes authority for its name. 269 If the host cannot match the returned computer name to its computer 270 name, then a conflict has been detected. In order to resolve name 271 conflict, the host will change the name. 273 A host that has detected a name conflict MUST NOT use the name. This 274 means that the host MUST NOT respond to multicast queries for that name 275 and MUST NOT respond to other multicast queries with the records that 276 contain in RDATA name in conflict (for example, PTR record). 278 Note that this name conflict detection mechanism doesn't prevent name 279 conflicts when previously separate networks are connected by a bridge. 280 Name conflict in such situation is detected when a sender receives more 281 than one response to its multicasted DNS query. Such sender sends using 282 unicast the first response that it received to all responders, except 283 the first one, that responded to this query. A host that receives a 284 response for a query for it's own name, even if it didn't send such 285 query, sends a multicast query for the SOA record for the name that it 286 is authoritative for. Based on the response the host detects the name 287 conflict and acts according to the description above. 289 6. IANA Considerations 291 Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses. 293 7. Security Considerations 295 This draft does not prescribe a means of securing the multicast DNS 296 mechanism. It is possible that hosts will allocate conflicting names for 297 a period of time, or that non-conforming hosts will attempt to deny 298 service to other hosts by allocating the same name. Such attacks also 299 allow nodes to receive packets destined for other nodes. The protocol 300 reduces the exposure to such threats in the absence of authentication 301 by ignoring multicast DNS query response packets received from off-link 302 senders. The Hop Limit field in IPv6 and TTL field in IPv4 of all 303 received packets is verified to contain 255, the maximum legal value. 304 Because routers decrement the Hop Limit on all packets they forward, 305 received packets containing a Hop Limit of 255 must have originated 306 from a neighbor. 308 These threats are most serious in wireless networks such as 802.11, 309 since attackers on a wired network will require physical access to the 310 home network, while wireless attackers may reside outside the home. In 311 order to provide for privacy equivalent to a wired network, the 802.11 312 specification provides for RC4-based encryption. This is known as the 313 "Wired Equivalency Privacy" (WEP) specification. Where WEP is 314 implemented, an attacker will need to obtain the WEP key prior to 315 gaining access to the home network. 317 The mechanism specified in this draft does not require use of the 318 DNSSEC, which means that the responses to the multicast DNS queries may 319 not be authenticated. If a network contains a "signed key distribution 320 center" for all (or at least some) of the DNS zones that the responders 321 are authoritative for, then those devices on such a network are 322 configured with the key for the top zone, "local.arpa." (hosted by 323 "signed keys distribution center") may use DNSSEC for the authentication 324 of the responders using DNSSEC. 326 8. Acknowledgements 328 The authors would like to thank Stuart Cheshire, Michael Patton, Erik 329 Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark, 330 Myrong Hattig, Bill Manning and James Gilroy for comments on this draft. 332 9. Authors' Addresses 334 Levon Esibov 335 Microsoft Corporation 336 One Microsoft Way 337 Redmond, WA 98052 339 EMail: levone@microsoft.com 340 Bernard Aboba 341 Microsoft Corporation 342 One Microsoft Way 343 Redmond, WA 98052 345 Phone: +1 (425) 936-6605 346 EMail: bernarda@microsoft.com 348 Dave Thaler 349 Microsoft Corporation 350 One Microsoft Way 351 Redmond, WA 98052 353 Phone: +1 (425) 703-8835 354 EMail: dthaler@microsoft.com 356 10. References 358 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 359 Levels", BCP 14, RFC 2119, March 1997. 361 [2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 362 2365, July 1998. 364 [3] Aboba, B., "The Mini-DHCP Server", Internet draft (work in 365 progress), draft-aboba-dhc-mini-01.txt, April 2000. 367 [4] Mockapetris, P., "Domain Names - Implementation and Specification", 368 RFC 1035, November 1987. 370 [5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 371 RFC 1034, November 1987. 373 11. Intellectual Property Statement 375 The IETF takes no position regarding the validity or scope of any 376 intellectual property or other rights that might be claimed to pertain 377 to the implementation or use of the technology described in this 378 document or the extent to which any license under such rights might or 379 might not be available; neither does it represent that it has made any 380 effort to identify any such rights. Information on the IETF's 381 procedures with respect to rights in standards-track and standards- 382 related documentation can be found in BCP-11. Copies of claims of 383 rights made available for publication and any assurances of licenses to 384 be made available, or the result of an attempt made to obtain a general 385 license or permission for the use of such proprietary rights by 386 implementors or users of this specification can be obtained from the 387 IETF Secretariat. 389 The IETF invites any interested party to bring to its attention any 390 copyrights, patents or patent applications, or other proprietary rights 391 which may cover technology that may be required to practice this 392 standard. Please address the information to the IETF Executive 393 Director. 395 12. Full Copyright Statement 397 Copyright (C) The Internet Society (2000). All Rights Reserved. 398 This document and translations of it may be copied and furnished to 399 others, and derivative works that comment on or otherwise explain it or 400 assist in its implementation may be prepared, copied, published and 401 distributed, in whole or in part, without restriction of any kind, 402 provided that the above copyright notice and this paragraph are included 403 on all such copies and derivative works. However, this document itself 404 may not be modified in any way, such as by removing the copyright notice 405 or references to the Internet Society or other Internet organizations, 406 except as needed for the purpose of developing Internet standards in 407 which case the procedures for copyrights defined in the Internet 408 Standards process must be followed, or as required to translate it into 409 languages other than English. The limited permissions granted above are 410 perpetual and will not be revoked by the Internet Society or its 411 successors or assigns. This document and the information contained 412 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 413 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 414 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 415 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 416 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 418 13. Expiration Date 420 This memo is filed as , and expires 421 May 16, 2001.