1Document: draft-cheshire-dnsext-dns-sd-04.txt Stuart Cheshire 2Internet-Draft Marc Krochmal 3Category: Standards Track Apple Computer, Inc. 4Expires 10th February 2007 10th August 2006 5 6 DNS-Based Service Discovery 7 8 <draft-cheshire-dnsext-dns-sd-04.txt> 9 10Status of this Memo 11 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 For the purposes of this document, the term "BCP 79" refers 17 exclusively to RFC 3979, "Intellectual Property Rights in IETF 18 Technology", published March 2005. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 24 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 35 36 37Abstract 38 39 This document describes a convention for naming and structuring DNS 40 resource records. Given a type of service that a client is looking 41 for, and a domain in which the client is looking for that service, 42 this convention allows clients to discover a list of named instances 43 of that desired service, using only standard DNS queries. In short, 44 this is referred to as DNS-based Service Discovery, or DNS-SD. 45 46 47 48 49 50 51 52 53 54 55 56 57 58Expires 10th February 2007 Cheshire & Krochmal [Page 1] 59 60Internet Draft DNS-Based Service Discovery 10th August 2006 61 62 63Table of Contents 64 65 1. Introduction...................................................3 66 2. Conventions and Terminology Used in this Document..............4 67 3. Design Goals...................................................4 68 4. Service Instance Enumeration...................................5 69 4.1 Structured Instance Names......................................5 70 4.2 User Interface Presentation....................................7 71 4.3 Internal Handling of Names.....................................7 72 4.4 What You See Is What You Get...................................8 73 4.5 Ordering of Service Instance Name Components...................9 74 5. Service Name Resolution.......................................11 75 6. Data Syntax for DNS-SD TXT Records............................12 76 6.1 General Format Rules for DNS TXT Records......................12 77 6.2 DNS TXT Record Format Rules for use in DNS-SD.................13 78 6.3 DNS-SD TXT Record Size........................................14 79 6.4 Rules for Names in DNS-SD Name/Value Pairs....................14 80 6.5 Rules for Values in DNS-SD Name/Value Pairs...................16 81 6.6 Example TXT Record............................................17 82 6.7 Version Tag...................................................17 83 7. Application Protocol Names....................................18 84 7.1 Selective Instance Enumeration................................19 85 7.2 Service Name Length Limits....................................20 86 8. Flagship Naming...............................................22 87 9. Service Type Enumeration......................................23 88 10. Populating the DNS with Information...........................24 89 11. Relationship to Multicast DNS.................................24 90 12. Discovery of Browsing and Registration Domains................25 91 13. DNS Additional Record Generation..............................26 92 14. Comparison with Alternative Service Discovery Protocols.......27 93 15. Real Examples.................................................29 94 16. User Interface Considerations.................................30 95 16.1 Service Advertising User-Interface Considerations.............30 96 16.2 Client Browsing User-Interface Considerations.................31 97 17. IPv6 Considerations...........................................34 98 18. Security Considerations.......................................34 99 19. IANA Considerations...........................................34 100 20. Acknowledgments...............................................35 101 21. Deployment History............................................35 102 22. Copyright Notice..............................................36 103 23. Normative References..........................................37 104 24. Informative References........................................37 105 25. Authors' Addresses............................................38 106 107 108 109 110 111 112 113 114 115 116Expires 10th February 2007 Cheshire & Krochmal [Page 2] 117 118Internet Draft DNS-Based Service Discovery 10th August 2006 119 120 1211. Introduction 122 123 This document describes a convention for naming and structuring DNS 124 resource records. Given a type of service that a client is looking 125 for, and a domain in which the client is looking for that service, 126 this convention allows clients to discover a list of named instances 127 of a that desired service, using only standard DNS queries. In short, 128 this is referred to as DNS-based Service Discovery, or DNS-SD. 129 130 This document proposes no change to the structure of DNS messages, 131 and no new operation codes, response codes, resource record types, 132 or any other new DNS protocol values. This document simply proposes 133 a convention for how existing resource record types can be named and 134 structured to facilitate service discovery. 135 136 This proposal is entirely compatible with today's existing unicast 137 DNS server and client software. 138 139 Note that the DNS-SD service does NOT have to be provided by the same 140 DNS server hardware that is currently providing an organization's 141 conventional host name lookup service (the service we traditionally 142 think of when we say "DNS"). By delegating the "_tcp" subdomain, 143 all the workload related to DNS-SD can be offloaded to a different 144 machine. This flexibility, to handle DNS-SD on the main DNS server, 145 or not, at the network administrator's discretion, is one of the 146 things that makes DNS-SD so compelling. 147 148 Even when the DNS-SD functions are delegated to a different machine, 149 the benefits of using DNS remain: It is mature technology, well 150 understood, with multiple independent implementations from different 151 vendors, a wide selection of books published on the subject, and an 152 established workforce experienced in its operation. In contrast, 153 adopting some other service discovery technology would require every 154 site in the world to install, learn, configure, operate and maintain 155 some entirely new and unfamiliar server software. Faced with these 156 obstacles, it seems unlikely that any other service discovery 157 technology could hope to compete with the ubiquitous deployment 158 that DNS already enjoys. 159 160 This proposal is also compatible with (but not dependent on) the 161 proposal outlined in "Multicast DNS" [mDNS]. 162 163 164 165 166 167 168 169 170 171 172 173 174Expires 10th February 2007 Cheshire & Krochmal [Page 3] 175 176Internet Draft DNS-Based Service Discovery 10th August 2006 177 178 1792. Conventions and Terminology Used in this Document 180 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in "Key words for use in 184 RFCs to Indicate Requirement Levels" [RFC 2119]. 185 186 1873. Design Goals 188 189 A good service discovery protocol needs to have many properties, 190 three of which are mentioned below: 191 192 (i) The ability to query for services of a certain type in a certain 193 logical domain and receive in response a list of named instances 194 (network browsing, or "Service Instance Enumeration"). 195 196 (ii) Given a particular named instance, the ability to efficiently 197 resolve that instance name to the required information a client needs 198 to actually use the service, i.e. IP address and port number, at the 199 very least (Service Name Resolution). 200 201 (iii) Instance names should be relatively persistent. If a user 202 selects their default printer from a list of available choices today, 203 then tomorrow they should still be able to print on that printer -- 204 even if the IP address and/or port number where the service resides 205 have changed -- without the user (or their software) having to repeat 206 the network browsing step a second time. 207 208 In addition, if it is to become successful, a service discovery 209 protocol should be so simple to implement that virtually any 210 device capable of implementing IP should not have any trouble 211 implementing the service discovery software as well. 212 213 These goals are discussed in more detail in the remainder of this 214 document. A more thorough treatment of service discovery requirements 215 may be found in "Requirements for a Protocol to Replace AppleTalk 216 NBP" [NBP]. That document draws upon examples from two decades of 217 operational experience with AppleTalk Name Binding Protocol to 218 develop a list of universal requirements which are broadly 219 applicable to any potential service discovery protocol. 220 221 222 223 224 225 226 227 228 229 230 231 232Expires 10th February 2007 Cheshire & Krochmal [Page 4] 233 234Internet Draft DNS-Based Service Discovery 10th August 2006 235 236 2374. Service Instance Enumeration 238 239 DNS SRV records [RFC 2782] are useful for locating instances of a 240 particular type of service when all the instances are effectively 241 indistinguishable and provide the same service to the client. 242 243 For example, SRV records with the (hypothetical) name 244 "_http._tcp.example.com." would allow a client to discover a list of 245 all servers implementing the "_http._tcp" service (i.e. Web servers) 246 for the "example.com." domain. The unstated assumption is that all 247 these servers offer an identical set of Web pages, and it doesn't 248 matter to the client which of the servers it uses, as long as it 249 selects one at random according to the weight and priority rules 250 laid out in RFC 2782. 251 252 Instances of other kinds of service are less easily interchangeable. 253 If a word processing application were to look up the (hypothetical) 254 SRV record "_ipp._tcp.example.com." to find the list of IPP printers 255 at Example Co., then picking one at random and printing on it would 256 probably not be what the user wanted. 257 258 The remainder of this section describes how SRV records may be used 259 in a slightly different way to allow a user to discover the names 260 of all available instances of a given type of service, in order to 261 select the particular instance the user desires. 262 263 2644.1 Structured Instance Names 265 266 This document borrows the logical service naming syntax and semantics 267 from DNS SRV records, but adds one level of indirection. Instead of 268 requesting records of type "SRV" with name "_ipp._tcp.example.com.", 269 the client requests records of type "PTR" (pointer from one name to 270 another in the DNS namespace). 271 272 In effect, if one thinks of the domain name "_ipp._tcp.example.com." 273 as being analogous to an absolute path to a directory in a file 274 system then the PTR lookup is akin to performing a listing of that 275 directory to find all the files it contains. (Remember that domain 276 names are expressed in reverse order compared to path names: An 277 absolute path name is read from left to right, beginning with a 278 leading slash on the left, and then the top level directory, then 279 the next level directory, and so on. A fully-qualified domain name is 280 read from right to left, beginning with the dot on the right -- the 281 root label -- and then the top level domain to the left of that, and 282 the second level domain to the left of that, and so on. If the fully- 283 qualified domain name "_ipp._tcp.example.com." were expressed as a 284 file system path name, it would be "/com/example/_tcp/_ipp".) 285 286 287 288 289 290Expires 10th February 2007 Cheshire & Krochmal [Page 5] 291 292Internet Draft DNS-Based Service Discovery 10th August 2006 293 294 295 The result of this PTR lookup for the name "<Service>.<Domain>" is a 296 list of zero or more PTR records giving Service Instance Names of the 297 form: 298 299 Service Instance Name = <Instance> . <Service> . <Domain> 300 301 The <Instance> portion of the Service Instance Name is a single DNS 302 label, containing arbitrary precomposed UTF-8-encoded text [RFC 303 3629]. It is a user-friendly name, meaning that it is allowed to 304 contain any characters, without restriction, including spaces, upper 305 case, lower case, punctuation -- including dots -- accented 306 characters, non-roman text, and anything else that may be represented 307 using UTF-8. DNS recommends guidelines for allowable characters for 308 host names [RFC 1033][RFC 1034][RFC 1035], but Service Instance Names 309 are not host names. Service Instance Names are not intended to ever 310 be typed in by a normal user; the user selects a Service Instance 311 Name by selecting it from a list of choices presented on the screen. 312 313 Note that just because this protocol supports arbitrary UTF-8-encoded 314 names doesn't mean that any particular user or administrator is 315 obliged to make use of that capability. Any user is free, if they 316 wish, to continue naming their services using only letters, digits 317 and hyphens, with no spaces, capital letters, or other punctuation. 318 319 DNS labels are currently limited to 63 octets in length. UTF-8 320 encoding can require up to four octets per Unicode character, which 321 means that in the worst case, the <Instance> portion of a name could 322 be limited to fifteen Unicode characters. However, the Unicode 323 characters with longer UTF-8 encodings tend to be the more obscure 324 ones, and tend to be the ones that convey greater meaning per 325 character. 326 327 Note that any character in the commonly-used 16-bit Unicode space 328 can be encoded with no more than three octets of UTF-8 encoding. This 329 means that an Instance name can contain up to 21 Kanji characters, 330 which is a sufficiently expressive name for most purposes. 331 332 The <Service> portion of the Service Instance Name consists of a pair 333 of DNS labels, following the established convention for SRV records 334 [RFC 2782], namely: the first label of the pair is the Application 335 Protocol Name, and the second label is either "_tcp" or "_udp", 336 depending on the transport protocol used by the application. 337 More details are given in Section 7, "Application Protocol Names". 338 339 The <Domain> portion of the Service Instance Name specifies the DNS 340 subdomain within which the service names are registered. It may be 341 "local", meaning "link-local Multicast DNS" [mDNS], or it may be 342 a conventional unicast DNS domain name, such as "apple.com.", 343 "cs.stanford.edu.", or "eng.us.ibm.com." Because service names are 344 not host names, they are not constrained by the usual rules for host 345 346 347 348Expires 10th February 2007 Cheshire & Krochmal [Page 6] 349 350Internet Draft DNS-Based Service Discovery 10th August 2006 351 352 353 names [RFC 1033][RFC 1034][RFC 1035], and rich-text service 354 subdomains are allowed and encouraged, for example: 355 356 Building 2, 1st Floor.apple.com. 357 Building 2, 2nd Floor.apple.com. 358 Building 2, 3rd Floor.apple.com. 359 Building 2, 4th Floor.apple.com. 360 361 In addition, because Service Instance Names are not constrained by 362 the limitations of host names, this document recommends that they 363 be stored in the DNS, and communicated over the wire, encoded as 364 straightforward canonical precomposed UTF-8, Unicode Normalization 365 Form C [UAX15]. In cases where the DNS server returns an NXDOMAIN 366 error for the name in question, client software MAY choose to retry 367 the query using "Punycode" [RFC 3492] encoding, if possible. 368 369 3704.2 User Interface Presentation 371 372 The names resulting from the PTR lookup are presented to the user in 373 a list for the user to select one (or more). Typically only the first 374 label is shown (the user-friendly <Instance> portion of the name). In 375 the common case, the <Service> and <Domain> are already known to the 376 user, these having been provided by the user in the first place, by 377 the act of indicating the service being sought, and the domain in 378 which to look for it. Note: The software handling the response 379 should be careful not to make invalid assumptions though, since it 380 *is* possible, though rare, for a service enumeration in one domain 381 to return the names of services in a different domain. Similarly, 382 when using subtypes (see "Selective Instance Enumeration") the 383 <Service> of the discovered instance my not be exactly the same as 384 the <Service> that was requested. 385 386 Having chosen the desired named instance, the Service Instance 387 Name may then be used immediately, or saved away in some persistent 388 user-preference data structure for future use, depending on what is 389 appropriate for the application in question. 390 391 3924.3 Internal Handling of Names 393 394 If the <Instance>, <Service> and <Domain> portions are internally 395 concatenated together into a single string, then care must be taken 396 with the <Instance> portion, since it is allowed to contain any 397 characters, including dots. 398 399 Any dots in the <Instance> portion should be escaped by preceding 400 them with a backslash ("." becomes "\."). Likewise, any backslashes 401 in the <Instance> portion should also be escaped by preceding them 402 with a backslash ("\" becomes "\\"). Having done this, the three 403 components of the name may be safely concatenated. The backslash- 404 405 406Expires 10th February 2007 Cheshire & Krochmal [Page 7] 407 408Internet Draft DNS-Based Service Discovery 10th August 2006 409 410 411 escaping allows literal dots in the name (escaped) to be 412 distinguished from label-separator dots (not escaped). 413 414 The resulting concatenated string may be safely passed to standard 415 DNS APIs like res_query(), which will interpret the string correctly 416 provided it has been escaped correctly, as described here. 417 418 4194.4 What You See Is What You Get 420 421 Some service discovery protocols decouple the true service identifier 422 from the name presented to the user. The true service identifier used 423 by the protocol is an opaque unique id, often represented using a 424 long string of hexadecimal digits, and should never be seen by the 425 typical user. The name presented to the user is merely one of the 426 ephemeral attributes attached to this opaque identifier. 427 428 The problem with this approach is that it decouples user perception 429 from reality: 430 431 * What happens if there are two service instances, with different 432 unique ids, but they have inadvertently been given the same 433 user-visible name? If two instances appear in an on-screen list 434 with the same name, how does the user know which is which? 435 436 * Suppose a printer breaks down, and the user replaces it with 437 another printer of the same make and model, and configures the 438 new printer with the exact same name as the one being replaced: 439 "Stuart's Printer". Now, when the user tries to print, the 440 on-screen print dialog tells them that their selected default 441 printer is "Stuart's Printer". When they browse the network to see 442 what is there, they see a printer called "Stuart's Printer", yet 443 when the user tries to print, they are told that the printer 444 "Stuart's Printer" can't be found. The hidden internal unique id 445 that the software is trying to find on the network doesn't match 446 the hidden internal unique id of the new printer, even though its 447 apparent "name" and its logical purpose for being there are the 448 same. To remedy this, the user typically has to delete the print 449 queue they have created, and then create a new (apparently 450 identical) queue for the new printer, so that the new queue will 451 contain the right hidden internal unique id. Having all this hidden 452 information that the user can't see makes for a confusing and 453 frustrating user experience, and exposing long ugly hexadecimal 454 strings to the user and forcing them to understand what they mean 455 is even worse. 456 457 * Suppose an existing printer is moved to a new department, and given 458 a new name and a new function. Changing the user-visible name of 459 that piece of hardware doesn't change its hidden internal unique 460 id. Users who had previously created print queues for that printer 461 will still be accessing the same hardware by its unique id, even 462 463 464Expires 10th February 2007 Cheshire & Krochmal [Page 8] 465 466Internet Draft DNS-Based Service Discovery 10th August 2006 467 468 469 though the logical service that used to be offered by that hardware 470 has ceased to exist. 471 472 To solve these problems requires the user or administrator to be 473 aware of the supposedly hidden unique id, and to set its value 474 correctly as hardware is moved around, repurposed, or replaced, 475 thereby contradicting the notion that it is a hidden identifier that 476 human users never need to deal with. Requiring the user to understand 477 this expert behind-the-scenes knowledge of what is *really* going on 478 is just one more burden placed on the user when they are trying to 479 diagnose why their computers and network devices are not working as 480 expected. 481 482 These anomalies and counter-intuitive behaviors can be eliminated by 483 maintaining a tight bidirectional one-to-one mapping between what 484 the user sees on the screen and what is really happening "behind 485 the curtain". If something is configured incorrectly, then that is 486 apparent in the familiar day-to-day user interface that everyone 487 understands, not in some little-known rarely-used "expert" interface. 488 489 In summary: The user-visible name is the primary identifier for a 490 service. If the user-visible name is changed, then conceptually 491 the service being offered is a different logical service -- even 492 though the hardware offering the service stayed the same. If the 493 user-visible name doesn't change, then conceptually the service being 494 offered is the same logical service -- even if the hardware offering 495 the service is new hardware brought in to replace some old equipment. 496 497 There are certainly arguments on both sides of this debate. 498 Nonetheless, the designers of any service discovery protocol have 499 to make a choice between between having the primary identifiers be 500 hidden, or having them be visible, and these are the reasons that 501 we chose to make them visible. We're not claiming that there are no 502 disadvantages of having primary identifiers be visible. We considered 503 both alternatives, and we believe that the few disadvantages 504 of visible identifiers are far outweighed by the many problems 505 caused by use of hidden identifiers. 506 507 5084.5 Ordering of Service Instance Name Components 509 510 There have been questions about why services are named using DNS 511 Service Instance Names of the form: 512 513 Service Instance Name = <Instance> . <Service> . <Domain> 514 515 instead of: 516 517 Service Instance Name = <Service> . <Instance> . <Domain> 518 519 520 521 522Expires 10th February 2007 Cheshire & Krochmal [Page 9] 523 524Internet Draft DNS-Based Service Discovery 10th August 2006 525 526 527 There are three reasons why it is beneficial to name service 528 instances with the parent domain as the most-significant (rightmost) 529 part of the name, then the abstract service type as the next-most 530 significant, and then the specific instance name as the 531 least-significant (leftmost) part of the name: 532 533 5344.5.1. Semantic Structure 535 536 The facility being provided by browsing ("Service Instance 537 Enumeration") is effectively enumerating the leaves of a tree 538 structure. A given domain offers zero or more services. For each 539 of those service types, there may be zero or more instances of 540 that service. 541 542 The user knows what type of service they are seeking. (If they are 543 running an FTP client, they are looking for FTP servers. If they have 544 a document to print, they are looking for entities that speak some 545 known printing protocol.) The user knows in which organizational or 546 geographical domain they wish to search. (The user does not want a 547 single flat list of every single printer on the planet, even if such 548 a thing were possible.) What the user does not know in advance is 549 whether the service they seek is offered in the given domain, or if 550 so, how many instances are offered, and the names of those instances. 551 Hence having the instance names be the leaves of the tree is 552 consistent with this semantic model. 553 554 Having the service types be the terminal leaves of the tree would 555 imply that the user knows the domain name, and already knows the 556 name of the service instance, but doesn't have any idea what the 557 service does. We would argue that this is a less useful model. 558 559 5604.5.2. Network Efficiency 561 562 When a DNS response contains multiple answers, name compression works 563 more effectively if all the names contain a common suffix. If many 564 answers in the packet have the same <Service> and <Domain>, then each 565 occurrence of a Service Instance Name can be expressed using only 566 the <Instance> part followed by a two-byte compression pointer 567 referencing a previous appearance of "<Service>.<Domain>". This 568 efficiency would not be possible if the <Service> component appeared 569 first in each name. 570 571 5724.5.3. Operational Flexibility 573 574 This name structure allows subdomains to be delegated along logical 575 service boundaries. For example, the network administrator at Example 576 Co. could choose to delegate the "_tcp.example.com." subdomain to a 577 different machine, so that the machine handling service discovery 578 579 580Expires 10th February 2007 Cheshire & Krochmal [Page 10] 581 582Internet Draft DNS-Based Service Discovery 10th August 2006 583 584 585 doesn't have to be the same as the machine handling other day-to-day 586 DNS operations. (It *can* be the same machine if the administrator so 587 chooses, but the point is that the administrator is free to make that 588 choice.) Furthermore, if the network administrator wishes to delegate 589 all information related to IPP printers to a machine dedicated to 590 that specific task, this is easily done by delegating the 591 "_ipp._tcp.example.com." subdomain to the desired machine. It is 592 also convenient to set security policies on a per-zone/per-subdomain 593 basis. For example, the administrator may choose to enable DNS 594 Dynamic Update [RFC 2136] [RFC 3007] for printers registering 595 in the "_ipp._tcp.example.com." subdomain, but not for other 596 zones/subdomains. This easy flexibility would not exist if the 597 <Service> component appeared first in each name. 598 599 6005. Service Name Resolution 601 602 Given a particular Service Instance Name, when a client needs to 603 contact that service, it sends a DNS query for the SRV record of 604 that name. 605 606 The result of the DNS query is a SRV record giving the port number 607 and target host where the service may be found. 608 609 The use of SRV records is very important. There are only 65535 TCP 610 port numbers available. These port numbers are being allocated 611 one-per-application-protocol at an alarming rate. Some protocols 612 like the X Window System have a block of 64 TCP ports allocated 613 (6000-6063). If we start allocating blocks of 64 TCP ports at a time, 614 we will run out even faster. Using a different TCP port for each 615 different instance of a given service on a given machine is entirely 616 sensible, but allocating large static ranges, as was done for X, is a 617 very inefficient way to manage a limited resource. On any given host, 618 most TCP ports are reserved for services that will never run on that 619 particular host. This is very poor utilization of the limited port 620 space. Using SRV records allows each host to allocate its available 621 port numbers dynamically to those services running on that host that 622 need them, and then advertise the allocated port numbers via SRV 623 records. Allocating the available listening port numbers locally 624 on a per-host basis as needed allows much better utilization of the 625 available port space than today's centralized global allocation. 626 627 In some environments there may be no compelling reason to assign 628 managed names to every host, since every available service is 629 accessible by name anyway, as a first-class entity in its own right. 630 However, the DNS packet format and record format still require a host 631 name to link the target host referenced in the SRV record to the 632 address records giving the IPv4 and/or IPv6 addresses for that 633 hardware. In the case where no natural host name is available, the 634 SRV record may give its own name as the name of the target host, and 635 then the requisite address records may be attached to that same name. 636 637 638Expires 10th February 2007 Cheshire & Krochmal [Page 11] 639 640Internet Draft DNS-Based Service Discovery 10th August 2006 641 642 643 It is perfectly permissible for a single name in the DNS hierarchy 644 to have multiple records of different type attached. (The only 645 restriction being that a given name may not have both a CNAME record 646 and other records at the same time.) 647 648 In the event that more than one SRV is returned, clients MUST 649 correctly interpret the priority and weight fields -- i.e. Lower 650 numbered priority servers should be used in preference to higher 651 numbered priority servers, and servers with equal priority should be 652 selected randomly in proportion to their relative weights. However, 653 in the overwhelmingly common case, a single advertised DNS-SD service 654 instance is described by exactly one SRV record, and in this common 655 case the priority and weight fields of the SRV record SHOULD both be 656 set to zero. 657 658 6596. Data Syntax for DNS-SD TXT Records 660 661 Some services discovered via Service Instance Enumeration may need 662 more than just an IP address and port number to properly identify the 663 service. For example, printing via the LPR protocol often specifies a 664 queue name. This queue name is typically short and cryptic, and need 665 not be shown to the user. It should be regarded the same way as the 666 IP address and port number -- it is one component of the addressing 667 information required to identify a specific instance of a service 668 being offered by some piece of hardware. Similarly, a file server may 669 have multiple volumes, each identified by its own volume name. A Web 670 server typically has multiple pages, each identified by its own URL. 671 In these cases, the necessary additional data is stored in a TXT 672 record with the same name as the SRV record. The specific nature of 673 that additional data, and how it is to be used, is service-dependent, 674 but the overall syntax of the data in the TXT record is standardized, 675 as described below. Every DNS-SD service MUST have a TXT record in 676 addition to its SRV record, with same name, even if the service has 677 no additional data to store and the TXT record contains no more than 678 a single zero byte. 679 680 6816.1 General Format Rules for DNS TXT Records 682 683 A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total 684 length is indicated by the length given in the resource record header 685 in the DNS message. There is no way to tell directly from the data 686 alone how long it is (e.g. there is no length count at the start, or 687 terminating NULL byte at the end). (Note that when using Multicast 688 DNS [mDNS] the maximum packet size is 9000 bytes, which imposes an 689 upper limit on the size of TXT records of about 8800 bytes.) 690 691 The format of the data within a DNS TXT record is one or more 692 strings, packed together in memory without any intervening gaps 693 or padding bytes for word alignment. 694 695 696Expires 10th February 2007 Cheshire & Krochmal [Page 12] 697 698Internet Draft DNS-Based Service Discovery 10th August 2006 699 700 701 The format of each constituent string within the DNS TXT record is a 702 single length byte, followed by 0-255 bytes of text data. 703 704 These format rules are defined in Section 3.3.14 of RFC 1035, and are 705 not specific to DNS-SD. DNS-SD simply specifies a usage convention 706 for what data should be stored in those constituent strings. 707 708 An empty TXT record containing zero strings is disallowed by RFC 709 1035. DNS-SD implementations MUST NOT emit empty TXT records. 710 DNS-SD implementations receiving empty TXT records MUST treat them 711 as equivalent to a one-byte TXT record containing a single zero byte 712 (i.e. a single empty string). 713 714 7156.2 DNS TXT Record Format Rules for use in DNS-SD 716 717 DNS-SD uses DNS TXT records to store arbitrary name/value pairs 718 conveying additional information about the named service. Each 719 name/value pair is encoded as its own constituent string within the 720 DNS TXT record, in the form "name=value". Everything up to the first 721 '=' character is the name. Everything after the first '=' character 722 to the end of the string (including subsequent '=' characters, if 723 any) is the value. Specific rules governing names and values are 724 given below. Each author defining a DNS-SD profile for discovering 725 instances of a particular type of service should define the base set 726 of name/value attributes that are valid for that type of service. 727 728 Using this standardized name/value syntax within the TXT record makes 729 it easier for these base definitions to be expanded later by defining 730 additional named attributes. If an implementation sees unknown 731 attribute names in a service TXT record, it MUST silently ignore 732 them. 733 734 The TCP (or UDP) port number of the service, and target host name, 735 are given in the SRV record. This information -- target host name and 736 port number -- MUST NOT be duplicated using name/value attributes in 737 the TXT record. 738 739 The intention of DNS-SD TXT records is to convey a small amount of 740 useful additional information about a service. Ideally it SHOULD NOT 741 be necessary for a client to retrieve this additional information 742 before it can usefully establish a connection to the service. For a 743 well-designed TCP-based application protocol, it should be possible, 744 knowing only the host name and port number, to open a connection 745 to that listening process, and then perform version- or feature- 746 negotiation to determine the capabilities of the service instance. 747 For example, when connecting to an AppleShare server over TCP, the 748 client enters into a protocol exchange with the server to determine 749 which version of the AppleShare protocol the server implements, and 750 which optional features or capabilities (if any) are available. For a 751 well-designed application protocol, clients should be able to connect 752 753 754Expires 10th February 2007 Cheshire & Krochmal [Page 13] 755 756Internet Draft DNS-Based Service Discovery 10th August 2006 757 758 759 and use the service even if there is no information at all in the TXT 760 record. In this case, the information in the TXT record should be 761 viewed as a performance optimization -- when a client discovers many 762 instances of a service, the TXT record allows the client to know some 763 rudimentary information about each instance without having to open a 764 TCP connection to each one and interrogate every service instance 765 separately. Extreme care should be taken when doing this to ensure 766 that the information in the TXT record is in agreement with the 767 information retrieved by a client connecting over TCP. 768 769 There are legacy protocols which provide no feature negotiation 770 capability, and in these cases it may be useful to convey necessary 771 information in the TXT record. For example, when printing using the 772 old Unix LPR (port 515) protocol, the LPR service provides no way 773 for the client to determine whether a particular printer accepts 774 PostScript, or what version of PostScript, etc. In this case it is 775 appropriate to embed this information in the TXT record, because the 776 alternative is worse -- passing around written instructions to the 777 users, arcane manual configuration of "/etc/printcap" files, etc. 778 779 7806.3 DNS-SD TXT Record Size 781 782 The total size of a typical DNS-SD TXT record is intended to be small 783 -- 200 bytes or less. 784 785 In cases where more data is justified (e.g. LPR printing), keeping 786 the total size under 400 bytes should allow it to fit in a single 787 standard 512-byte DNS message. (This standard DNS message size is 788 defined in RFC 1035.) 789 790 In extreme cases where even this is not enough, keeping the size of 791 the TXT record under 1300 bytes should allow it to fit in a single 792 1500-byte Ethernet packet. 793 794 Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this 795 time. 796 797 7986.4 Rules for Names in DNS-SD Name/Value Pairs 799 800 The "Name" MUST be at least one character. Strings beginning with an 801 '=' character (i.e. the name is missing) SHOULD be silently ignored. 802 803 The characters of "Name" MUST be printable US-ASCII values 804 (0x20-0x7E), excluding '=' (0x3D). 805 806 Spaces in the name are significant, whether leading, trailing, or in 807 the middle -- so don't include any spaces unless you really intend 808 that! 809 810 811 812Expires 10th February 2007 Cheshire & Krochmal [Page 14] 813 814Internet Draft DNS-Based Service Discovery 10th August 2006 815 816 817 Case is ignored when interpreting a name, so "papersize=A4", 818 "PAPERSIZE=A4" and "Papersize=A4" are all identical. 819 820 If there is no '=', then it is a boolean attribute, and is simply 821 identified as being present, with no value. 822 823 A given attribute name may appear at most once in a TXT record. 824 The reason for this simplifying rule is to facilitate the creation 825 of client libraries that parse the TXT record into an internal data 826 structure, such as a hash table or dictionary object that maps from 827 names to values, and then make that abstraction available to client 828 code. The rule that a given attribute name may not appear more than 829 once simplifies these abstractions because they aren't required to 830 support the case of returning more than one value for a given key. 831 832 If a client receives a TXT record containing the same attribute name 833 more than once, then the client MUST silently ignore all but the 834 first occurrence of that attribute. For client implementations that 835 process a DNS-SD TXT record from start to end, placing name/value 836 pairs into a hash table, using the name as the hash table key, this 837 means that if the implementation attempts to add a new name/value 838 pair into the table and finds an entry with the same name already 839 present, then the new entry being added should be silently discarded 840 instead. For client implementations that retrieve name/value pairs by 841 searching the TXT record for the requested name, they should search 842 the TXT record from the start, and simply return the first matching 843 name they find. 844 845 When examining a TXT record for a given named attribute, there are 846 therefore four broad categories of results which may be returned: 847 848 * Attribute not present (Absent) 849 850 * Attribute present, with no value 851 (e.g. "Anon Allowed" -- server allows anonymous connections) 852 853 * Attribute present, with empty value (e.g. "Installed PlugIns=" -- 854 server supports plugins, but none are presently installed) 855 856 * Attribute present, with non-empty value 857 (e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4") 858 859 Each author defining a DNS-SD profile for discovering instances of a 860 particular type of service should define the interpretation of these 861 different kinds of result. For example, for some keys, there may be 862 a natural true/false boolean interpretation: 863 864 * Present implies 'true' 865 * Absent implies 'false' 866 867 868 869 870Expires 10th February 2007 Cheshire & Krochmal [Page 15] 871 872Internet Draft DNS-Based Service Discovery 10th August 2006 873 874 875 For other keys it may be sensible to define other semantics, such as 876 value/no-value/unknown: 877 878 * Present with value implies that value. 879 E.g. "Color=4" for a four-color ink-jet printer, 880 or "Color=6" for a six-color ink-jet printer. 881 882 * Present with empty value implies 'false'. E.g. Not a color printer. 883 884 * Absent implies 'Unknown'. E.g. A print server connected to some 885 unknown printer where the print server doesn't actually know if the 886 printer does color or not -- which gives a very bad user experience 887 and should be avoided wherever possible. 888 889 (Note that this is a hypothetical example, not an example of actual 890 name/value keys used by DNS-SD network printers.) 891 892 As a general rule, attribute names that contain no dots are defined 893 as part of the open-standard definition written by the person or 894 group defining the DNS-SD profile for discovering that particular 895 service type. Vendor-specific extensions should be given names of the 896 form "keyname.company.com=value", using a domain name legitimately 897 registered to the person or organization creating the vendor-specific 898 key. This reduces the risk of accidental conflict if different 899 organizations each define their own vendor-specific keys. 900 901 9026.5 Rules for Values in DNS-SD Name/Value Pairs 903 904 If there is an '=', then everything after the first '=' to the end 905 of the string is the value. The value can contain any eight-bit 906 values including '='. Leading or trailing spaces are part of the 907 value, so don't put them there unless you intend them to be there. 908 Any quotation marks around the value are part of the value, so don't 909 put them there unless you intend them to be part of the value. 910 911 The value is opaque binary data. Often the value for a particular 912 attribute will be US-ASCII (or UTF-8) text, but it is legal for a 913 value to be any binary data. For example, if the value of a key is an 914 IPv4 address, that address should simply be stored as four bytes of 915 binary data, not as a variable-length 7-15 byte ASCII string giving 916 the address represented in textual dotted decimal notation. 917 918 Generic debugging tools should generally display all attribute values 919 as a hex dump, with accompanying text alongside displaying the UTF-8 920 interpretation of those bytes, except for attributes where the 921 debugging tool has embedded knowledge that the value is some other 922 kind of data. 923 924 Authors defining DNS-SD profiles SHOULD NOT convert binary attribute 925 data types into printable text (e.g. using hexadecimal, Base-64 or UU 926 927 928Expires 10th February 2007 Cheshire & Krochmal [Page 16] 929 930Internet Draft DNS-Based Service Discovery 10th August 2006 931 932 933 encoding) merely for the sake of making the data be printable text 934 when seen in a generic debugging tool. Doing this simply bloats the 935 size of the TXT record, without actually making the data any more 936 understandable to someone looking at it in a generic debugging tool. 937 938 9396.6 Example TXT Record 940 941 The TXT record below contains three syntactically valid name/value 942 pairs. (The meaning of these name/value pairs, if any, would depend 943 on the definitions pertaining to the service in question that is 944 using them.) 945 946 --------------------------------------------------------------- 947 | 0x0A | name=value | 0x08 | paper=A4 | 0x0E | DNS-SD Is Cool | 948 --------------------------------------------------------------- 949 950 9516.7 Version Tag 952 953 It is recommended that authors defining DNS-SD profiles include an 954 attribute of the form "txtvers=xxx" in their definition, and require 955 it to be the first name/value pair in the TXT record. This 956 information in the TXT record can be useful to help clients maintain 957 backwards compatibility with older implementations if it becomes 958 necessary to change or update the specification over time. Even if 959 the profile author doesn't anticipate the need for any future 960 incompatible changes, having a version number in the specification 961 provides useful insurance should incompatible changes become 962 unavoidable. Clients SHOULD ignore TXT records with a txtvers number 963 higher (or lower) than the version(s) they know how to interpret. 964 965 Note that the version number in the txtvers tag describes the version 966 of the TXT record specification being used to create this TXT record, 967 not the version of the application protocol that will be used if the 968 client subsequently decides to contact that service. Ideally, every 969 DNS-SD TXT record specification starts at txtvers=1 and stays that 970 way forever. Improvements can be made by defining new keys that older 971 clients silently ignore. The only reason to increment the version 972 number is if the old specification is subsequently found to be so 973 horribly broken that there's no way to do a compatible forward 974 revision, so the txtvers number has to be incremented to tell all the 975 old clients they should just not even try to understand this new TXT 976 record. 977 978 If there is a need to indicate which version number(s) of the 979 application protocol the service implements, the recommended key 980 name for this is "protovers". 981 982 983 984 985 986Expires 10th February 2007 Cheshire & Krochmal [Page 17] 987 988Internet Draft DNS-Based Service Discovery 10th August 2006 989 990 9917. Application Protocol Names 992 993 The <Service> portion of a Service Instance Name consists of a pair 994 of DNS labels, following the established convention for SRV records 995 [RFC 2782], namely: the first label of the pair is an underscore 996 character followed by the Application Protocol Name, and the second 997 label is either "_tcp" or "_udp". 998 999 Application Protocol Names may be no more than fourteen characters 1000 (not counting the mandatory underscore), conforming to normal DNS 1001 host name rules: Only lower-case letters, digits, and hyphens; must 1002 begin and end with lower-case letter or digit. 1003 1004 Wise selection of an Application Protocol Name is very important, 1005 and the choice is not always as obvious as it may appear. 1006 1007 In some cases, the Application Protocol Name merely names and refers 1008 to the on-the-wire message format and semantics being used. FTP is 1009 "ftp", IPP printing is "ipp", and so on. 1010 1011 However, it is common to "borrow" an existing protocol and repurpose 1012 it for a new task. This is entirely sensible and sound engineering 1013 practice, but that doesn't mean that the new protocol is providing 1014 the same semantic service as the old one, even if it borrows the same 1015 message formats. For example, the local network music playing 1016 protocol implemented by iTunes on Macintosh and Windows is little 1017 more than "HTTP GET" commands. However, that does *not* mean that it 1018 is sensible or useful to try to access one of these music servers by 1019 connecting to it with a standard web browser. Consequently, the 1020 DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp" 1021 (Digital Audio Access Protocol), not "_http._tcp". Advertising 1022 "_http._tcp" service would cause iTunes servers to show up in 1023 conventional Web browsers (Safari, Camino, OmniWeb, Opera, Netscape, 1024 Internet Explorer, etc.) which is little use since it offers no pages 1025 containing human-readable content. Similarly, browsing for 1026 "_http._tcp" service would cause iTunes to find generic web servers, 1027 such as the embedded web servers in devices like printers, which is 1028 little use since printers generally don't have much music to offer. 1029 1030 Similarly, NFS is built on top of SUN RPC, but that doesn't mean it 1031 makes sense for an NFS server to advertise that it provides "SUN RPC" 1032 service. Likewise, Microsoft SMB file service is built on top of 1033 Netbios running over IP, but that doesn't mean it makes sense for 1034 an SMB file server to advertise that it provides "Netbios-over-IP" 1035 service. The DNS-SD name of a service needs to encapsulate both the 1036 "what" (semantics) and the "how" (protocol implementation) of the 1037 service, since knowledge of both is necessary for a client to 1038 usefully use the service. Merely advertising that a service was 1039 built on top of SUN RPC is no use if the client has no idea what 1040 the service actually does. 1041 1042 1043 1044Expires 10th February 2007 Cheshire & Krochmal [Page 18] 1045 1046Internet Draft DNS-Based Service Discovery 10th August 2006 1047 1048 1049 Another common mistake is to assume that the service type advertised 1050 by iTunes should be "_daap._http._tcp." This is also incorrect. 1051 Similarly, a protocol designer implementing a network service that 1052 happens to use Simple Object Access Protocol [SOAP] should not feel 1053 compelled to have "_soap" appear somewhere in the Application 1054 Protocol Name. Part of the confusion here is that the presence of 1055 "_tcp" or "_udp" in the <Service> portion of a Service Instance Name 1056 has led people to assume that the structure of a service name has to 1057 reflect the internal structure of how the protocol was implemented. 1058 This is not correct. All that is required is that the service be 1059 identified by a unique Application Protocol Name. Making the 1060 Application Protocol Name at least marginally descriptive of 1061 what the service does is desirable, though not essential. 1062 1063 The "_tcp" or "_udp" should be regarded as little more than 1064 boilerplate text, and care should be taken not to attach too much 1065 importance to it. Some might argue that the "_tcp" or "_udp" should 1066 not be there at all, but this format is defined by RFC 2782, and 1067 that's not going to change. In addition, the presence of "_tcp" has 1068 the useful side-effect that it provides a convenient delegation point 1069 to hand off responsibility for service discovery to a different DNS 1070 server, if so desired. 1071 1072 10737.1. Selective Instance Enumeration 1074 1075 This document does not attempt to define an arbitrary query language 1076 for service discovery, nor do we believe one is necessary. 1077 1078 However, there are some circumstances where narrowing the list of 1079 results may be useful. A hypothetical Web browser client that is able 1080 to retrieve HTML documents via HTTP and display them may also be able 1081 to retrieve HTML documents via FTP and display them, but only in the 1082 case of FTP servers that allow anonymous login. For that Web browser, 1083 discovering all FTP servers on the network is not useful. The Web 1084 browser only wants to discover FTP servers that it is able to talk 1085 to. In this case, a subtype of "_ftp._tcp" could be defined. Instead 1086 of issuing a query for "_ftp._tcp.<Domain>", the Web browser issues a 1087 query for "_anon._sub._ftp._tcp.<Domain>", where "_anon" is a defined 1088 subtype of "_ftp._tcp". The response to this query only includes the 1089 names of SRV records for FTP servers that are willing to allow 1090 anonymous login. 1091 1092 Note that the FTP server's Service Instance Name is unchanged -- it 1093 is still something of the form "The Server._ftp._tcp.example.com." 1094 The subdomain in which FTP server SRV records are registered defines 1095 the namespace within which FTP server names are unique. Additional 1096 subtypes (e.g. "_anon") of the basic service type (e.g. "_ftp._tcp") 1097 serve to narrow the list of results, not to create more namespace. 1098 1099 1100 1101 1102Expires 10th February 2007 Cheshire & Krochmal [Page 19] 1103 1104Internet Draft DNS-Based Service Discovery 10th August 2006 1105 1106 1107 Subtypes are appropriate when it is desirable for different kinds 1108 of clients to be able to browse for services at two levels of 1109 granularity. In the example above, we hypothesize two classes of 1110 ftp client: clients that can provide username and password when 1111 connecting, and clients that can only do anonymous login. The set of 1112 ftp servers on the network is the same in both cases; the difference 1113 is that the more capable client wants to discover all of them, 1114 whereas the more limited client only wants to find the subset of 1115 those ftp servers that it can talk to. Subtypes are only appropriate 1116 in two-level scenarios such as this one, where some clients want to 1117 find the full set of services of a given type, and at the same time 1118 other clients only want to find some subset. Generally speaking, if 1119 there is no client that wants to find the entire set, then it's 1120 neither necessary nor desirable to use the subtype mechanism. If all 1121 clients are browsing for some particular subtype, and no client 1122 exists that browses for the parent type, then an Application Protocol 1123 Name representing the logical service should be defined, and software 1124 should simply advertise and browse for that particular service type 1125 directly. In particular, just because a particular network service 1126 happens to be implemented in terms of some other underlying protocol, 1127 like HTTP, Sun RPC, or SOAP, doesn't mean that it's sensible for that 1128 service to be defined as a subtype of "_http", "_sunrpc", or "_soap". 1129 That would only be useful if there were some class of client for 1130 which it is sensible to say, "I want to discover a service on the 1131 network, and I don't care what it does, as long as it does it using 1132 the SOAP XML RPC mechanism." 1133 1134 As with the TXT record name/value pairs, the list of possible 1135 subtypes, if any, are defined and specified separately for each basic 1136 service type. Note that the example given here using "_ftp" is a 1137 hypothetical one. The "_ftp" service type does not (currently) have 1138 any subtypes defined. Subtypes are currently a little-used feature 1139 of DNS-SD, and experience will show whether or not they ultimately 1140 prove to have broad applicability. 1141 1142 11437.2 Service Name Length Limits 1144 1145 As described above, application protocol names are allowed to be up 1146 to fourteen characters long. The reason for this limit is to leave 1147 as many bytes of the domain name as possible available for use 1148 by both the network administrator (choosing service domain names) 1149 and the end user (choosing instance names). 1150 1151 A domain name may be up to 255 bytes long, including the final 1152 terminating root label at the end. Domain names used by DNS-SD 1153 take the following forms: 1154 1155 <Instance>.<app>._tcp.<servicedomain>.<parentdomain>. 1156 <sub>._sub.<app>._tcp.<servicedomain>.<parentdomain>. 1157 1158 1159 1160Expires 10th February 2007 Cheshire & Krochmal [Page 20] 1161 1162Internet Draft DNS-Based Service Discovery 10th August 2006 1163 1164 1165 The first example shows a service instance name, i.e. the name of the 1166 service's SRV and TXT records. The second shows a subtype browsing 1167 name, i.e. the name of a PTR record pointing to service instance 1168 names (see "Selective Instance Enumeration"). 1169 1170 The instance name <Instance> may be up to 63 bytes. Including the 1171 length byte used by the DNS format when the name is stored in a 1172 packet, that makes 64 bytes. 1173 1174 When using subtypes, the subtype identifier is allowed to be up to 1175 63 bytes, plus the length byte, making 64. Including the "_sub" 1176 and its length byte, this makes 69 bytes. 1177 1178 The application protocol name <app> may be up to 14 bytes, plus the 1179 underscore and length byte, making 16. Including the "_udp" or "_tcp" 1180 and its length byte, this makes 21 bytes. 1181 1182 Typically, DNS-SD service records are placed into subdomains of their 1183 own beneath a company's existing domain name. Since these subdomains 1184 are intended to be accessed through graphical user interfaces, not 1185 typed on a command-line they are frequently long and descriptive. 1186 Including the length byte, the user-visible service domain may be up 1187 to 64 bytes. 1188 1189 The terminating root label at the end counts as one byte. 1190 1191 Of our available 255 bytes, we have now accounted for 69+21+64+1 = 1192 155 bytes. This leaves 100 bytes to accommodate the organization's 1193 existing domain name <parentdomain>. When used with Multicast DNS, 1194 <parentdomain> is "local", which easily fits. When used with parent 1195 domains of 100 bytes or less, the full functionality of DNS-SD is 1196 available without restriction. When used with parent domains longer 1197 than 100 bytes, the protocol risks exceeding the maximum possible 1198 length of domain names, causing failures. In this case, careful 1199 choice of short <servicedomain> names can help avoid overflows. 1200 If the <servicedomain> and <parentdomain> are too long, then service 1201 instances with long instance names will not be discoverable or 1202 resolvable, and applications making use of long subtype names 1203 may fail. 1204 1205 Because of this constraint, we choose to limit Application Protocol 1206 Names to 14 characters or less. Allowing more characters would not 1207 add to the expressive power of the protocol, and would needlessly 1208 lower the limit on the maximum <parentdomain> length that may be 1209 safely used. 1210 1211 1212 1213 1214 1215 1216 1217 1218Expires 10th February 2007 Cheshire & Krochmal [Page 21] 1219 1220Internet Draft DNS-Based Service Discovery 10th August 2006 1221 1222 12238. Flagship Naming 1224 1225 In some cases, there may be several network protocols available 1226 which all perform roughly the same logical function. For example, 1227 the printing world has the LPR protocol, and the Internet Printing 1228 Protocol (IPP), both of which cause printed sheets to be emitted 1229 from printers in much the same way. In addition, many printer vendors 1230 send their own proprietary page description language (PDL) data 1231 over a TCP connection to TCP port 9100, herein referred to as the 1232 "pdl-datastream" protocol. In an ideal world we would have only one 1233 network printing protocol, and it would be sufficiently good that no 1234 one felt a compelling need to invent a different one. However, in 1235 practice, multiple legacy protocols do exist, and a service discovery 1236 protocol has to accommodate that. 1237 1238 Many printers implement all three printing protocols: LPR, IPP, and 1239 pdl-datastream. For the benefit of clients that may speak only one of 1240 those protocols, all three are advertised. 1241 1242 However, some clients may implement two, or all three of those 1243 printing protocols. When a client looks for all three service types 1244 on the network, it will find three distinct services -- an LPR 1245 service, an IPP service, and a pdl-datastream service -- all of which 1246 cause printed sheets to be emitted from the same physical printer. 1247 1248 In the case of multiple protocols like this that all perform 1249 effectively the same function, the client should suppress duplicate 1250 names and display each name only once. When the user prints to a 1251 given named printer, the printing client is responsible for choosing 1252 the protocol which will best achieve the desired effect, without, for 1253 example, requiring the user to make a manual choice between LPR and 1254 IPP. 1255 1256 As described so far, this all works very well. However, consider some 1257 future printer that only supports IPP printing, and some other future 1258 printer that only supports pdl-datastream printing. The name spaces 1259 for different service types are intentionally disjoint -- it is 1260 acceptable and desirable to be able to have both a file server called 1261 "Sales Department" and a printer called "Sales Department". However, 1262 it is not desirable, in the common case, to have two different 1263 printers both called "Sales Department", just because those printers 1264 are implementing different protocols. 1265 1266 To help guard against this, when there are two or more network 1267 protocols which perform roughly the same logical function, one of 1268 the protocols is declared the "flagship" of the fleet of related 1269 protocols. Typically the flagship protocol is the oldest and/or 1270 best-known protocol of the set. 1271 1272 If a device does not implement the flagship protocol, then it instead 1273 creates a placeholder SRV record (priority=0, weight=0, port=0, 1274 1275 1276Expires 10th February 2007 Cheshire & Krochmal [Page 22] 1277 1278Internet Draft DNS-Based Service Discovery 10th August 2006 1279 1280 1281 target host = hostname of device) with that name. If, when it 1282 attempts to create this SRV record, it finds that a record with the 1283 same name already exists, then it knows that this name is already 1284 taken by some entity implementing at least one of the protocols from 1285 the class, and it must choose another. If no SRV record already 1286 exists, then the act of creating it stakes a claim to that name so 1287 that future devices in the same class will detect a conflict when 1288 they try to use it. The SRV record needs to contain the target host 1289 name in order for the conflict detection rules to operate. If two 1290 different devices were to create placeholder SRV records both using a 1291 null target host name (just the root label), then the two SRV records 1292 would be seen to be in agreement so no conflict would be registered. 1293 1294 By defining a common well-known flagship protocol for the class, 1295 future devices that may not even know about each other's protocols 1296 establish a common ground where they can coordinate to verify 1297 uniqueness of names. 1298 1299 No PTR record is created advertising the presence of empty flagship 1300 SRV records, since they do not represent a real service being 1301 advertised. 1302 1303 13049. Service Type Enumeration 1305 1306 In general, clients are not interested in finding *every* service on 1307 the network, just the services that the client knows how to talk to. 1308 (Software designers may *think* there's some value to finding *every* 1309 service on the network, but that's just wooly thinking.) 1310 1311 However, for problem diagnosis and network management tools, it may 1312 be useful for network administrators to find the list of advertised 1313 service types on the network, even if those service names are just 1314 opaque identifiers and not particularly informative in isolation. 1315 1316 For this reason, a special meta-query is defined. A DNS query for 1317 PTR records with the name "_services._dns-sd._udp.<Domain>" yields 1318 a list of PTR records, where the rdata of each PTR record is the 1319 name of a service type. A subsequent query for PTR records with 1320 one of those names yields a list of instances of that service type. 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334Expires 10th February 2007 Cheshire & Krochmal [Page 23] 1335 1336Internet Draft DNS-Based Service Discovery 10th August 2006 1337 1338 133910. Populating the DNS with Information 1340 1341 How the SRV and PTR records that describe services and allow them to 1342 be enumerated make their way into the DNS is outside the scope of 1343 this document. However, it can happen easily in any of a number of 1344 ways, for example: 1345 1346 On some networks, the administrator might manually enter the records 1347 into the name server's configuration file. 1348 1349 A network monitoring tool could output a standard zone file to be 1350 read into a conventional DNS server. For example, a tool that can 1351 find Apple LaserWriters using AppleTalk NBP could find the list 1352 of printers, communicate with each one to find its IP address, 1353 PostScript version, installed options, etc., and then write out a 1354 DNS zone file describing those printers and their capabilities using 1355 DNS resource records. That information would then be available to 1356 DNS-SD clients that don't implement AppleTalk NBP, and don't want to. 1357 1358 Future IP printers could use Dynamic DNS Update [RFC 2136] to 1359 automatically register their own SRV and PTR records with the DNS 1360 server. 1361 1362 A printer manager device which has knowledge of printers on the 1363 network through some other management protocol could also use Dynamic 1364 DNS Update [RFC 2136]. 1365 1366 Alternatively, a printer manager device could implement enough of 1367 the DNS protocol that it is able to answer DNS queries directly, 1368 and Example Co.'s main DNS server could delegate the 1369 _ipp._tcp.example.com subdomain to the printer manager device. 1370 1371 Zeroconf printers answer Multicast DNS queries on the local link 1372 for appropriate PTR and SRV names ending with ".local." [mDNS] 1373 1374 137511. Relationship to Multicast DNS 1376 1377 DNS-Based Service Discovery is only peripherally related to Multicast 1378 DNS, in that the standard unicast DNS queries used by DNS-SD may also 1379 be performed using multicast when appropriate, which is particularly 1380 beneficial in Zeroconf environments [ZC]. 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392Expires 10th February 2007 Cheshire & Krochmal [Page 24] 1393 1394Internet Draft DNS-Based Service Discovery 10th August 2006 1395 1396 139712. Discovery of Browsing and Registration Domains (Domain Enumeration) 1398 1399 One of the main reasons for DNS-Based Service Discovery is so that 1400 when a visiting client (e.g. a laptop computer) arrives at a new 1401 network, it can discover what services are available on that network 1402 without manual configuration. This logic that applies to discovering 1403 services without manual configuration also applies to discovering the 1404 domains in which services are registered without requiring manual 1405 configuration. 1406 1407 This discovery is performed recursively, using Unicast or Multicast 1408 DNS. Five special RR names are reserved for this purpose: 1409 1410 b._dns-sd._udp.<domain>. 1411 db._dns-sd._udp.<domain>. 1412 r._dns-sd._udp.<domain>. 1413 dr._dns-sd._udp.<domain>. 1414 lb._dns-sd._udp.<domain>. 1415 1416 By performing PTR queries for these names, a client can learn, 1417 respectively: 1418 1419 o A list of domains recommended for browsing 1420 1421 o A single recommended default domain for browsing 1422 1423 o A list of domains recommended for registering services using 1424 Dynamic Update 1425 1426 o A single recommended default domain for registering services. 1427 1428 o The final query shown yields the "legacy browsing" domain. 1429 Sophisticated client applications that care to present choices 1430 of domain to the user, use the answers learned from the previous 1431 four queries to discover those domains to present. In contrast, 1432 many current applications browse without specifying an explicit 1433 domain, allowing the operating system to automatically select an 1434 appropriate domain on their behalf. It is for this class of 1435 application that the "legacy browsing" query is provided, to allow 1436 the network administrator to communicate to the client operating 1437 systems which domain should be used for these applications. 1438 1439 These domains are purely advisory. The client or user is free to 1440 browse and/or register services in any domains. The purpose of these 1441 special queries is to allow software to create a user-interface that 1442 displays a useful list of suggested choices to the user, from which 1443 they may make a suitable selection, or ignore the offered suggestions 1444 and manually enter their own choice. 1445 1446 1447 1448 1449 1450Expires 10th February 2007 Cheshire & Krochmal [Page 25] 1451 1452Internet Draft DNS-Based Service Discovery 10th August 2006 1453 1454 1455 The <domain> part of the name may be "local" (meaning "perform the 1456 query using link-local multicast) or it may be learned through some 1457 other mechanism, such as the DHCP "Domain" option (option code 15) 1458 [RFC 2132] or the DHCP "Domain Search" option (option code 119) 1459 [RFC 3397]. 1460 1461 The <domain> part of the name may also be derived from the host's IP 1462 address. The host takes its IP address, and calculates the logical 1463 AND of that address and its subnet mask, to derive the 'base' address 1464 of the subnet. It then constructs the conventional DNS "reverse 1465 mapping" name corresponding to that base address, and uses that 1466 as the <domain> part of the name for the queries described above. 1467 For example, if a host has address 192.168.12.34, with subnet mask 1468 255.255.0.0, then the 'base' address of the subnet is 192.168.0.0, 1469 and to discover the recommended legacy browsing domain for devices 1470 on this subnet, the host issues a DNS PTR query for the name 1471 "lb._dns-sd._udp.0.0.168.192.in-addr.arpa." 1472 1473 Sophisticated clients may perform domain enumeration queries both in 1474 "local" and in one or more unicast domains, and then present the user 1475 with an aggregate result, combining the information received from all 1476 sources. 1477 1478 147913. DNS Additional Record Generation 1480 1481 DNS has an efficiency feature whereby a DNS server may place 1482 additional records in the Additional Section of the DNS Message. 1483 These additional records are typically records that the client did 1484 not explicitly request, but the server has reasonable grounds to 1485 expect that the client might request them shortly. 1486 1487 This section recommends which additional records should be generated 1488 to improve network efficiency for both unicast and multicast DNS-SD 1489 responses. 1490 1491 149213.1 PTR Records 1493 1494 When including a PTR record in a response packet, the 1495 server/responder SHOULD include the following additional records: 1496 1497 o The SRV record(s) named in the PTR rdata. 1498 o The TXT record(s) named in the PTR rdata. 1499 o All address records (type "A" and "AAAA") named in the SRV rdata. 1500 1501 1502 1503 1504 1505 1506 1507 1508Expires 10th February 2007 Cheshire & Krochmal [Page 26] 1509 1510Internet Draft DNS-Based Service Discovery 10th August 2006 1511 1512 151313.2 SRV Records 1514 1515 When including an SVR record in a response packet, the 1516 server/responder SHOULD include the following additional records: 1517 1518 o All address records (type "A" and "AAAA") named in the SRV rdata. 1519 1520 152113.3 TXT Records 1522 1523 When including a TXT record in a response packet, no additional 1524 records are required. 1525 1526 152713.4 Other Record Types 1528 1529 In response to address queries, or other record types, no additional 1530 records are required by this document. 1531 1532 153314. Comparison with Alternative Service Discovery Protocols 1534 1535 Over the years there have been many proposed ways to do network 1536 service discovery with IP, but none achieved ubiquity in the 1537 marketplace. Certainly none has achieved anything close to the 1538 ubiquity of today's deployment of DNS servers, clients, and other 1539 infrastructure. 1540 1541 The advantage of using DNS as the basis for service discovery is 1542 that it makes use of those existing servers, clients, protocols, 1543 infrastructure, and expertise. Existing network analyzer tools 1544 already know how to decode and display DNS packets for network 1545 debugging. 1546 1547 For ad-hoc networks such as Zeroconf environments, peer-to-peer 1548 multicast protocols are appropriate. The Zeroconf host profile [ZCHP] 1549 requires the use of a DNS-like protocol over IP Multicast for host 1550 name resolution in the absence of DNS servers. Given that Zeroconf 1551 hosts will have to implement this Multicast-based DNS-like protocol 1552 anyway, it makes sense for them to also perform service discovery 1553 using that same Multicast-based DNS-like software, instead of also 1554 having to implement an entirely different service discovery protocol. 1555 1556 In larger networks, a high volume of enterprise-wide IP multicast 1557 traffic may not be desirable, so any credible service discovery 1558 protocol intended for larger networks has to provide some facility to 1559 aggregate registrations and lookups at a central server (or servers) 1560 instead of working exclusively using multicast. This requires some 1561 service discovery aggregation server software to be written, 1562 debugged, deployed, and maintained. This also requires some service 1563 discovery registration protocol to be implemented and deployed for 1564 1565 1566Expires 10th February 2007 Cheshire & Krochmal [Page 27] 1567 1568Internet Draft DNS-Based Service Discovery 10th August 2006 1569 1570 1571 clients to register with the central aggregation server. Virtually 1572 every company with an IP network already runs a DNS server, and DNS 1573 already has a dynamic registration protocol [RFC 2136]. Given that 1574 virtually every company already has to operate and maintain a DNS 1575 server anyway, it makes sense to take advantage of this instead of 1576 also having to learn, operate and maintain a different service 1577 registration server. It should be stressed again that using the 1578 same software and protocols doesn't necessarily mean using the same 1579 physical piece of hardware. The DNS-SD service discovery functions 1580 do not have to be provided by the same piece of hardware that 1581 is currently providing the company's DNS name service. The 1582 "_tcp.<Domain>" subdomain may be delegated to a different piece of 1583 hardware. However, even when the DNS-SD service is being provided 1584 by a different piece of hardware, it is still the same familiar DNS 1585 server software that is running, with the same configuration file 1586 syntax, the same log file format, and so forth. 1587 1588 Service discovery needs to be able to provide appropriate security. 1589 DNS already has existing mechanisms for security [RFC 2535]. 1590 1591 In summary: 1592 1593 Service discovery requires a central aggregation server. 1594 DNS already has one: It's called a DNS server. 1595 1596 Service discovery requires a service registration protocol. 1597 DNS already has one: It's called DNS Dynamic Update. 1598 1599 Service discovery requires a query protocol 1600 DNS already has one: It's called DNS. 1601 1602 Service discovery requires security mechanisms. 1603 DNS already has security mechanisms: DNSSEC. 1604 1605 Service discovery requires a multicast mode for ad-hoc networks. 1606 Zeroconf environments already require a multicast-based DNS-like 1607 name lookup protocol for mapping host names to addresses, so it 1608 makes sense to let one multicast-based protocol do both jobs. 1609 1610 It makes more sense to use the existing software that every network 1611 needs already, instead of deploying an entire parallel system just 1612 for service discovery. 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624Expires 10th February 2007 Cheshire & Krochmal [Page 28] 1625 1626Internet Draft DNS-Based Service Discovery 10th August 2006 1627 1628 162915. Real Examples 1630 1631 The following examples were prepared using standard unmodified 1632 nslookup and standard unmodified BIND running on GNU/Linux. 1633 1634 Note: In real products, this information is obtained and presented to 1635 the user using graphical network browser software, not command-line 1636 tools, but if you wish you can try these examples for yourself as you 1637 read along, using the command-line tools already available on your 1638 own Unix machine. 1639 164015.1 Question: What FTP servers are being advertised from dns-sd.org? 1641 1642 nslookup -q=ptr _ftp._tcp.dns-sd.org. 1643 _ftp._tcp.dns-sd.org 1644 name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org 1645 _ftp._tcp.dns-sd.org 1646 name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org 1647 _ftp._tcp.dns-sd.org 1648 name = Registered\032Users'\032Only._ftp._tcp.dns-sd.org 1649 1650 Answer: There are three, called "Apple QuickTime Files", 1651 "Microsoft Developer Files" and "Registered Users' Only". 1652 1653 Note that nslookup escapes spaces as "\032" for display purposes, 1654 but a graphical DNS-SD browser does not. 1655 165615.2 Question: What FTP servers allow anonymous access? 1657 1658 nslookup -q=ptr _anon._sub._ftp._tcp.dns-sd.org 1659 _anon._sub._ftp._tcp.dns-sd.org 1660 name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org 1661 _anon._sub._ftp._tcp.dns-sd.org 1662 name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org 1663 1664 Answer: Only "Apple QuickTime Files" and "Microsoft Developer Files" 1665 allow anonymous access. 1666 166715.3 Question: How do I access "Apple QuickTime Files"? 1668 1669 nslookup -q=any "Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org." 1670 Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org 1671 text = "path=/quicktime" 1672 Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org 1673 priority = 0, weight = 0, port= 21 host = ftp.apple.com 1674 ftp.apple.com internet address = 17.254.0.27 1675 ftp.apple.com internet address = 17.254.0.31 1676 ftp.apple.com internet address = 17.254.0.26 1677 1678 Answer: You need to connect to ftp.apple.com, port 21, path 1679 "/quicktime". The addresses for ftp.apple.com are also given. 1680 1681 1682Expires 10th February 2007 Cheshire & Krochmal [Page 29] 1683 1684Internet Draft DNS-Based Service Discovery 10th August 2006 1685 1686 168716. User Interface Considerations 1688 1689 DNS-Based Service Discovery was designed by first giving careful 1690 consideration to what constitutes a good user experience for service 1691 discovery, and then designing a protocol with the features necessary 1692 to enable that good user experience. This section covers two issues 1693 in particular: Choice of factory-default names (and automatic 1694 renaming behavior) for devices advertising services, and the 1695 "continuous live update" user-experience model for clients 1696 browsing to discover services. 1697 1698 169916.1 Service Advertising User-Interface Considerations 1700 1701 When a DNS-SD service is advertised using Multicast DNS [mDNS], 1702 automatic name conflict and resolution will occur if there is already 1703 another service of the same type advertising with the same name. 1704 As described in the Multicast DNS specification [mDNS], upon a 1705 conflict, the service should: 1706 1707 1. Automatically select a new name (typically by appending 1708 or incrementing a digit at the end of the name), 1709 2. try advertising with the new name, and 1710 3. upon success, record the new name in persistent storage. 1711 1712 This renaming behavior is very important, because it is the key 1713 to providing user-friendly service names in the out-of-the-box 1714 factory-default configuration. Some product developers may not 1715 have realized this, because there are some products today where 1716 the factory-default name is distinctly unfriendly, containing 1717 random-looking strings of characters, like the device's Ethernet 1718 address in hexadecimal. This is unnecessary, and undesirable, because 1719 the point of the user-visible name is that it should be friendly and 1720 useful to human users. If the name is not unique on the local network 1721 the protocol will rememdy this as necessary. It is ironic that many 1722 of the devices with this mistake are network printers, given that 1723 these same printers also simultaneously support AppleTalk-over- 1724 Ethernet, with nice user-friendly default names (and automatic 1725 conflict detection and renaming). Examples of good factory-default 1726 names are as follows: 1727 1728 Brother 5070N 1729 Canon W2200 [ Apologies to makers of ] 1730 HP LaserJet 4600 [ DNS-SD/mDNS printers ] 1731 Lexmark W840 [ not listed. Email ] 1732 Okidata C5300 [ the authors and we'll ] 1733 Ricoh Aficio CL7100 [ add you to the list. ] 1734 Xerox Phaser 6200DX 1735 1736 1737 1738 1739 1740 1741 1742Expires 10th February 2007 Cheshire & Krochmal [Page 30] 1743 1744Internet Draft DNS-Based Service Discovery 10th August 2006 1745 1746 1747 To complete the case for why adding long ugly serial numbers to 1748 the end of names is neither necessary nor desirable, consider 1749 the cases where the user has (a) only one network printer, 1750 (b) two network printers, and (c) many network printers. 1751 1752 (a) In the case where the user has only one network printer, a simple 1753 name like (to use a vendor-neutral example) "Printer" is more 1754 user-friendly than an ugly name like "Printer 0001E68C74FB". 1755 Appending ugly hexadecimal goop to the end of the name to make 1756 sure the name is unique is irrelevant to a user who only has one 1757 printer anyway. 1758 1759 (b) In the case where the user gets a second network printer, 1760 having it detect that the name "Printer" is already in use 1761 and automatically instead name itself "Printer (2)" provides a 1762 good user experience. For the users, remembering that the old 1763 printer is "Printer" and the new one is "Printer (2)" is easy 1764 and intuitive. Seeing two printers called "Printer 0001E68C74FB" 1765 and "Printer 00306EC3FD1C" is a lot less helpful. 1766 1767 (c) In the case of a network with ten network printers, seeing a 1768 list of ten names all of the form "Printer xxxxxxxxxxxx" has 1769 effectively taken what was supposed to be a list of user-friendly 1770 rich-text names (supporting mixed case, spaces, punctuation, 1771 non-Roman characters and other symbols) and turned it into 1772 just about the worst user-interface imaginable: a list of 1773 incomprehensible random-looking strings of letters and digits. 1774 In a network with a lot of printers, it would be desirable for 1775 the people setting up the printers to take a moment to give each 1776 one a descriptive name, but in the event they don't, presenting 1777 the users with a list of sequentially-numbered printers is a much 1778 more desirable default user experience than showing a list of raw 1779 Ethernet addresses. 1780 1781 178216.2 Client Browsing User-Interface Considerations 1783 1784 Of particular concern in the design of DNS-SD was the dynamic nature 1785 of service discovery in a changing network environment. Other service 1786 discovery protocols have been designed with an implicit unstated 1787 assumption that the usage model is: 1788 1789 (a) client calls the service discovery code 1790 (b) client gets list of discovered services 1791 as of a particular instant in time, and then 1792 (c) client displays list for user to select from 1793 1794 Superficially this usage model seems reasonable, but the problem is 1795 that it's too optimistic. It only considers the success case, where 1796 the user successfully finds the service they're looking for. In the 1797 1798 1799Expires 10th February 2007 Cheshire & Krochmal [Page 31] 1800 1801Internet Draft DNS-Based Service Discovery 10th August 2006 1802 1803 1804 case where the user is looking for (say) a particular printer, and 1805 that printer's not turned on or not connected, the user first has 1806 to attempt to remedy the problem, and then has to click a "refresh" 1807 button to retry the service discovery (or, worse, dismiss the 1808 browsing window entirely, and open a new one to initiate a new 1809 network search attempt) to find out whether they were successful. 1810 Because nothing happens instantaneously in networking, and packets 1811 can be lost, necessitating some number of retransmissions, a service 1812 discovery search typically takes a few seconds. A fairly typical user 1813 experience model is: 1814 1815 (a) display an empty window, 1816 (b) display some animation like a searchlight 1817 sweeping back and forth for ten seconds, and then 1818 (c) at the end of the ten-second search, display 1819 a static list showing what was discovered. 1820 1821 Every time the user clicks the "refresh" button they have to endure 1822 another ten-second wait, and every time the discovered list is 1823 finally shown at the end of the ten-second wait, the moment it's 1824 displayed on the screen it's already beginning to get stale and 1825 out-of-date. 1826 1827 The service discovery user experience that the DNS-SD designers had 1828 in mind has some rather different properties: 1829 1830 1. Displaying a list of discovered services should be effectively 1831 instantaneous -- i.e. typically 1/10 second, not 10 seconds. 1832 1833 2. The list of discovered services should not be getting stale 1834 and out-of-date from the moment it's displayed. The list 1835 should be 'live' and should continue to update as new services 1836 are discovered. Because of the delays, packet losses, and 1837 retransmissions inherent in networking, it is to be expected 1838 that sometimes, after the initial list is displayed showing 1839 the majority of discovered services, a few remaining stragglers 1840 may continue to trickle in during the subsequent few seconds. 1841 Even after this initial stable list has been built and displayed, 1842 the list should remain 'live' and should continue to update. 1843 At any future time, be it minutes, hours, or even days later, 1844 if a new service of the desired type is discovered, it should be 1845 displayed in the list automatically, without the user having to 1846 click a "refresh" button or take any other explicit action to 1847 update the display. 1848 1849 3. With users getting to be in the habit of leaving service discovery 1850 windows open, and coming to expect to be able to rely on them 1851 to show a continuous 'live' view of current network reality, 1852 this creates a new requirement for us: deletion of stale services. 1853 When a service discovery list shows just a static snapshot at a 1854 moment in time, then the situation is simple: either a service was 1855 1856 1857Expires 10th February 2007 Cheshire & Krochmal [Page 32] 1858 1859Internet Draft DNS-Based Service Discovery 10th August 2006 1860 1861 1862 discovered and appears in the list, or it was not, and does not. 1863 However, when our list is live and updates continuously with the 1864 discovery of new services, then this implies the corollary: when 1865 a service goes away, it needs to *disappear* from the service 1866 discovery list. Otherwise, the result would be unacceptable: the 1867 service discovery list would simply grow monotonically over time, 1868 and would require a periodic "refresh" (or complete dismissal and 1869 recreation) to clear out old stale data. 1870 1871 4. With users getting to be in the habit of leaving service discovery 1872 windows open, these windows need to update not only in response 1873 to services coming and going, but also in response to changes 1874 in configuration and connectivity of the client machine itself. 1875 For example, if a user opens a service discovery window when no 1876 Ethernet cable is connected to the client machine, and the window 1877 appears empty with no discovered services, then when the user 1878 connects the cable the window should automatically populate with 1879 discovered services without requiring any explicit user action. 1880 If the user disconnects the Ethernet cable, all the services 1881 discovered via that network interface should automatically 1882 disappear. If the user switches from one 802.11 wireless base 1883 station to another, the service discovery window should 1884 automatically update to remove all the services discovered 1885 via the old wireless base station, and add all the services 1886 discovered via the new one. 1887 1888 If these requirements seem to be setting an arbitrary and 1889 unreasonably high standard for service discovery, bear in mind that 1890 while it may have seemed that way to some, back in the 1990s when 1891 these ideas were first proposed, in the years since then Apple and 1892 other companies have shipped multiple implementations of DNS-SD/mDNS 1893 that meet and exceed these requirements. In the years since Apple 1894 shipped Mac OS X 10.2 Jaguar with the Open Source mDNSResponder 1895 daemon, this service discovery "live browsing" paradigm has been 1896 adopted and implemented in a wide range of Apple and third-party 1897 applications, including printer discovery, Safari discovery of 1898 devices with embedded web servers (for status and configuration), 1899 iTunes music sharing, iPhoto photo sharing, the iChat Bonjour buddy 1900 list, SubEthaEdit multi-user document editing, etc. 1901 1902 With so many different applications demonstrating that the "live 1903 browsing" paradigm is clearly achievable, these four requirements 1904 should not be regarded as idealistic unattainable goals, but 1905 instead as the bare minimum baseline functionality that any 1906 credible service discovery protocol needs to achieve. 1907 1908 1909 1910 1911 1912 1913 1914 1915Expires 10th February 2007 Cheshire & Krochmal [Page 33] 1916 1917Internet Draft DNS-Based Service Discovery 10th August 2006 1918 1919 192017. IPv6 Considerations 1921 1922 IPv6 has no significant differences, except that the address of the 1923 SRV record's target host is given by the appropriate IPv6 address 1924 records instead of the IPv4 "A" record. 1925 1926 192718. Security Considerations 1928 1929 DNSSEC [RFC 2535] should be used where the authenticity of 1930 information is important. Since DNS-SD is just a naming and usage 1931 convention for records in the existing DNS system, it has no specific 1932 additional security requirements over and above those that already 1933 apply to DNS queries and DNS updates. 1934 1935 193619. IANA Considerations 1937 1938 This protocol builds on DNS SRV records [RFC 2782], and similarly 1939 requires IANA to assign unique application protocol names. 1940 Unfortunately, the "IANA Considerations" section of RFC 2782 says 1941 simply, "The IANA has assigned RR type value 33 to the SRV RR. 1942 No other IANA services are required by this document." 1943 Due to this oversight, IANA is currently prevented from carrying 1944 out the necessary function of assigning these unique identifiers. 1945 1946 This document proposes the following IANA allocation policy for 1947 unique application protocol names: 1948 1949 Allowable names: 1950 * Must be no more than fourteen characters long 1951 * Must consist only of: 1952 - lower-case letters 'a' - 'z' 1953 - digits '0' - '9' 1954 - the hyphen character '-' 1955 * Must begin and end with a lower-case letter or digit. 1956 * Must not already be assigned to some other protocol in the 1957 existing IANA "list of assigned application protocol names 1958 and port numbers" [ports]. 1959 1960 These identifiers are allocated on a First Come First Served basis. 1961 In the event of abuse (e.g. automated mass registrations, etc.), 1962 the policy may be changed without notice to Expert Review [RFC 2434]. 1963 1964 The textual nature of service/protocol names means that there are 1965 almost infinitely many more of them available than the finite set of 1966 65535 possible port numbers. This means that developers can produce 1967 experimental implementations using unregistered service names with 1968 little chance of accidental collision, providing service names are 1969 chosen with appropriate care. However, this document strongly 1970 1971 1972 1973Expires 10th February 2007 Cheshire & Krochmal [Page 34] 1974 1975Internet Draft DNS-Based Service Discovery 10th August 2006 1976 1977 1978 advocates that on or before the date a product ships, developers 1979 should properly register their service names. 1980 1981 Some developers have expressed concern that publicly registering 1982 their service names (and port numbers today) with IANA before a 1983 product ships may give away clues about that product to competitors. 1984 For this reason, IANA should consider allowing service name 1985 applications to remain secret for some period of time, much as US 1986 patent applications remain secret for two years after the date of 1987 filing. 1988 1989 This proposed IANA allocation policy is not in force until this 1990 document is published as an RFC. In the meantime, unique application 1991 protocol names may be registered according to the instructions at 1992 <http://www.dns-sd.org/ServiceTypes.html>. As of August 2006, there 1993 are roughly 300 application protocols in currently shipping products 1994 that have been so registered as using DNS-SD for service discovery. 1995 1996 199720. Acknowledgments 1998 1999 The concepts described in this document have been explored, developed 2000 and implemented with help from Richard Brown, Erik Guttman, Paul 2001 Vixie, and Bill Woodcock. 2002 2003 Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, 2004 Roger Pantos and Kiren Sekar for their significant contributions. 2005 2006 200721. Deployment History 2008 2009 The first implementations of DNS-Based Service Discovery and 2010 Multicast DNS were initially developed during the late 1990s, 2011 but the event that put them into the media spotlight was Steve Jobs 2012 demonstrating it live on stage in his keynote presentation opening 2013 Apple's annual Worldwide Developers Conference in May 2002, and 2014 announcing Apple's adoption of the technology throughout its hardware 2015 and software product line. Three months later, in August 2002, Apple 2016 shipped Mac OS X 10.2 Jaguar, and millions of end-users got their 2017 first exposure to Zero Configuration Networking with DNS-SD/mDNS 2018 in applications like Safari, iChat, and printer setup. A month later, 2019 in September 2002, Apple released the entire source code for the 2020 mDNS Responder daemon under its Darwin Open Source project, with 2021 code not just for Mac OS X, but also for a range of other platforms 2022 including Windows, VxWorks, Linux, Solaris, FreeBSD, etc. 2023 2024 Many hardware makers were quick to see the benefits of Zero 2025 Configuration Networking. Printer makers especially were enthusiastic 2026 early adopters, and within a year every major printer manufacturer 2027 was shipping DNS-SD/mDNS-enabled network printers. If you've bought 2028 any network printer at all in the last few years, it was probably one 2029 2030 2031Expires 10th February 2007 Cheshire & Krochmal [Page 35] 2032 2033Internet Draft DNS-Based Service Discovery 10th August 2006 2034 2035 2036 that supports DNS-SD/mDNS, even if you didn't know that at the time. 2037 For Mac OS X users, telling if you have DNS-SD/mDNS printers on your 2038 network is easy because they automatically appear in the "Bonjour" 2039 submenu in the "Print" dialog of every Mac application. Microsoft 2040 Windows users can get a similar experience by installing Bonjour for 2041 Windows (takes about 90 seconds, no restart required) and running the 2042 Bonjour for Windows Printer Setup Wizard [B4W]. 2043 2044 The Open Source community has produced several independent 2045 implementations of DNS-Based Service Discovery and Multicast DNS, 2046 some in C like Apple's mDNSResponder daemon, and others in a variety 2047 of different languages including Java, Python, Perl, and C#/Mono. 2048 2049 205022. Copyright Notice 2051 2052 Copyright (C) The Internet Society (2006). 2053 2054 This document is subject to the rights, licenses and restrictions 2055 contained in BCP 78, and except as set forth therein, the authors 2056 retain all their rights. For the purposes of this document, 2057 the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights 2058 in Contributions", published March 2005. 2059 2060 This document and the information contained herein are provided on an 2061 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2062 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2063 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2064 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2065 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2066 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089Expires 10th February 2007 Cheshire & Krochmal [Page 36] 2090 2091Internet Draft DNS-Based Service Discovery 10th August 2006 2092 2093 209423. Normative References 2095 2096 [ports] IANA list of assigned application protocol names and port 2097 numbers <http://www.iana.org/assignments/port-numbers> 2098 2099 [RFC 1033] Lottor, M., "Domain Administrators Operations Guide", 2100 RFC 1033, November 1987. 2101 2102 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 2103 Facilities", STD 13, RFC 1034, November 1987. 2104 2105 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 2106 Specifications", STD 13, RFC 1035, November 1987. 2107 2108 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 2109 Requirement Levels", RFC 2119, March 1997. 2110 2111 [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the 2112 location of services (DNS SRV)", RFC 2782, February 2000. 2113 2114 [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO 2115 10646", RFC 3629, November 2003. 2116 2117 [UAX15] "Unicode Normalization Forms" 2118 http://www.unicode.org/reports/tr15/ 2119 2120 212124. Informative References 2122 2123 [B4W] Bonjour for Windows <http://www.apple.com/bonjour/> 2124 2125 [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS", 2126 Internet-Draft (work in progress), 2127 draft-cheshire-dnsext-multicastdns-06.txt, August 2006. 2128 2129 [NBP] Cheshire, S., and M. Krochmal, 2130 "Requirements for a Protocol to Replace AppleTalk NBP", 2131 Internet-Draft (work in progress), 2132 draft-cheshire-dnsext-nbp-05.txt, August 2006. 2133 2134 [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP 2135 Vendor Extensions", RFC 2132, March 1997. 2136 2137 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 2138 System (DNS UPDATE)", RFC 2136, April 1997. 2139 2140 [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing 2141 an IANA Considerations Section in RFCs", RFC 2434, 2142 October 1998. 2143 2144 2145 2146 2147Expires 10th February 2007 Cheshire & Krochmal [Page 37] 2148 2149Internet Draft DNS-Based Service Discovery 10th August 2006 2150 2151 2152 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", 2153 RFC 2535, March 1999. 2154 2155 [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS) 2156 Dynamic Update", RFC 3007, November 2000. 2157 2158 [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration 2159 Protocol (DHCP) Domain Search Option", RFC 3397, November 2160 2002. 2161 2162 [SOAP] Nilo Mitra, "SOAP Version 1.2 Part 0: Primer", 2163 W3C Proposed Recommendation, 24 June 2003 2164 http://www.w3.org/TR/2003/REC-soap12-part0-20030624 2165 2166 [ZC] Williams, A., "Requirements for Automatic Configuration 2167 of IP Hosts", Internet-Draft (work in progress), 2168 draft-ietf-zeroconf-reqts-12.txt, September 2002. 2169 2170 [ZCHP] Guttman, E., "Zeroconf Host Profile Applicability 2171 Statement", Internet-Draft (work in progress), 2172 draft-ietf-zeroconf-host-prof-01.txt, July 2001. 2173 2174 217525. Authors' Addresses 2176 2177 Stuart Cheshire 2178 Apple Computer, Inc. 2179 1 Infinite Loop 2180 Cupertino 2181 California 95014 2182 USA 2183 2184 Phone: +1 408 974 3207 2185 EMail: rfc [at] stuartcheshire [dot] org 2186 2187 2188 Marc Krochmal 2189 Apple Computer, Inc. 2190 1 Infinite Loop 2191 Cupertino 2192 California 95014 2193 USA 2194 2195 Phone: +1 408 974 4368 2196 EMail: marc [at] apple [dot] com 2197 2198 2199 2200 2201 2202 2203 2204 2205Expires 10th February 2007 Cheshire & Krochmal [Page 38] 2206