idnits 2.17.1 draft-aboba-dnsext-mdns-01.txt: ** The Abstract section seems to be numbered 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? == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 296 has weird spacing: '... Option to D...' == Line 297 has weird spacing: '...uration in I...' == Line 308 has weird spacing: '...imed to perta...' == Line 352 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 (14 July 2000) is 8658 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) == Unused Reference: '2' is defined on line 255, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 264, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 267, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 270, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 277, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 281, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 285, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 289, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 293, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 296, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 302, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-aboba-dhc-mini-01 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Historic draft: draft-ietf-mboned-mzap (ref. '10') == Outdated reference: A later version (-12) exists of draft-ietf-dhc-dhcp-dns-11 -- Possible downref: Normative reference to a draft: ref. '12' Summary: 6 errors (**), 0 flaws (~~), 22 warnings (==), 6 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 14 July 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 1. Copyright Notice 30 Copyright (C) The Internet Society (2000). All Rights Reserved. 32 2. 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 3. 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 the 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 4. Terminology 58 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 59 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 60 described in [1]. 62 5. Name resolution using Multicast DNS 64 This extension to the DNS protocol consists of a single change to the 65 method of use, and no change whatsoever to the current format of DNS 66 packets. Namely, this extension allows multicast DNS queries to be sent 67 to and received on port 53 using the LINKLOCAL addresses for IPv4 and 68 IPv6, which are yet to be assigned by IANA. LINKLOCAL addresses are used 69 since the expectation is that if a network has a router, then this 70 router can function as a mini-DHCP server, as described in [3], and a 71 DNS proxy, possibly implementing dynamic DNS. Thus there is not expected 72 to be a need for use of multicast DNS in networks with multiple 73 segments. 75 Hosts actively using mDNS behave as DNS servers, and inherit all the 76 obligations of DNS servers, as described in [8], including the need to 77 increment the serial number in SOA records. It is suggested that the 78 serial number be taken from a monotonically increasing clock which 79 implies that the serial number will be monotonic across reboots. 80 However, this is not crucial if the DNS TTL is set to a low value. 82 In order to prevent a DNS server from recursive resolution of the 83 multicast DNS queries, the RD (Recursion Desired) bit in the Header 84 section of the query MUST be set to 0. If the RD bit is set to 1, then 85 it is ignored. 87 DNS resolvers configured to use multicast DNS for name resolution listen 88 on port 53 on the LINKLOCAL mDNS address. Responses SHOULD contain a AA 89 (Authoritative Answer) bit set to 0. 91 Issue: Handling of the AA bit was flagged as a subject for more 92 discussion. 94 If a query sent to the LINKLOCAL mDNS addresses is not positively 95 resolved ("positively resolved" refers in this document to the response 96 with the RCODE set to 0) during a limited amount of time, then the 97 resolver MAY repeat the transmission of a query in order to assure 98 themselves that the query has been received by any hosts capable of 99 answering the query. 101 Resolvers MUST anticipate receiving no replies to some multicasted 102 queries, in the event that no multicast-enabled clients are available 103 within the multicast scope, or in the event that no positive non-null 104 responses exist to the transmitted query. 106 If no positive response is received, a resolver treats it as a response 107 that no records of the specified type and class for the specified name 108 exist (NXRRSET), which should be cached according to RFC 2308 [15]. 110 6. Usage model 112 Multicast DNS usage is determined by the domain search configuration as 113 well as by special treatment of the ".lcl.arpa" namespace. The resolver 114 treat queries for ".lcl.arpa" as a special case, thus avoiding the need 115 to formally allocate a new top level domain. The domain search list can 116 be configured manually or automatically via a DHCP option. There is 117 therefore no need for another mDNS configuration mechanism. 119 The resolver will always do a multicast query for names in the 120 ".lcl.arpa" namespace if there is no NS record corresponding to the 121 name. mDNS is only used to resolve unqualified names. This means, for 122 example, that queries for "www.microsoft.com" will never be resolved via 123 mDNS. 125 If ".lcl.arpa" is not in the domain search list, then mDNS MUST NOT be 126 used by that host. An auto-configured host will typically have 127 ".lcl.arpa" first in its search list so that it will be enabled to use 128 mDNS. Typically an enterprise host will not have ".lcl.arpa" in its 129 searchlist at all so that it will not use mDNS. 131 6.1. Sequence of events 133 The sequence of events for usage of multicast DNS is as follows: 135 1. A host multicasts a query for ANY record for a name within 136 the ".lcl.arpa" domain. The query is sent to the LINKLOCAL 137 multicast address. The response is multicast to the LINKLOCAL 138 address, and uses DNS TTL=0, with the exception of NS, which 139 uses a default TTL, with a value TBD. 141 2. Hosts only respond to queries if they are the name server for 142 the domain (e.g. they are foo.lcl.arpa). Hosts never 143 respond based on cached information. The responding host 144 responds with SOA and NS records. 146 3. Now that the querying host has discovered the name server for the 147 domain, subsequent queries are sent unicast to the discovered 148 name server. 150 Note that this implies that multicast DNS cannot be used for discovering 151 services (e.g. trying to query for all printers on the segument via a 152 "*._lpr._udp" SRV [4] query). While this is not an objective of the 153 current specification, this functionality may be added in a subsequent 154 extension. 156 Since mDNS queries are sent on to a LINKLOCAL multicast address, mDNS 157 cannot even be used to discover the location of DNS servers off the 158 local segment. As a result, mDNS is not useful for IPv6 or IPv4 DNS 159 server discovery. 161 7. Name conflicts 163 It is required to verify the uniqueness of the host DNS name when a host 164 boots, when its name is changed, or when it is configured to use 165 multicast DNS (such as when the domain search option is changed to 166 include ".lcl.arpa"). 168 A gratuitious name resolution query SHOULD be done to check for a name 169 conflict. This is done by having the resolver send a multicast ANY type 170 query for its own name. If the query is not positively resolved then 171 host starts using its name. If the query is positively resolved, then 172 the host should verify that the IP addresses specified in the response 173 are its own IP addresses, possibly from another adapter. If the host 174 verifies it, then it starts using its name. If the host cannot match the 175 returned A records to its IP addresses, then a conflict has been 176 detected. In order to resolve ownership conflicts, if the host has a 177 lower IP address it will keep the name, else if the device has a higher 178 IP address it will change names. 180 A host that has detected a name conflict and has loses the name election 181 MUST NOT use the name. This means that the host MUST NOT respond to 182 multicast queries for that name and MUST NOT respond to other multicast 183 queries with the records that contain in RDATA name in conflict (for 184 example, PTR record). 186 Note that this name conflict detection mechanism doesn't prevent name 187 conflicts when previously separate networks are connected by a bridge. 188 Name conflict in such situation is detected when a host receives an 189 multicast response to a query for its name or when a client receives 190 more than one response to a multicast query that it sent. A host that 191 receives a response for a query for it's own name, even if it didn't 192 send such query, behaves as if it sent this query. 194 In order to prevent denial of service attacks, it is recommended that 195 "lcl.arpa" be placed last in the domain searchlist. As long as this is 196 the case, there should be no way for a server with a FQDN to encounter 197 name conflict problems which would cause it to become unreachable. 199 8. IANA Considerations 201 Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses. 203 9. Security Considerations 205 This draft does not prescribe a means of securing the multicast DNS 206 mechanism. It is possible that hosts will allocate conflicting names for 207 a period of time, or that non-conforming hosts will attempt to deny 208 service to other hosts by allocating the same name. 210 These threats are most serious in wireless networks such as 802.11, 211 since attackers on a wired network will require physical access to the 212 home network, while wireless attackers may reside outside the home. In 213 order to provide for privacy equivalent to a wired network, the 802.11 214 specification provides for RC4-based encryption. This is known as the 215 "Wired Equivalency Privacy" (WEP) specification. Where WEP is 216 implemented, an attacker will need to obtain the WEP key prior to 217 gaining access to the home network. 219 10. Acknowledgements 221 The authors would like to thank Stuart Cheshire, Michael Patton, Erik 222 Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark, 223 Myrong Hattig and Bill Manning for comments on this draft, provided at 224 the mDNS lunch in Adelaide, Australia on 3/29/00. 226 11. Authors' Addresses 228 Levon Esibov 229 Microsoft Corporation 230 One Microsoft Way 231 Redmond, WA 98052 233 EMail: levone@microsoft.com 235 Bernard Aboba 236 Microsoft Corporation 237 One Microsoft Way 238 Redmond, WA 98052 240 Phone: +1 (425) 936-6605 241 EMail: bernarda@microsoft.com 242 Dave Thaler 243 Microsoft Corporation 244 One Microsoft Way 245 Redmond, WA 98052 247 Phone: +1 (425) 703-8835 248 EMail: dthaler@microsoft.com 250 12. References 252 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 253 Levels", BCP 14, RFC 2119, March 1997. 255 [2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 256 2365, July 1998. 258 [3] Aboba, B., "The Mini-DHCP Server", Internet draft (work in 259 progress), draft-aboba-dhc-mini-01.txt, April 2000. 261 [4] Gulbrandsen, A., Vixie, P., Esibov, L. "A DNS RR for specifying the 262 location of services (DNS SRV)", RFC 2782, February 2000. 264 [5] Braden, R., "Requirements for Internet Hosts -- Application and 265 Support", RFC 1123, October 1989. 267 [6] Hanna, S., Patel, B., and Shah, M., "Multicast Address Dynamic 268 Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. 270 [7] Gulbrandsen, A., "A DNS RR for encoding DHCP information", Internet 271 draft (work in progress), draft-ietf-dnsind-dhcp-rr-00.txt, October 272 1999. 274 [8] Mockapetris, P., "Domain Names - Implementation and Specification", 275 RFC 1035, November 1987. 277 [9] IANA, "Single-source IP Multicast Address Range", 278 http://www.isi.edu/in-notes/iana/assignments/single-source- 279 multicast, October 1998. 281 [10] Handley, M., Thaler, D., and Kermode, R., "Multicast-Scope Zone 282 Announcement Protocol (MZAP)", Work in progress, draft-ietf-mboned- 283 mzap-06.txt, December, 1999. 285 [11] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear, 286 E., "Address Allocation for Private Internets", RFC 1918, February, 287 1996. 289 [12] Stapp, M., Rekhter, Y., "Interaction between DHCP and DNS", 290 Internet draft (work in progress), draft-ietf-dhc-dhcp-dns-11.txt, 291 October 1999. 293 [13] Vixie, P., et. al., "Dynamic Updates in the Domain Name System (DNS 294 UPDATE)", RFC 2136, April, 1997. 296 [14] Troll, R., "DHCP Option to Disable Stateless Auto- 297 Configuration in IPv4 Clients", RFC 2563, May 1999. 299 [15] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 300 2308, March 1998. 302 [16] Auerbach, K., "PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP 303 TRANSPORT: CONCEPTS AND METHODS", RFC 1001, March, 1987. 305 13. Intellectual Property Statement 307 The IETF takes no position regarding the validity or scope of any 308 intellectual property or other rights that might be claimed to pertain 309 to the implementation or use of the technology described in this 310 document or the extent to which any license under such rights might or 311 might not be available; neither does it represent that it has made any 312 effort to identify any such rights. Information on the IETF's 313 procedures with respect to rights in standards-track and standards- 314 related documentation can be found in BCP-11. Copies of claims of 315 rights made available for publication and any assurances of licenses to 316 be made available, or the result of an attempt made to obtain a general 317 license or permission for the use of such proprietary rights by 318 implementors or users of this specification can be obtained from the 319 IETF Secretariat. 321 The IETF invites any interested party to bring to its attention any 322 copyrights, patents or patent applications, or other proprietary rights 323 which may cover technology that may be required to practice this 324 standard. Please address the information to the IETF Executive 325 Director. 327 14. Full Copyright Statement 329 Copyright (C) The Internet Society (2000). All Rights Reserved. 330 This document and translations of it may be copied and furnished to 331 others, and derivative works that comment on or otherwise explain it or 332 assist in its implmentation may be prepared, copied, published and 333 distributed, in whole or in part, without restriction of any kind, 334 provided that the above copyright notice and this paragraph are included 335 on all such copies and derivative works. However, this document itself 336 may not be modified in any way, such as by removing the copyright notice 337 or references to the Internet Society or other Internet organizations, 338 except as needed for the purpose of developing Internet standards in 339 which case the procedures for copyrights defined in the Internet 340 Standards process must be followed, or as required to translate it into 341 languages other than English. The limited permissions granted above are 342 perpetual and will not be revoked by the Internet Society or its 343 successors or assigns. This document and the information contained 344 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 345 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 346 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 347 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 348 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 350 15. Expiration Date 352 This memo is filed as , and expires 353 February 1, 20001.