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