idnits 2.17.1 draft-cheshire-dnsext-multicastdns-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 ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 8 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 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 (July 2001) is 8321 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802' -- Possible downref: Normative reference to a draft: ref. 'NIAS' ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2673 (Obsoleted by RFC 6891) == Outdated reference: A later version (-12) exists of draft-ietf-zeroconf-reqts-08 ** Downref: Normative reference to an Informational draft: draft-ietf-zeroconf-reqts (ref. 'ZC') Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Stuart Cheshire 2 Document: draft-cheshire-dnsext-multicastdns-00.txt Apple Computer 3 Expires 13th January 2002 13th July 2001 5 Performing DNS queries via IP Multicast 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), 14 its areas, and its working groups. Note that other groups may 15 also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material 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 Distribution of this memo is unlimited. 30 Abstract 32 Multicast DNS is a really obvious idea, whose time has finally come. 33 This draft proposes one possible way of making it work. 35 1. Acknowledgements 37 This work builds upon original work done on Multicast DNS by Bill 38 Manning and Bill Woodcock. The authors gratefully acknowledge their 39 contribution to the current specification. Other contributors of 40 valuable ideas include Bernard Aboba, Mark Andrews, Randy Bush, Levon 41 Esibov, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, 42 Thomas Narten, Erik Nordmark and Dave Thaler. 44 I apologize humbly to anyone who feels their work has not been 45 properly credited and I offer to buy dinner or drinks in 46 compensation. 48 2. Introduction 50 This is a rough first draft. Its purpose is to describe the proposed 51 idea well enough for meaningful discussion to take place. As such, 52 while feedback concerning typographical mistakes and similar minutiae 53 is always appreciated, the reader is advised that it is probably 54 unwise to waste a lot of time on such trivia until after we find out 55 whether this proposal will even live long enough to become a 56 'draft-01'. 58 When reading this document, familiarity with the concepts of Zero 59 Configuration Networking [ZC] and automatic link-local addressing 60 [v4LL] [RFC 2462] is helpful. 62 This document proposes no change to the structure of DNS messages, 63 and no new operation codes, response codes, resource record types, or 64 any other new DNS protocol values. This document simply discusses 65 what needs to happen if DNS clients start sending DNS requests to a 66 multicast address. 68 The primary difference between this document and "draft-ietf-dnsext- 69 mdns-01.txt" is the philosophy about how subdomains of the 70 "local.arpa." domain are delegated. That document proposes that hosts 71 running Multicast DNS Responders each assert an SOA record, thereby 72 claiming to be the sole authority for their own little zone within 73 the "local.arpa." domain. That approach makes it difficult for 74 different hosts to manage two or more resource records with the same 75 name, a feature that has some benefits. This document proposes that 76 subdomains of the "local.arpa." domain can never be delegated, and 77 instead "local.arpa." is managed as a single zone implemented by 78 a loose collection of hosts cooperatively executing a distributed 79 algorithm. From that philosophical difference, a variety of 80 implementation differences emerge. 82 There has been discussion of whether "local.arpa." is an appropriate 83 domain to use. Perhaps it is not. Perhaps some other domain should, 84 by IETF Standards Action, be declared a reserved name in the DNS 85 protocol for this particular use. In any case, the text "local.arpa." 86 in this document should be taken as a place holder for whatever 87 reserved name or "domain" may eventually be allocated for this 88 purpose. 90 There has been discussion of how much burden Multicast DNS might 91 impose on a network. It should be remembered that whenever IPv4 hosts 92 communicate they broadcast ARP packets on the network on a regular 93 basis, and this is not disastrous. The approximate amount of 94 multicast traffic generated by hosts using Multicast DNS is 95 anticipated to be roughly the same order of magnitude as the amount 96 of broadcast ARP traffic those hosts already generate. 98 3. Conventions and Terminology Used in this Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in "Key words for use in 103 RFCs to Indicate Requirement Levels" [RFC 2119]. 105 This document uses the term "host name" in the strict sense to mean a 106 fully qualified domain name that has an address record. It does not 107 use the term "host name" in the commonly used but incorrect sense to 108 mean just the first DNS label of a host's fully qualified domain 109 name. 111 4. Multicast DNS Names 113 The DNS domain "local.arpa." is (this document proposes) a 114 special domain with special semantics, namely that "local.arpa." and 115 all its subdomains are link-local, and names within this domain are 116 meaningful only on the link where they originate, much as IPv4 117 addresses in the 169.254/16 prefix are link-local and meaningful 118 only on the link where they originate. 120 Any DNS query for a name within the "local.arpa." domain MUST be sent 121 to the all-DNS multicast address (224.0.0.251 or its IPv6 122 equivalent). 124 It is unimportant whether a name within the "local.arpa." domain 125 occurred because the user explicitly typed in a fully qualified 126 domain name ending in "local.arpa.", or because the user entered an 127 unqualified domain name and the host software appended the 128 "local.arpa." search domain to it. The "local.arpa." domain could 129 appear in the search list because the user manually configured it, or 130 because it was received in a DHCP option, or via any other valid 131 mechanism for configuring the DNS search list. In this respect the 132 "local.arpa." domain is no different to any other search domain that 133 might appear in the list. 135 DNS queries for a names outside the "local.arpa." domain MAY be sent 136 to the all-DNS multicast address, if no other conventional DNS server 137 is available. This can allow hosts on the same link to continue 138 communicating using each other's globally unique DNS names during 139 network outages which disrupt communication with the greater 140 Internet. This is a contentious issue, and this document does not 141 discuss it in detail, instead concentrating on the issue of resolving 142 local names using DNS packets sent to a multicast address. 144 A host which belongs to an organization that owns some portion of the 145 DNS namespace can be assigned a globally unique name within that 146 portion of the DNS namespace, for example, "cheshire.apple.com." 147 Another host, attempting and failing to resolve that name via 148 conventional unicast DNS MAY elect to try resolving it via multicast, 149 which may be successful if the two hosts happen to be on the same 150 link. 152 However, the majority home customers do not have easy access to any 153 portion of the global DNS namespace within which they have the 154 authority to create names as they wish. This leaves the majority of 155 home computers effectively anonymous for practical purposes. These 156 users MAY elect to give their computers link-local host names of the 157 form: "single-dns-label.local.arpa." For example, my laptop computer 158 answers to the name "stu.local.arpa." Any computer user is granted 159 the authority to name their computer this way, providing that the 160 chosen host name is not already in use on that link. Having named 161 their computer this way, the user has the authority to continue using 162 that name until such time as name conflict occurs on the link which 163 is not resolved in the user's favour. When this happens, the computer 164 (or its human user) SHOULD cease using the name, and may choose to 165 attempt to allocate a new unique name for use on that link. 167 The point made in the previous paragraph is very important and bears 168 repeating. It is easy for those of us in the IETF community who run 169 our own name servers at home to forget that the majority of computer 170 users do not run their own name server and have no easy way to create 171 their own host names. When these users wish to transfer files between 172 two laptop computers, they are frequently reduced to typing in 173 dotted-decimal IP addresses because they simply have no other way 174 for one host to refer to the other by name. This is a sorry state of 175 affairs. 177 Allowing ad-hoc allocation of single-label names in a single flat 178 "local.arpa." namespace may seem to invite chaos. However, 179 operational experience with AppleTalk NBP names, which on any given 180 link are also effectively single-label names in a flat namespace, 181 shows that in practice name collisions happen extremely rarely and 182 are not a problem. Groups of computer users from disparate 183 organizations bring Macintosh laptop computers to events such as IETF 184 Meetings, the Mac Hack conference, the Apple World Wide Developer 185 Conference, etc., and complaints at these events about users 186 suffering conflicts and being forced to rename their machines have 187 never been an issue. 189 Enforcing uniqueness of host names (i.e. the names of DNS address 190 records mapping names to IP addresses) is probably desirable in the 191 common case, but this document does not mandate that. It is also 192 permissible for a collection of coordinated hosts to agree to 193 maintain multiple DNS address records with the same name, possibly 194 for load balancing or fault-tolerance reasons. This document does not 195 take a position on whether that is sensible, but it is important that 196 the Multicast DNS protocol allows hosts to verify and maintain unique 197 names for resource records where that behaviour is desired, and to 198 maintain multiple resource records with a single shared name where 199 that behaviour is desired. This consideration applies to all resource 200 records, not just address records (i.e. host names). 202 5. IP TTL Checks 204 A host sending a Multicast DNS request to a link-local address MUST 205 verify that the TTL in reply packets is 255, and silently discard any 206 reply packets where the TTL is not 255. Without this check, it could 207 be possible for remote rogue hosts to send spoof answer packets 208 (perhaps unicast to the victim host) which the receiving machine 209 could misinterpret as having originated on the local link. 211 There has been some discussion that many current network programming 212 APIs to not provide any indication of the TTL on received packets. 213 This is unfortunate, and should be fixed for hosts that want to be 214 able to guard against spoof packets arriving from off-link. 216 6. Reverse Address Mapping 218 Like "local.arpa." the domain "254.169.in-addr.arpa." is defined to 219 be link-local. Any DNS query for a name within the "254.169.in-addr. 220 arpa." domain MUST be sent to the all-DNS multicast address 221 224.0.0.251. 223 7. Requesting 225 There are three kinds of Multicast DNS Requests, one-shot requests of 226 the kind made by today's conventional DNS clients, one-shot requests 227 accumulating multiple replies made by multicast-aware DNS clients, 228 and continuous ongoing Multicast DNS Requests used by IP network 229 browser software. 231 A Multicast DNS Responder that is offering records that are intended 232 to be unique on the local link MUST also implement a Multicast DNS 233 Requester so that it can first verify the uniqueness of those records 234 before it begins answering requests for them. 236 7.1 One-Shot Requests 238 An unsophisticated DNS client may simply send its DNS requests 239 blindly to the 224.0.0.251 multicast address, without necessarily 240 even being aware what a multicast address is. Indeed, certain 241 existing DNS clients (e.g. Mac and Windows) can be persuaded to do 242 this even today, simply by the user typing in that address as the 243 'name server address'. 245 Such an unsophisticated DNS client may not get ideal behaviour. Such 246 a client may simply take the first response it receives and fail to 247 wait to see if there are more, but in many instances this may not be 248 a serious problem. If a user types "http://stu.local.arpa." into 249 their Web browser and gets to see the page they were hoping for, then 250 the protocol has met the user's needs in this case. 252 7.2 One-Shot Requests, Accumulating Multiple Replies 254 A more sophisticated DNS client should understand that Multicast DNS 255 is not exactly the same as unicast DNS, and should modify its 256 behaviour in some simple ways. 258 As described above, there are some cases, such as looking up the 259 address associated with a unique host name, where a single response 260 is sufficient, and moreover may be all that is expected. However, 261 there are other DNS requests where more than one response is 262 possible, and for these requests a more sophisticated Multicast DNS 263 client should include the ability to wait for an appropriate period 264 of time to collect multiple responses. 266 A naive DNS client retransmits its request only so long as it has 267 received no reply. A more sophisticated Multicast DNS client is aware 268 that having received one response is not necessarily an indication 269 that it might not receive others, and has the ability to retransmit 270 its request an appropriate number of times at appropriate intervals 271 until it is satisfied with the collection of responses it has 272 gathered. 274 A more sophisticated Multicast DNS client that is retransmitting a 275 request for which is has already received some replies, MAY elect to 276 implement duplicate suppression, as described below under "Duplicate 277 Suppression". This indicates to responders who have already replied 278 that their responses have been received, and they don't need to send 279 them again in response to this repeated request. 281 A Multicast DNS Requester MAY place more than one question into the 282 Question Section of a Multicast DNS Request. 284 7.3 Continuous Requesting 286 In One-Shot Requests, with either a single or multiple responses, the 287 underlying assumption is that the transaction begins when the 288 application issues a request, and ends when all the desired responses 289 have been received. There is another type of operation which is more 290 akin to continuous monitoring. 292 Macintosh users are accustomed to opening the "Chooser" window, 293 selecting a desired printer, and then closing the Chooser window. 294 However, when the desired printer does not appear in the list, the 295 user will typically leave the "Chooser" window open while they go and 296 check to verify that the printer is plugged in, powered on, connected 297 to the Ethernet, etc. While the user jiggles the wires, hits the 298 Ethernet hub, and so forth, they keep an eye on the Chooser window, 299 and when the printer name appears, they know they have fixed whatever 300 the problem was. This can be a useful and intuitive troubleshooting 301 technique, but a user who goes home for the weekend leaving the 302 Chooser window open places a non-trivial burden on the network. 304 It is important that an IP network browser window displaying 305 live information from the network using Multicast DNS, if left 306 running for an extended period of time, should generate significantly 307 less multicast traffic on the network than the old AppleTalk Chooser. 309 A Multicast DNS Requester asking the same question repeatedly for an 310 indefinite period of time MUST implement duplicate suppression, as 311 described below. 313 8. Duplicate Suppression 315 When a Multicast DNS Requester sends a request to which it already 316 knows some answers, it populates the Answer Section of the DNS 317 message with those cached resource records whose remaining TTL values 318 indicate that they will remain valid for at least the time 319 anticipated to send this DNS request, and the next, and the one after 320 that. For example, if the Multicast DNS Requester is planning to wait 321 four seconds after this request before sending the next, and then 322 eight seconds after that, then only resource records with TTL values 323 greater than twelve seconds should be included in the answer section. 324 This is to ensure that when a resource record's TTL is close to 325 expiration, the Multicast DNS Requester has *two* chances to refresh 326 it before the cached record expires and has to be removed from the 327 list. 329 A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Request 330 if the answer it would give is already included in the Answer 331 Section with a TTL at least half the correct value. If the TTL of the 332 answer as given in the Answer Section is less than half of the real 333 TTL as known by the Multicast DNS Responder, the responder SHOULD 334 send an answer so as to update the Requester's cache before the 335 record becomes in danger of expiration. 337 A Multicast DNS Requester MUST NOT cache resource records observed in 338 the Answer Section of other Multicast DNS Requests. The Answer 339 Section of Multicast DNS Requests is not authoritative. By placing 340 information in the Answer Section of a Multicast DNS Request the 341 requester is stating that it *believes* the information to be true. 342 It is not asserting that the information *is* true. Some of those 343 records may have come from other hosts that are no longer on the 344 network. Propagating that stale information to other Multicast DNS 345 Requesters on the network would not be helpful. 347 A Multicast DNS Responder that implements duplicate suppression 348 SHOULD implement EDNS0 [RFC 2671] to allow larger-sized requests and 349 replies. 351 9. Responding 353 A Multicast DNS Responder MUST only reply when it has a positive 354 non-null response to send. Error responses must never be sent. The 355 non-existence of any name in a Multicast DNS Domain is ascertained by 356 the failure of any machine to respond to the Multicast DNS query, not 357 by NXDOMAIN errors. 359 A Multicast DNS Responder on Ethernet [IEEE802] and similar shared 360 multiple access networks SHOULD delay its responses by a random 361 amount of time selected with uniform random distribution in the range 362 0-10ms. If multiple Multicast DNS Responders were all to immediately 363 reply to a particular request, a collision would be virtually 364 guaranteed. By imposing a small random delay, the number of 365 collisions is dramatically reduced. 10ms is a short enough time that 366 it is not perceptible to a human user, but long enough to 367 significantly reduce the risk of Ethernet collisions. On a full-sized 368 Ethernet using the maximum cable lengths allowed and the maximum 369 number of repeaters allowed, an Ethernet frame is vulnerable to 370 collisions during the transmission of its first 256 bits. On 10Mb/s 371 Ethernet, this equates to a vulnerable time window of 25.6us. 373 In the case where a Multicast DNS Responder has good reason to 374 believe that it will be the only responder on the link with a 375 positive non-null response, it MAY reply immediately, without the 376 random delay. To do this safely, it MUST have previously verified 377 that the requested name type and class in the DNS query are unique on 378 this link. This may be appropriate for things like looking up the 379 address record for a particular host name, when the host name has 380 been previously verified unique. This is *not* appropriate for things 381 like looking up PTR records used for DNS Service Discovery [NIAS], 382 where a large number of responses may be anticipated. 384 Multicast DNS Responses MUST be sent to UDP port 53 (the well-known 385 port assigned to DNS) on the 224.0.0.251 multicast address. Operating 386 in a Zeroconf environment requires constant vigilance. Just because a 387 name has been previously verified unique does not mean it will 388 continue to be so indefinitely. By allowing all Multicast DNS 389 Responders to constantly monitor their peers' responses, conflicts 390 arising out of network topology changes can be promptly detected and 391 resolved. 393 If the source UDP port in a received Multicast DNS Request is not 394 port 53, this suggests that the client originating the request is an 395 old naive client that is not entirely aware that it is using a 396 multicast address. (The host OS needs to understand what an IP 397 multicast address is in order to hash it to the correct Ethernet 398 multicast address, but the user-level DNS client software does not 399 need to know anything about multicast to blindly send a UDP packet to 400 the IP address 224.0.0.251.) In this case, after sending the usual 401 Multicast DNS Response to 224.0.0.251 port 53, the Multicast DNS 402 Responder MUST also send a second identical UDP reply to the client 403 via unicast to the request packet's source IP address and port. 405 Multicast DNS Responders MUST correctly handle DNS request packets 406 containing more than one question, by answering any or all of the 407 questions to which they have answers. 409 Multicast DNS Responders SHOULD implement EDNS0 [RFC 2671] to allow 410 larger-sized requests and replies. Larger-sized requests are useful 411 to allow longer duplicate suppression lists in the Answer Section. 413 10. Startup Procedure 415 Whenever a Multicast DNS Responder starts up, wakes up from sleep, 416 receives an indication of an Ethernet 'Link Change' event, or has any 417 other reason to believe that its network connectivity may have 418 changed in some relevant way, it MUST perform two startup steps. 420 The first startup step is that for all those resource records that a 421 Multicast DNS Responder desires to be unique on the local link, it 422 MUST send a Multicast DNS Query asking for those resource records, to 423 see if any of them are already in use. The primary example of this is 424 its address record which maps its unique host name to its unique IP 425 address. The ability to place more than one question in a Multicast 426 DNS Request is useful here, because it can allow a host to use a 427 single packet for all of its resource records instead of needing a 428 separate packet for each. If any conflicting Multicast DNS replies 429 are received, then the host MUST defer to the other host already 430 using those names, and MUST select new names for its conflicting 431 records which need to be unique. One second after the first query it 432 should send a second, then two seconds after that a third. If, after 433 a total of seven seconds, no conflicting Multicast DNS replies have 434 been received, the host may move to the second step. 436 The second startup step is that the Multicast DNS Responder SHOULD 437 send a gratuitous Multicast DNS Response containing, in the Answer 438 Section, all those resource records that may be of interest to other 439 hosts on the link. One example of this is the PTR records used by DNS 440 Service Discovery [NIAS]. Since other hosts running Multicast DNS 441 Requesters may have network browser windows open using an extremely 442 long interval between Multicast DNS Request packets, the reception of 443 a gratuitous Multicast DNS Response from a new device starting up 444 allows the browser window to update immediately instead of having to 445 wait until the next request is sent. 447 Up to ten of gratuitous Multicast DNS Responses may be sent, 448 providing that the interval between gratuitous responses doubles 449 with every response sent, and the interval between the first two 450 gratuitous responses is not less than one second. 452 Whenever a Multicast DNS Responder receives any Multicast DNS 453 response (gratuitous or otherwise) containing a conflicting resource 454 record, the conflict MUST be resolved as described below in "Conflict 455 Resolution". 457 A Multicast DNS Responder MUST NOT send announcements in the absence 458 of information that its network connectivity may have changed in some 459 relevant way. In particular, a Multicast DNS Responder MUST NOT send 460 regular periodic announcements as a matter of course. 462 11. Conflict Resolution 464 A conflict occurs when two resource records with the same name, type 465 and class have inconsistent rdata. What may be considered 466 inconsistent is context sensitive, except that resource records with 467 identical rdata are never considered inconsistent, even if they 468 originate from different hosts. In the case of a host desiring to 469 have a unique host name, another address record with the same name 470 but a different IP address is considered inconsistent. 472 Whenever a Multicast DNS Responder receives any Multicast DNS 473 response (gratuitous or otherwise) containing a conflicting resource 474 record, the Multicast DNS Responder must cease using that record 475 and potentially reconfigure. 477 In the case of a typical laptop or desktop computer with a human 478 user, reconfiguration is achieved by displaying an error message to 479 the user and suggesting that they choose a new name. In the case of a 480 device with no human operator, reconfiguration is achieved by its 481 software programmatically generating a new name. In either case, the 482 host must then test the new name for uniqueness as described above in 483 "Startup Procedure". 485 It is important that the host that believes there is a conflict be 486 the one to take action. In the case of two hosts using the same host 487 name, where one has been configured to require a unique host name and 488 the other has not, the one configured to require a unique host name 489 must be the one to reconfigure, since the other one doesn't view the 490 sharing of address records as a conflict and hence sees no reason why 491 it should reconfigure. This algorithm could result in situations 492 where both hosts reconfigure, but this will be rare. The uniqueness 493 check described above in "Startup Procedure" helps reduces resource 494 record conflicts to only those cases where two separate links are 495 connected together, or a previously partitioned link is re-joined. 497 The examples in this section focus on address records (i.e. host 498 names), but the same considerations apply to all resource records 499 where uniqueness or some other defined constraint is desired. 501 12. Special Characteristics of Multicast DNS Domains 503 Unlike conventional DNS, the DNS domains "local.arpa." and "254.169. 504 in-addr.arpa." have only local significance. Conventional DNS seeks 505 to provide a single unified namespace, where a given DNS query yields 506 the same answer no matter where on the planet it is performed or to 507 which recursive DNS server the query is sent. (However, split views, 508 firewalls, intranets and the like have somewhat interfered with this 509 goal of DNS representing a single universal truth.) In contrast, each 510 IP link has its own private "local.arpa." and "254.169.in-addr.arpa." 511 namespaces, and the answer to any query for a name within those 512 domains depends on where that query is asked. 514 Multicast DNS Domains are not delegated from their parent domain via 515 use of NS records. Instead, all Multicast DNS Domains are delegated 516 to the IP address 224.0.0.251 by (potential) IETF Standards Action 517 (i.e. this document, should it become a standard). There are no NS 518 records anywhere in Multicast DNS Domains. 520 The name server for a Multicast DNS Domain is 224.0.0.251. This is a 521 multicast address; therefore it identifies not a single host but a 522 collection of hosts, working in cooperation to maintain some 523 reasonable facsimile of a competently managed DNS zone. Conceptually 524 a Multicast DNS Domain is a single DNS zone, however its server is 525 implemented as a distributed process running on cluster of loosely 526 cooperating CPUs rather than as a single process running on a single 527 CPU (or tightly coupled multiprocessor). 529 No delegation is performed within Multicast DNS Domains. Because the 530 cluster of loosely coordinated CPUs is cooperating to administer a 531 single zone, no delegation is necessary or desirable. Just because a 532 particular host on the network may answer queries for a particular 533 record type with the name "example.local.arpa." does not imply 534 anything about whether that host will answer for the name 535 "child.example.local.arpa.", or indeed for other record types with 536 the "example.local.arpa." 538 Multicast DNS Zones have no SOA record. A conventional DNS zone's 539 SOA record contains information such as the email address of the zone 540 administrator and the monotonically increasing serial number of the 541 last zone modification. There is no single human administrator for 542 any given Multicast DNS Zone, so there is no email address. Because 543 the hosts managing any given Multicast DNS Zone are only loosely 544 coordinated, there is no readily available monotonically increasing 545 serial number to determine whether or not the zone contents have 546 changed. A host holding part of the shared zone could crash or be 547 disconnected from the network at any time without informing the other 548 hosts. There is no reliable way to provide a zone serial number that 549 would, whenever such a crash or disconnection occurred, immediately 550 change to indicate that the contents of the shared zone had changed. 552 Zone transfers are not possible for any Multicast DNS Zone. 554 13. Multicast DNS for Service Discovery 556 This document does not describe using Multicast DNS for network 557 browsing or service discovery. However, the mechanisms this document 558 describes are compatible with (and support) the browsing and service 559 discovery mechanisms proposed in "Discovering Named Instances of 560 Abstract Services using DNS" [NIAS]. 562 This document places few limitations on what DNS record types may be 563 looked up in the "local.arpa." domain. In particular, a Multicast DNS 564 request for the SRV record named "_dns._udp.local.arpa." may yield 565 the port number and host name (and thence IP address) of a 566 conventional DNS server willing to perform general recursive DNS 567 lookups. The benefit of using this mechanism rather than a DHCP 568 option to configure a host's DNS server address is that using DHCP is 569 an outward-looking solution that makes DNS dependent on another 570 protocol, which may not be running on every network (e.g. an IPv6 571 network using stateless address autoconfiguration [RFC 2462]). 572 Locating a recursive DNS server using Multicast DNS is a self- 573 sufficient solution that reduces DNS's need for support from other 574 protocols. This possibility is not discussed futher here. 576 14. Resource Record TTL Values 578 Multicast DNS resource records used in typical 'One-Shot' requests 579 should generally have fairly low TTL values, on the order of seconds, 580 rather than hours or days. The transient nature of Zeroconf networks 581 [ZC] [v4LL] means that information can change at any time, and a host 582 caching ancient stale resource records with unreasonably long TTL 583 values could be left trying to work with hopelessly out-of-date 584 information. 586 Having hosts send gratuitous responses when configuration changes 587 occur can somewhat mitigate this problem, but in the event of a 588 network partition, or temporary signal fade in a wireless network, it 589 is not safe to assume that all hosts will necessarily see all 590 gratuitous responses. 592 The one exception to this recommendation is resource records expected 593 to be used to populate network browser lists, such as the PTR records 594 used for DNS Service Discovery [NIAS]. Using short TTL values here 595 would force the network browser to be continuously sending Multicast 596 DNS Requests to refresh records before they expired from the list. 597 In this case, the harm done by stale data due to high TTL values is 598 relatively mild. The appearance of names in the network browser list 599 is merely an assertion that the name exists now or has existed in the 600 recent past. In order to actually use any named service, the client 601 has to perform another DNS request to find the IP address, and in the 602 case where the service has been forced to reconfigure to a new IP 603 address (or has left the network entirely), the client will quickly 604 discover that. 606 15. Enabling and Disabling Multicast DNS 608 The option to fail-over to Multicast DNS for names outside the 609 "local.arpa." domain SHOULD be a user-configured option, and SHOULD 610 be disabled by default because of the possible security issues 611 related to unintended local resolution of apparently global names. 613 The option to lookup unqualified (relative) names in the 614 "local.arpa." domain (or not) is controlled by whether or not 615 "local.arpa." appears in the client's DNS search list. 617 No special control is needed for enabling and disabling Multicast DNS 618 for names within the "local.arpa." domain. The user doesn't need a 619 way to disable Multicast DNS for names within the "local.arpa." 620 domain, because if the user doesn't want to use Multicast DNS, they 621 can achieve this by simply not using names that end in ".local.arpa." 622 If a user *does* enter a name ending in ".local.arpa." into their Web 623 browser, then we can safely assume their intention was probably that 624 it should work. Having user configuration options that can be 625 (intentionally or unintentionally) set so that this doesn't work is 626 just one more way of frustrating the user's ability to perform the 627 tasks they want, perpetuating the view that, "IP networking is too 628 complicated to configure and too hard to use." This in turn 629 perpetuates the continued use of protocols like AppleTalk, and 630 there's no DHCP option to disable that! If we want to retire 631 AppleTalk, we need to offer users equivalent IP functionality that 632 they can rely on to, "always work, like AppleTalk." A little 633 Multicast DNS traffic may be a burden on the network, but it is an 634 insignificant burden compared to continued widespread use of 635 AppleTalk. 637 16. Considerations for Multiple Interfaces 639 A host should defend its host name (FQDN) on all active interfaces on 640 which it is answering Multicast DNS requests. 642 In the event of a name conflict on *any* interface, a host should 643 configure a new host name, if it wishes to maintain uniqueness of its 644 host name. 646 When answering a Multicast DNS request, a multi-homed host with a 647 link-local address (or addresses) should take care to ensure that 648 any address going out in a Multicast DNS reply is valid for use 649 on the interface on which the reply is going out. 651 Just as the same link-local IP address may validly be in use 652 simultaneously on different links, the same link-local host name may 653 validly be in use simultaneously on different links, and this is not 654 an error. A multi-homed host with connections to two different links 655 may be able to communicate with two different hosts that are validly 656 using the same name. While this kind of name duplication should be 657 rare, it means that a host which wants to fully support this case 658 needs network programming APIs that allow applications to specify on 659 what interface to perform a link-local Multicast DNS request and/or 660 on what interface a Multicast DNS reply was received. 662 17. DNS Message Format 664 This section describes specific restrictions on the allowable 665 values for the header fields of a Multicast DNS message. 667 17.1. ID (Query Identifier) 669 Multicast DNS clients SHOULD listen for gratuitous responses 670 issued by hosts booting up (or waking up from sleep or otherwise 671 joining the network). Since these gratuitous responses may contain a 672 useful answer to a question for which the client is currently 673 awaiting an answer, Multicast DNS clients SHOULD examine all received 674 Multicast DNS response messages for useful answers, without regard to 675 the contents of the ID field or the question section. In multicast 676 DNS, knowing which particular query message (if any) is responsible 677 for eliciting a particular response message is less interesting than 678 knowing whether the response message contains useful information. 680 Multicast DNS clients MAY cache any or all Multicast DNS response 681 messages they receive, for possible future use, providing of course 682 that normal TTL aging is performed on these cashed resource records. 684 In multicast query messages, the Query ID SHOULD be set to zero on 685 transmission. 687 In multicast responses, including gratuitous multicast responses, the 688 Query ID MUST be set to zero on transmission, and MUST be ignored on 689 reception. 691 In unicast response messages generated specifically in response to a 692 particular (unicast or multicast) query, the Query ID MUST match the 693 ID from the query message. 695 17.2. QR (Query/Response) Bit 697 In query messages, MUST be zero. 699 In response messages, MUST be one. 701 17.3. OPCODE 703 In both multicast query and multicast response messages, MUST be zero 704 (only standard queries are currently supported over multicast, unless 705 other queries are allowed by future IETF Standards Action). 707 17.4. AA (Authoritative Answer) Bit 709 In query messages, the Authoritative Answer bit MUST be zero on 710 transmission, and MUST be ignored on reception. 712 In response messages for Multicast Domains, the Authoritative Answer 713 bit MUST be one -- not setting this bit implies there's some other 714 place where 'better' information may be found. 716 17.5. TC (Truncated) Bit 718 In query messages, the Truncated bit MUST be zero on transmission, 719 and MUST be ignored on reception. 721 In response messages, if the message does not contain all the data 722 the requester was looking for, the requester SHOULD open a TCP 723 connection to the responder and repeat the query. 725 17.6. RD (Recursion Desired) Bit 727 In both multicast query and multicast response messages, the 728 Recursion Desired bit MUST be zero on transmission, and MUST be 729 ignored on reception. 731 17.7. RA (Recursion Available) Bit 733 In both multicast query and multicast response messages, the 734 Recursion Available bit MUST be zero on transmission, and MUST be 735 ignored on reception. 737 17.8. Z (Zero) Bit 739 In both query and response messages, the Zero bit MUST be zero on 740 transmission, and MUST be ignored on reception. 742 17.9. AD (Authentic Data) Bit [RFC 2535] 744 In query messages the Authentic Data bit MUST be zero on 745 transmission, and MUST be ignored on reception. 747 In response messages, the Authentic Data bit MAY be set. Resolvers 748 receiving response messages with the AD bit set MUST NOT trust the AD 749 bit unless they trust the source of the message and either have a 750 secure path to it or use DNS transaction security. 752 17.10. CD (Checking Disabled) Bit [RFC 2535] 754 In query messages, a resolver willing to do cryptography SHOULD set 755 the Checking Disabled bit to permit it to impose its own policies. 757 In response messages, the Checking Disabled bit MUST be zero on 758 transmission, and MUST be ignored on reception. 760 17.11. RCODE (Response Code) 762 In both multicast query and multicast response messages, the Response 763 Code MUST be zero on transmission. Multicast DNS messages received 764 with non-zero Response Codes MUST be silently ignored. 766 18. IPv6 Considerations 768 An IPv4-only host and an IPv6-only host behave as "ships that pass in 769 the night". Even if they are on the same Ethernet, neither is aware 770 of the other's traffic. For this reason, each physical link may have 771 *two* unrelated "local.arpa." zones, one for IPv4 and one for IPv6. 772 Since for practical purposes, a group of IPv4-only hosts and a group 773 of IPv6-only hosts on the same Ethernet act as if they were on two 774 entirely separate Ethernet segments, it is unsurprising that their 775 use of the "local.arpa." zone should occur exactly as it would if 776 they really were on two entirely separate Ethernet segments. 778 A dual-stack (v4/v6) host can participate in both "local.arpa." 779 zones, and should register its name(s) and perform its lookups both 780 using IPv4 and IPv6. This enables it to reach, and be reached by, 781 both IPv4-only and IPv6-only hosts. 783 There has been discussion of the proposal that in the IPv6 case, the 784 all-DNS multicast address should not be a single address, but instead 785 a range of addresses selected using a hash function of the name being 786 looked for. There are some issues with this: 788 1. The hash function must work correctly with both normal 789 (case-insensitive) DNS labels and binary labels [RFC 2673]. 791 2. This may prevent more than one question being put into a single 792 packet, since the different questions may hash to different multicast 793 addresses. 795 3. This impedes the ability to use a single multicast reply packet to 796 answer the client and simultaneously facilitate ongoing conflict 797 monitoring, because every client would have to listen on every 798 multicast address in the range (or rapidly join and leave multicast 799 groups on demand for each request) in order to receive the reply. 801 4. This limits the ability to gain certain useful functionality out 802 of old resolver software by configuring it with a single All-DNS 803 multicast address to which it can send its queries. 805 19. Security Considerations 807 DNSSEC [RFC 2535] should be used where the authenticity of 808 information is important. 810 When DNS queries for names outside the "local.arpa." domain are sent 811 to the all-DNS multicast address (during of network outages which 812 disrupt communication with the greater Internet) it is *especially* 813 important to use DNSSEC, because the user may have the impression 814 that he or she is communicating with some authentic host, when in 815 fact he or she is really communicating with some local host that is 816 merely masquerading as that name. This is less critical for names 817 within the "local.arpa." domain, because within this domain the user 818 can be aware that names have only local significance and no global 819 authority is implied. 821 Most computer users neglect to type the trailing dot at the end of a 822 fully qualified domain name, making it a relative domain name (e.g. 823 "www.example.com"). In the event of network outage, attempts to 824 positively resolve the name as entered will fail, resulting in 825 application of the search list, including "local.arpa.", if present. 826 A malicious host could masquerade as "www.example.com" by answering 827 the resulting Multicast DNS request for "www.example.com.local.arpa." 828 To avoid this, a host MUST NOT append the search domain 829 "local.arpa.", if present, to any relative (partially qualified) 830 domain name containing two or more labels. Appending "local.arpa." to 831 single-label relative domain names is acceptable, since the user 832 should have no expectation that a single-label domain name will 833 resolve as-is. 835 [Lots more work to be done here!] 837 20. IANA Considerations 839 The IANA has allocated the IPv4 link-local multicast address 840 224.0.0.251 for the use described in this document. 842 We'd like the IANA to designate the DNS domain "local.arpa." a 843 "Multicast Domain" with special semantics, namely that "local.arpa." 844 and its subdomains are link-local, and names within this domain are 845 meaningful only on the link where they originate, much as IPv4 846 addresses in the 169.254/16 prefix are link-local and meaningful only 847 on the link where they originate. Likewise we'd like the IANA to 848 designate the DNS domain "254.169.in-addr.arpa." to be similarly 849 link-local and non-delegated. 851 No other IANA services are required by this document. 853 21. Copyright 855 Copyright (C) The Internet Society 8th March 2000. 856 All Rights Reserved. 858 This document and translations of it may be copied and furnished to 859 others, and derivative works that comment on or otherwise explain it 860 or assist in its implementation may be prepared, copied, published 861 and distributed, in whole or in part, without restriction of any 862 kind, provided that the above copyright notice and this paragraph are 863 included on all such copies and derivative works. However, this 864 document itself may not be modified in any way, such as by removing 865 the copyright notice or references to the Internet Society or other 866 Internet organizations, except as needed for the purpose of 867 developing Internet standards in which case the procedures for 868 copyrights defined in the Internet Standards process must be 869 followed, or as required to translate it into languages other than 870 English. 872 The limited permissions granted above are perpetual and will not be 873 revoked by the Internet Society or its successors or assigns. 875 This document and the information contained herein is provided on an 876 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 877 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 878 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 879 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 880 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 882 22. References 884 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 885 Overview and Architecture. 886 Institute of Electrical and Electronic Engineers, 887 IEEE Standard 802, 1990. 889 [NIAS] S. Cheshire, "Discovering Named Instances of Abstract 890 Services using DNS", Internet-Draft (work in progress), 891 draft-cheshire-dnsext-nias-00.txt, July 2001. 893 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 894 Requirement Levels", RFC 2119, March 1997. 896 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address 897 Autoconfiguration", RFC 2462, December 1998. 899 [RFC 2535] D. Eastlake, "Domain Name System Security Extensions", 900 RFC 2535, March 1999. 902 [RFC 2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)", 903 RFC 2671, August 1999. 905 [RFC 2673] M. Crawford, "Binary Labels in the Domain Name System", 906 RFC 2673, August 1999. 908 [v4LL] S. Cheshire and B. Aboba, "Dynamic Configuration of IPv4 909 Link-Local Addresses", Internet-Draft (work in progress), 910 draft-ietf-zeroconf-ipv4-linklocal-03.txt, June 2001. 912 [ZC] M. Hattig, "Zeroconf Requirements", Internet-Draft (work 913 in progress), draft-ietf-zeroconf-reqts-08.txt, May 2001. 915 23. Author's Address 917 Stuart Cheshire 918 Apple Computer, Inc. 919 1 Infinite Loop 920 Cupertino 921 California 95014 922 USA 924 Phone: +1 408 974 3207 925 EMail: rfc@stuartcheshire.org