1 Document: draft-cheshire-dnsext-dns-sd-03.txt Stuart Cheshire 2 Category: Standards Track Apple Computer, Inc. 3 Expires 7th December 2005 Marc Krochmal 4 Apple Computer, Inc. 5 7th June 2005 6 7 DNS-Based Service Discovery 8 9 <draft-cheshire-dnsext-dns-sd-03.txt> 10 11 12 Status of this Memo 13 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), 17 its areas, and its working groups. Note that other groups may 18 also distribute working documents as Internet-Drafts. 19 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 24 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 30 31 Distribution of this memo is unlimited. 32 33 34 Abstract 35 36 This document describes a convention for naming and structuring DNS 37 resource records. Given a type of service that a client is looking 38 for, and a domain in which the client is looking for that service, 39 this convention allows clients to discover a list of named instances 40 of that desired service, using only standard DNS queries. In short, 41 this is referred to as DNS-based Service Discovery, or DNS-SD. 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 Expires 7th December 2005 Cheshire & Krochmal [Page 1] 59 61 Internet Draft DNS-Based Service Discovery 7th June 2005 62 63 64 Table of Contents 65 66 1. Introduction....................................................3 67 2. Conventions and Terminology Used in this Document...............3 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....................................7 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.............................................16 83 6.7 Version Tag....................................................17 84 7. Application Protocol Names.....................................17 85 7.1 Service Name Length Limits.....................................19 86 8. Selective Instance Enumeration.................................20 87 9. Flagship Naming................................................20 88 10. Service Type Enumeration.......................................22 89 11. Populating the DNS with Information............................23 90 12. Relationship to Multicast DNS..................................23 91 13. Discovery of Browsing and Registration Domains.................24 92 14. DNS Additional Record Generation...............................25 93 15. Comparison with Alternative Service Discovery Protocols........26 94 16. Real Example...................................................28 95 17. IPv6 Considerations............................................29 96 18. Security Considerations........................................29 97 19. IANA Considerations............................................29 98 20. Acknowledgments................................................30 99 21. Copyright......................................................30 100 22. Normative References...........................................31 101 23. Informative References.........................................31 102 24. Authors' Addresses.............................................32 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 Expires 7th December 2005 Cheshire & Krochmal [Page 2] 118 120 Internet Draft DNS-Based Service Discovery 7th June 2005 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, all 145 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 2. Conventions and Terminology Used in this Document 167 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in "Key words for use in 171 RFCs to Indicate Requirement Levels" [RFC 2119]. 172 173 174 175 176 Expires 7th December 2005 Cheshire & Krochmal [Page 3] 177 179 Internet Draft DNS-Based Service Discovery 7th June 2005 180 181 182 3. Design Goals 183 184 A good service discovery protocol needs to have many properties, 185 three of which are mentioned below: 186 187 (i) The ability to query for services of a certain type in a certain 188 logical domain and receive in response a list of named instances 189 (network browsing, or "Service Instance Enumeration"). 190 191 (ii) Given a particular named instance, the ability to efficiently 192 resolve that instance name to the required information a client needs 193 to actually use the service, i.e. IP address and port number, at the 194 very least (Service Name Resolution). 195 196 (iii) Instance names should be relatively persistent. If a user 197 selects their default printer from a list of available choices today, 198 then tomorrow they should still be able to print on that printer -- 199 even if the IP address and/or port number where the service resides 200 have changed -- without the user (or their software) having to repeat 201 the network browsing step a second time. 202 203 In addition, if it is to become successful, a service discovery 204 protocol should be so simple to implement that virtually any 205 device capable of implementing IP should not have any trouble 206 implementing the service discovery software as well. 207 208 These goals are discussed in more detail in the remainder of this 209 document. A more thorough treatment of service discovery requirements 210 may be found in "Requirements for a Protocol to Replace AppleTalk 211 NBP" [NBP]. That document draws upon examples from two decades of 212 operational experience with AppleTalk Name Binding Protocol to 213 develop a list of universal requirements which are broadly applicable 214 to any potential service discovery protocol. 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 Expires 7th December 2005 Cheshire & Krochmal [Page 4] 236 238 Internet Draft DNS-Based Service Discovery 7th June 2005 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 laid 254 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 the 283 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 7th December 2005 Cheshire & Krochmal [Page 5] 295 297 Internet Draft DNS-Based Service Discovery 7th June 2005 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 2279]. 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 can 333 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 is a conventional 345 DNS domain name, consisting of as many labels as appropriate. For 346 example, "apple.com.", "cs.stanford.edu.", and "eng.us.ibm.com." are 347 all valid domain names for the <Domain> portion of the Service 348 Instance Name. 349 350 351 352 353 Expires 7th December 2005 Cheshire & Krochmal [Page 6] 354 356 Internet Draft DNS-Based Service Discovery 7th June 2005 357 358 359 4.2 User Interface Presentation 360 361 The names resulting from the PTR lookup are presented to the user in 362 a list for the user to select one (or more). Typically only the first 363 label is shown (the user-friendly <Instance> portion of the name). In 364 the common case, the <Service> and <Domain> are already known to the 365 user, these having been provided by the user in the first place, by 366 the act of indicating the service being sought, and the domain in 367 which to look for it. Note: The software handling the response 368 should be careful not to make invalid assumptions though, since it 369 *is* possible, though rare, for a service enumeration in one domain 370 to return the names of services in a different domain. Similarly, 371 when using subtypes (see "Selective Instance Enumeration") the 372 <Service> of the discovered instance my not be exactly the same as 373 the <Service> that was requested. 374 375 Having chosen the desired named instance, the Service Instance Name 376 may then be used immediately, or saved away in some persistent 377 user-preference data structure for future use, depending on what is 378 appropriate for the application in question. 379 380 381 4.3 Internal Handling of Names 382 383 If the <Instance>, <Service> and <Domain> portions are internally 384 concatenated together into a single string, then care must be taken 385 with the <Instance> portion, since it is allowed to contain any 386 characters, including dots. 387 388 Any dots in the <Instance> portion should be escaped by preceding 389 them with a backslash ("." becomes "\."). Likewise, any backslashes 390 in the <Instance> portion should also be escaped by preceding them 391 with a backslash ("\" becomes "\\"). Having done this, the three 392 components of the name may be safely concatenated. The 393 backslash-escaping allows literal dots in the name (escaped) to be 394 distinguished from label-separator dots (not escaped). 395 396 The resulting concatenated string may be safely passed to standard 397 DNS APIs like res_query(), which will interpret the string correctly 398 provided it has been escaped correctly, as described here. 399 400 401 4.4 What You See Is What You Get 402 403 Some service discovery protocols decouple the true service identifier 404 from the name presented to the user. The true service identifier used 405 by the protocol is an opaque unique id, often represented using a 406 long string of hexadecimal digits, and should never be seen by the 407 typical user. The name presented to the user is merely one of the 408 ephemeral attributes attached to this opaque identifier. 409 410 411 412 Expires 7th December 2005 Cheshire & Krochmal [Page 7] 413 415 Internet Draft DNS-Based Service Discovery 7th June 2005 416 417 418 The problem with this approach is that it decouples user perception 419 from reality: 420 421 * What happens if there are two service instances, with different 422 unique ids, but they have inadvertently been given the same 423 user-visible name? If two instances appear in an on-screen list 424 with the same name, how does the user know which is which? 425 426 * Suppose a printer breaks down, and the user replaces it with 427 another printer of the same make and model, and configures the new 428 printer with the exact same name as the one being replaced: 429 "Stuart's Printer". Now, when the user tries to print, the 430 on-screen print dialog tells them that their selected default 431 printer is "Stuart's Printer". When they browse the network to see 432 what is there, they see a printer called "Stuart's Printer", yet 433 when the user tries to print, they are told that the printer 434 "Stuart's Printer" can't be found. The hidden internal unique id 435 that the software is trying to find on the network doesn't match 436 the hidden internal unique id of the new printer, even though its 437 apparent "name" and its logical purpose for being there are the 438 same. To remedy this, the user typically has to delete the print 439 queue they have created, and then create a new (apparently 440 identical) queue for the new printer, so that the new queue will 441 contain the right hidden internal unique id. Having all this hidden 442 information that the user can't see makes for a confusing and 443 frustrating user experience, and exposing long ugly hexadecimal 444 strings to the user and forcing them to understand what they mean 445 is even worse. 446 447 * Suppose an existing printer is moved to a new department, and given 448 a new name and a new function. Changing the user-visible name of 449 that piece of hardware doesn't change its hidden internal unique 450 id. Users who had previously created print queues for that printer 451 will still be accessing the same hardware by its unique id, even 452 though the logical service that used to be offered by that hardware 453 has ceased to exist. 454 455 To solve these problems requires the user or administrator to be 456 aware of the supposedly hidden unique id, and to set its value 457 correctly as hardware is moved around, repurposed, or replaced, 458 thereby contradicting the notion that it is a hidden identifier that 459 human users never need to deal with. Requiring the user to understand 460 this expert behind-the-scenes knowledge of what is *really* going on 461 is just one more burden placed on the user when they are trying to 462 diagnose why their computers and network devices are not working as 463 expected. 464 465 These anomalies and counter-intuitive behaviors can be eliminated by 466 maintaining a tight bidirectional one-to-one mapping between what the 467 user sees on the screen and what is really happening "behind the 468 469 470 471 Expires 7th December 2005 Cheshire & Krochmal [Page 8] 472 474 Internet Draft DNS-Based Service Discovery 7th June 2005 475 476 477 curtain". If something is configured incorrectly, then that is 478 apparent in the familiar day-to-day user interface that everyone 479 understands, not in some little-known rarely-used "expert" interface. 480 481 In summary: The user-visible name is the primary identifier for a 482 service. If the user-visible name is changed, then conceptually the 483 service being offered is a different logical service -- even though 484 the hardware offering the service stayed the same. If the 485 user-visible name doesn't change, then conceptually the service being 486 offered is the same logical service -- even if the hardware offering 487 the service is new hardware brought in to replace some old equipment. 488 489 There are certainly arguments on both sides of this debate. 490 Nonetheless, the designers of any service discovery protocol have 491 to make a choice between between having the primary identifiers be 492 hidden, or having them be visible, and these are the reasons that we 493 chose to make them visible. We're not claiming that there are no 494 disadvantages of having primary identifiers be visible. We considered 495 both alternatives, and we believe that the few disadvantages 496 of visible identifiers are far outweighed by the many problems 497 caused by use of hidden identifiers. 498 499 500 4.5 Ordering of Service Instance Name Components 501 502 There have been questions about why services are named using DNS 503 Service Instance Names of the form: 504 505 Service Instance Name = <Instance> . <Service> . <Domain> 506 507 instead of: 508 509 Service Instance Name = <Service> . <Instance> . <Domain> 510 511 There are three reasons why it is beneficial to name service 512 instances with the parent domain as the most-significant (rightmost) 513 part of the name, then the abstract service type as the next-most 514 significant, and then the specific instance name as the 515 least-significant (leftmost) part of the name: 516 517 518 4.5.1. Semantic Structure 519 520 The facility being provided by browsing ("Service Instance 521 Enumeration") is effectively enumerating the leaves of a tree 522 structure. A given domain offers zero or more services. For each of 523 those service types, there may be zero or more instances of that 524 service. 525 526 527 528 529 530 Expires 7th December 2005 Cheshire & Krochmal [Page 9] 531 533 Internet Draft DNS-Based Service Discovery 7th June 2005 534 535 536 The user knows what type of service they are seeking. (If they are 537 running an FTP client, they are looking for FTP servers. If they have 538 a document to print, they are looking for entities that speak some 539 known printing protocol.) The user knows in which organizational or 540 geographical domain they wish to search. (The user does not want a 541 single flat list of every single printer on the planet, even if such 542 a thing were possible.) What the user does not know in advance is 543 whether the service they seek is offered in the given domain, or if 544 so, how many instances are offered, and the names of those instances. 545 Hence having the instance names be the leaves of the tree is 546 consistent with this semantic model. 547 548 Having the service types be the terminal leaves of the tree would 549 imply that the user knows the domain name, and already knows the 550 name of the service instance, but doesn't have any idea what the 551 service does. We would argue that this is a less useful model. 552 553 554 4.5.2. Network Efficiency 555 556 When a DNS response contains multiple answers, name compression works 557 more effectively if all the names contain a common suffix. If many 558 answers in the packet have the same <Service> and <Domain>, then each 559 occurrence of a Service Instance Name can be expressed using only the 560 <Instance> part followed by a two-byte compression pointer 561 referencing a previous appearance of "<Service>.<Domain>". This 562 efficiency would not be possible if the <Service> component appeared 563 first in each name. 564 565 566 4.5.3. Operational Flexibility 567 568 This name structure allows subdomains to be delegated along logical 569 service boundaries. For example, the network administrator at Example 570 Co. could choose to delegate the "_tcp.example.com." subdomain to a 571 different machine, so that the machine handling service discovery 572 doesn't have to be the same as the machine handling other day-to-day 573 DNS operations. (It *can* be the same machine if the administrator so 574 chooses, but the point is that the administrator is free to make that 575 choice.) Furthermore, if the network administrator wishes to delegate 576 all information related to IPP printers to a machine dedicated to 577 that specific task, this is easily done by delegating the 578 "_ipp._tcp.example.com." subdomain to the desired machine. It is also 579 convenient to set security policies on a per-zone/per-subdomain 580 basis. For example, the administrator may choose to enable DNS 581 Dynamic Update [RFC 2136] [RFC 3007] for printers registering in the 582 "_ipp._tcp.example.com." subdomain, but not for other 583 zones/subdomains. This easy flexibility would not exist if the 584 <Service> component appeared first in each name. 585 586 587 588 589 Expires 7th December 2005 Cheshire & Krochmal [Page 10] 590 592 Internet Draft DNS-Based Service Discovery 7th June 2005 593 594 595 5. Service Name Resolution 596 597 Given a particular Service Instance Name, when a client needs to 598 contact that service, it sends a DNS query for the SRV record of 599 that name. 600 601 The result of the DNS query is a SRV record giving the port number 602 and target host where the service may be found. 603 604 The use of SRV records is very important. There are only 65535 TCP 605 port numbers available. These port numbers are being allocated 606 one-per-application-protocol at an alarming rate. Some protocols like 607 the X Window System have a block of 64 TCP ports allocated 608 (6000-6063). If we start allocating blocks of 64 TCP ports at a time, 609 we will run out even faster. Using a different TCP port for each 610 different instance of a given service on a given machine is entirely 611 sensible, but allocating large static ranges, as was done for X, is a 612 very inefficient way to manage a limited resource. On any given host, 613 most TCP ports are reserved for services that will never run on that 614 particular host. This is very poor utilization of the limited port 615 space. Using SRV records allows each host to allocate its available 616 port numbers dynamically to those services running on that host that 617 need them, and then advertise the allocated port numbers via SRV 618 records. Allocating the available listening port numbers locally 619 on a per-host basis as needed allows much better utilization of the 620 available port space than today's centralized global allocation. 621 622 In some environments there may be no compelling reason to assign 623 managed names to every host, since every available service is 624 accessible by name anyway, as a first-class entity in its own right. 625 However, the DNS packet format and record format still require a host 626 name to link the target host referenced in the SRV record to the 627 address records giving the IPv4 and/or IPv6 addresses for that 628 hardware. In the case where no natural host name is available, the 629 SRV record may give its own name as the name of the target host, and 630 then the requisite address records may be attached to that same name. 631 It is perfectly permissible for a single name in the DNS hierarchy to 632 have multiple records of different type attached. (The only 633 restriction being that a given name may not have both a CNAME record 634 and other records at the same time.) 635 636 In the event that more than one SRV is returned, clients MUST 637 correctly interpret the priority and weight fields -- i.e. Lower 638 numbered priority servers should be used in preference to higher 639 numbered priority servers, and servers with equal priority should be 640 selected randomly in proportion to their relative weights. However, 641 in the overwhelmingly common case, a single advertised DNS-SD service 642 instance is described by exactly one SRV record, and in this common 643 case the priority and weight fields of the SRV record SHOULD both be 644 set to zero. 645 646 647 648 Expires 7th December 2005 Cheshire & Krochmal [Page 11] 649 651 Internet Draft DNS-Based Service Discovery 7th June 2005 652 653 654 6. Data Syntax for DNS-SD TXT Records 655 656 Some services discovered via Service Instance Enumeration may need 657 more than just an IP address and port number to properly identify the 658 service. For example, printing via the LPR protocol often specifies a 659 queue name. This queue name is typically short and cryptic, and need 660 not be shown to the user. It should be regarded the same way as the 661 IP address and port number -- it is one component of the addressing 662 information required to identify a specific instance of a service 663 being offered by some piece of hardware. Similarly, a file server may 664 have multiple volumes, each identified by its own volume name. A Web 665 server typically has multiple pages, each identified by its own URL. 666 In these cases, the necessary additional data is stored in a TXT 667 record with the same name as the SRV record. The specific nature of 668 that additional data, and how it is to be used, is service-dependent, 669 but the overall syntax of the data in the TXT record is standardized, 670 as described below. Every DNS-SD service MUST have a TXT record in 671 addition to its SRV record, with same name, even if the service has 672 no additional data to store and the TXT record contains no more than 673 a single zero byte. 674 675 676 6.1 General Format Rules for DNS TXT Records 677 678 A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total 679 length is indicated by the length given in the resource record header 680 in the DNS message. There is no way to tell directly from the data 681 alone how long it is (e.g. there is no length count at the start, or 682 terminating NULL byte at the end). (Note that when using Multicast 683 DNS [mDNS] the maximum packet size is 9000 bytes, which imposes an 684 upper limit on the size of TXT records of about 8800 bytes.) 685 686 The format of the data within a DNS TXT record is one or more 687 strings, packed together in memory without any intervening gaps or 688 padding bytes for word alignment. 689 690 The format of each constituent string within the DNS TXT record is a 691 single length byte, followed by 0-255 bytes of text data. 692 693 These format rules are defined in Section 3.3.14 of RFC 1035, and are 694 not specific to DNS-SD. DNS-SD simply specifies a usage convention 695 for what data should be stored in those constituent strings. 696 697 An empty TXT record containing zero strings is disallowed by RFC 698 1035. DNS-SD implementations MUST NOT emit empty TXT records. DNS-SD 699 implementations receiving empty TXT records MUST treat them as 700 equivalent to a one-byte TXT record containing a single zero byte 701 (i.e. a single empty string). 702 703 704 705 706 707 Expires 7th December 2005 Cheshire & Krochmal [Page 12] 708 710 Internet Draft DNS-Based Service Discovery 7th June 2005 711 712 713 6.2 DNS TXT Record Format Rules for use in DNS-SD 714 715 DNS-SD uses DNS TXT records to store arbitrary name/value pairs 716 conveying additional information about the named service. Each 717 name/value pair is encoded as its own constituent string within the 718 DNS TXT record, in the form "name=value". Everything up to the first 719 '=' character is the name. Everything after the first '=' character 720 to the end of the string (including subsequent '=' characters, if 721 any) is the value. Specific rules governing names and values are 722 given below. Each author defining a DNS-SD profile for discovering 723 instances of a particular type of service should define the base set 724 of name/value attributes that are valid for that type of service. 725 726 Using this standardized name/value syntax within the TXT record makes 727 it easier for these base definitions to be expanded later by defining 728 additional named attributes. If an implementation sees unknown 729 attribute names in a service TXT record, it MUST silently ignore 730 them. 731 732 The TCP (or UDP) port number of the service, and target host name, 733 are given in the SRV record. This information -- target host name and 734 port number -- MUST NOT be duplicated using name/value attributes in 735 the TXT record. 736 737 The intention of DNS-SD TXT records is to convey a small amount of 738 useful additional information about a service. Ideally it SHOULD NOT 739 be necessary for a client to retrieve this additional information 740 before it can usefully establish a connection to the service. For a 741 well-designed TCP-based application protocol, it should be possible, 742 knowing only the host name and port number, to open a connection to 743 that listening process, and then perform version- or feature- 744 negotiation to determine the capabilities of the service instance. 745 For example, when connecting to an AppleShare server over TCP, the 746 client enters into a protocol exchange with the server to determine 747 which version of the AppleShare protocol the server implements, and 748 which optional features or capabilities (if any) are available. For a 749 well-designed application protocol, clients should be able to connect 750 and use the service even if there is no information at all in the TXT 751 record. In this case, the information in the TXT record should be 752 viewed as a performance optimization -- when a client discovers many 753 instances of a service, the TXT record allows the client to know some 754 rudimentary information about each instance without having to open a 755 TCP connection to each one and interrogate every service instance 756 separately. Extreme care should be taken when doing this to ensure 757 that the information in the TXT record is in agreement with the 758 information retrieved by a client connecting over TCP. 759 760 There are legacy protocols which provide no feature negotiation 761 capability, and in these cases it may be useful to convey necessary 762 information in the TXT record. For example, when printing using the 763 old Unix LPR (port 515) protocol, the LPR service provides no way for 764 765 766 Expires 7th December 2005 Cheshire & Krochmal [Page 13] 767 769 Internet Draft DNS-Based Service Discovery 7th June 2005 770 771 772 the client to determine whether a particular printer accepts 773 PostScript, or what version of PostScript, etc. In this case it is 774 appropriate to embed this information in the TXT record, because the 775 alternative is worse -- passing around written instructions to the 776 users, arcane manual configuration of "/etc/printcap" files, etc. 777 778 779 6.3 DNS-SD TXT Record Size 780 781 The total size of a typical DNS-SD TXT record is intended to be small 782 -- 200 bytes or less. 783 784 In cases where more data is justified (e.g. LPR printing), keeping 785 the total size under 400 bytes should allow it to fit in a single 786 standard 512-byte DNS message. (This standard DNS message size is 787 defined in RFC 1035.) 788 789 In extreme cases where even this is not enough, keeping the size of 790 the TXT record under 1300 bytes should allow it to fit in a single 791 1500-byte Ethernet packet. 792 793 Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this 794 time. 795 796 797 6.4 Rules for Names in DNS-SD Name/Value Pairs 798 799 The "Name" MUST be at least one character. Strings beginning with an 800 '=' character (i.e. the name is missing) SHOULD be silently ignored. 801 802 The characters of "Name" MUST be printable US-ASCII values 803 (0x20-0x7E), excluding '=' (0x3D). 804 805 Spaces in the name are significant, whether leading, trailing, or in 806 the middle -- so don't include any spaces unless you really intend 807 that! 808 809 Case is ignored when interpreting a name, so "papersize=A4", 810 "PAPERSIZE=A4" and "Papersize=A4" are all identical. 811 812 If there is no '=', then it is a boolean attribute, and is simply 813 identified as being present, with no value. 814 815 A given attribute name may appear at most once in a TXT record. If a 816 client receives a TXT record containing the same attribute name more 817 than once, then the client MUST silently ignore all but the first 818 occurrence of that attribute. For client implementations that process 819 a DNS-SD TXT record from start to end, placing name/value pairs into 820 a hash table, using the name as the hash table key, this means that 821 if the implementation attempts to add a new name/value pair into the 822 table and finds an entry with the same name already present, then the 823 824 825 Expires 7th December 2005 Cheshire & Krochmal [Page 14] 826 828 Internet Draft DNS-Based Service Discovery 7th June 2005 829 830 831 new entry being added should be silently discarded instead. For 832 client implementations that retrieve name/value pairs by searching 833 the TXT record for the requested name, they should search the TXT 834 record from the start, and simply return the first matching name they 835 find. The reason for this simplifying rule is to facilitate the 836 creation of client libraries that parse the TXT record into an 837 internal data structure, such as a hash table or dictionary object 838 that maps from names to values, and then make that abstraction 839 available to client code. 840 841 When examining a TXT record for a given named attribute, there are 842 therefore four broad categories of results which may be returned: 843 844 * Attribute not present (Absent) 845 846 * Attribute present, with no value 847 (e.g. "Anon Allowed" -- server allows anonymous connections) 848 849 * Attribute present, with empty value (e.g. "Installed PlugIns=" -- 850 server supports plugins, but none are presently installed) 851 852 * Attribute present, with non-empty value 853 (e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4") 854 855 Each author defining a DNS-SD profile for discovering instances of a 856 particular type of service should define the interpretation of these 857 different kinds of result. For example, for some keys, there may be 858 a natural true/false boolean interpretation: 859 860 * Present implies 'true' 861 * Absent implies 'false' 862 863 For other keys it may be sensible to define other semantics, such as 864 value/no-value/unknown: 865 866 * Present with value implies that value. 867 E.g. "Color=4" for a four-color ink-jet printer, 868 or "Color=6" for a six-color ink-jet printer. 869 870 * Present with empty value implies 'false'. E.g. Not a color printer. 871 872 * Absent implies 'Unknown'. E.g. A print server connected to some 873 unknown printer where the print server doesn't actually know if the 874 printer does color or not -- which gives a very bad user experience 875 and should be avoided wherever possible. 876 877 (Note that this is a hypothetical example, not an example of actual 878 name/value keys used by DNS-SD network printers.) 879 880 As a general rule, attribute names that contain no dots are defined 881 as part of the open-standard definition written by the person or 882 883 884 Expires 7th December 2005 Cheshire & Krochmal [Page 15] 885 887 Internet Draft DNS-Based Service Discovery 7th June 2005 888 889 890 group defining the DNS-SD profile for discovering that particular 891 service type. Vendor-specific extensions should be given names of the 892 form "keyname.company.com=value", using a domain name legitimately 893 registered to the person or organization creating the vendor-specific 894 key. This reduces the risk of accidental conflict if different 895 organizations each define their own vendor-specific keys. 896 897 898 6.5 Rules for Values in DNS-SD Name/Value Pairs 899 900 If there is an '=', then everything after the first '=' to the end of 901 the string is the value. The value can contain any eight-bit values 902 including '='. Leading or trailing spaces are part of the value, so 903 don't put them there unless you intend them to be there. Any 904 quotation marks around the value are part of the value, so don't put 905 them there unless you intend them to be part of the value. 906 907 The value is opaque binary data. Often the value for a particular 908 attribute will be US-ASCII (or UTF-8) text, but it is legal for a 909 value to be any binary data. For example, if the value of a key is an 910 IPv4 address, that address should simply be stored as four bytes of 911 binary data, not as a variable-length 7-15 byte ASCII string giving 912 the address represented in textual dotted decimal notation. 913 914 Generic debugging tools should generally display all attribute values 915 as a hex dump, with accompanying text alongside displaying the UTF-8 916 interpretation of those bytes, except for attributes where the 917 debugging tool has embedded knowledge that the value is some other 918 kind of data. 919 920 Authors defining DNS-SD profiles SHOULD NOT convert binary attribute 921 data types into printable text (e.g. using hexadecimal, Base-64 or UU 922 encoding) merely for the sake of making the data be printable text 923 when seen in a generic debugging tool. Doing this simply bloats the 924 size of the TXT record, without actually making the data any more 925 understandable to someone looking at it in a generic debugging tool. 926 927 928 6.6 Example TXT Record 929 930 The TXT record below contains three syntactically valid name/value 931 pairs. (The meaning of these name/value pairs, if any, would depend 932 on the definitions pertaining to the service in question that is 933 using them.) 934 935 --------------------------------------------------------------- 936 | 0x0A | name=value | 0x08 | paper=A4 | 0x0E | DNS-SD Is Cool | 937 --------------------------------------------------------------- 938 939 940 941 942 943 Expires 7th December 2005 Cheshire & Krochmal [Page 16] 944 946 Internet Draft DNS-Based Service Discovery 7th June 2005 947 948 949 6.7 Version Tag 950 951 It is recommended that authors defining DNS-SD profiles include an 952 attribute of the form "txtvers=xxx" in their definition, and require 953 it to be the first name/value pair in the TXT record. This 954 information in the TXT record can be useful to help clients maintain 955 backwards compatibility with older implementations if it becomes 956 necessary to change or update the specification over time. Even if 957 the profile author doesn't anticipate the need for any future 958 incompatible changes, having a version number in the specification 959 provides useful insurance should incompatible changes become 960 unavoidable. Clients SHOULD ignore TXT records with a txtvers number 961 higher (or lower) than the version(s) they know how to interpret. 962 963 Note that the version number in the txtvers tag describes the version 964 of the TXT record specification being used to create this TXT record, 965 not the version of the application protocol that will be used if the 966 client subsequently decides to contact that service. Ideally, every 967 DNS-SD TXT record specification starts at txtvers=1 and stays that 968 way forever. Improvements can be made by defining new keys that older 969 clients silently ignore. The only reason to increment the version 970 number is if the old specification is subsequently found to be so 971 horribly broken that there's no way to do a compatible forward 972 revision, so the txtvers number has to be incremented to tell all the 973 old clients they should just not even try to understand this new TXT 974 record. 975 976 If there is a need to indicate which version number(s) of the 977 application protocol the service implements, the recommended key 978 name for this is "protovers". 979 980 981 7. Application Protocol Names 982 983 The <Service> portion of a Service Instance Name consists of a pair 984 of DNS labels, following the established convention for SRV records 985 [RFC 2782], namely: the first label of the pair is the Application 986 Protocol Name, and the second label is either "_tcp" or "_udp". 987 988 Wise selection of the Application Protocol Name is very important, 989 and the choice is not always as obvious as it may appear. 990 991 Application Protocol Names may be no more than fourteen characters, 992 conforming to normal DNS host name rules: Only lower-case letters, 993 digits, and hyphens; must begin and end with lower-case letter or 994 digit. 995 996 In some cases, the Application Protocol Name merely names and refers 997 to the on-the-wire message format and semantics being used. FTP is 998 "ftp", IPP printing is "ipp", and so on. 999 1000 1001 1002 Expires 7th December 2005 Cheshire & Krochmal [Page 17] 1003 1005 Internet Draft DNS-Based Service Discovery 7th June 2005 1006 1007 1008 However, it is common to "borrow" an existing protocol and repurpose 1009 it for a new task. This is entirely sensible and sound engineering 1010 practice, but that doesn't mean that the new protocol is providing 1011 the same semantic service as the old one, even if it borrows the same 1012 message formats. For example, the local network music playing 1013 protocol implemented by iTunes on Macintosh and Windows is little 1014 more than "HTTP GET" commands. However, that does *not* mean that it 1015 is sensible or useful to try to access one of these music servers by 1016 connecting to it with a standard web browser. Consequently, the 1017 DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp" 1018 (Digital Audio Access Protocol), not "_http._tcp". Advertising 1019 "_http._tcp" service would cause iTunes servers to show up in 1020 conventional Web browsers (Safari, Camino, OmniWeb, Opera, Netscape, 1021 Internet Explorer, etc.) which is little use since it offers no pages 1022 containing human-readable content. Similarly, browsing for 1023 "_http._tcp" service would cause iTunes to find generic web servers, 1024 such as the embedded web servers in devices like printers, which is 1025 little use since printers generally don't have much music to offer. 1026 1027 Similarly, NFS is built on top of SUN RPC, but that doesn't mean it 1028 makes sense for an NFS server to advertise that it provides "SUN RPC" 1029 service. Likewise, Microsoft SMB file service is built on top of 1030 Netbios running over IP, but that doesn't mean it makes sense for an 1031 SMB file server to advertise that it provides "Netbios-over-IP" 1032 service. The DNS-SD name of a service needs to encapsulate both the 1033 "what" (semantics) and the "how" (protocol implementation) of the 1034 service, since knowledge of both is necessary for a client to 1035 usefully use the service. Merely advertising that a service was built 1036 on top of SUN RPC is no use if the client has no idea what the 1037 service actually does. 1038 1039 Another common mistake is to assume that the service type advertised 1040 by iTunes should be "_daap._http._tcp." This is also incorrect. Part 1041 of the confusion here is that the presence of "_tcp" or "_udp" in the 1042 <Service> portion of a Service Instance Name has led people to assume 1043 that the structure of a service name has to reflect the internal 1044 structure of how the protocol was implemented. This is not correct. 1045 1046 The "_tcp" or "_udp" should be regarded as little more than 1047 boilerplate text, and care should be taken not to attach too much 1048 importance to it. Some might argue that the "_tcp" or "_udp" should 1049 not be there at all, but this format is defined by RFC 2782, and 1050 that's not going to change. In addition, the presence of "_tcp" has 1051 the useful side-effect that it provides a convenient delegation point 1052 to hand off control to a different DNS server, if so desired. 1053 1054 1055 1056 1057 1058 1059 1060 1061 Expires 7th December 2005 Cheshire & Krochmal [Page 18] 1062 1064 Internet Draft DNS-Based Service Discovery 7th June 2005 1065 1066 1067 7.1 Service Name Length Limits 1068 1069 As described above, application protocol names are allowed to be up 1070 to fourteen characters long. The reason for this limit is to leave 1071 as many bytes of the domain name as possible available for use 1072 by both the network administrator (choosing service domain names) 1073 and the end user (choosing instance names). 1074 1075 A domain name may be up to 255 bytes long, including the final 1076 terminating root label at the end. Domain names used by DNS-SD 1077 take the following forms: 1078 1079 <Instance>.<app>._tcp.<servicedomain>.<parentdomain>. 1080 <sub>._sub.<app>._tcp.<servicedomain>.<parentdomain>. 1081 1082 The first example shows a service instance name, i.e. the name of the 1083 service's SRV and TXT records. The second shows a subtype browsing 1084 name, i.e. the name of a PTR record pointing to service instance 1085 names. 1086 1087 The instance name <Instance> may be up to 63 bytes. Including the 1088 length byte used by the DNS format when the name is stored in a 1089 packet, that makes 64 bytes. 1090 1091 When using subtypes, the subtype identifier is allowed to be up to 1092 63 bytes, plus the length byte, making 64. Including the "_sub" 1093 and its length byte, this makes 69 bytes. 1094 1095 The application protocol name <app> may be up to 14 bytes, plus the 1096 underscore and length byte, making 16. Including the "_udp" or "_tcp" 1097 and its length byte, this makes 21 bytes. 1098 1099 Typically, DNS-SD service records are placed into subdomains of their 1100 own beneath a company's existing domain name. Since these subdomains 1101 are intended to be accessed through graphical user interfaces, not 1102 typed on a command-line they are frequently long and descriptive. 1103 Including the length byte, the user-visible service domain may be up 1104 to 64 bytes. 1105 1106 The terminating root label at the end counts as one byte. 1107 1108 Of our available 255 bytes, we have now accounted for 69+21+64+1 = 1109 155 bytes. This leaves 100 bytes to accommodate the organization's 1110 existing domain name <parentdomain>. When used with Multicast DNS, 1111 <parentdomain> is "local", which easily fits. When used with parent 1112 domains of 100 bytes or less, the full functionality of DNS-SD is 1113 available without restriction. When used with parent domains longer 1114 than 100 bytes, the protocol risks exceeding the maximum possible 1115 length of domain names, causing failures. In this case, careful 1116 choice of short <servicedomain> names can help avoid overflows. If 1117 the <servicedomain> and <parentdomain> are too long, then service 1118 1119 1120 Expires 7th December 2005 Cheshire & Krochmal [Page 19] 1121 1123 Internet Draft DNS-Based Service Discovery 7th June 2005 1124 1125 1126 instances with long instance names will not be discoverable or 1127 resolvable, and applications making use of long subtype names may 1128 fail. 1129 1130 Because of this constraint, we choose to limit Application Protocol 1131 Names to 14 characters or less. Allowing more characters would not 1132 add to the expressive power of the protocol, and would needlessly 1133 lower the limit on the maximum <parentdomain> length that may be 1134 safely used. 1135 1136 1137 8. Selective Instance Enumeration 1138 1139 This document does not attempt to define an arbitrary query language 1140 for service discovery, nor do we believe one is necessary. 1141 1142 However, there are some circumstances where narrowing the list of 1143 results may be useful. A Web browser client that is able to retrieve 1144 HTML documents via HTTP and display them may also be able to retrieve 1145 HTML documents via FTP and display them, but only in the case of FTP 1146 servers that allow anonymous login. For that Web browser, discovering 1147 all FTP servers on the network is not useful. The Web browser only 1148 wants to discover FTP servers that it is able to talk to. In this 1149 case, a subtype of "_ftp._tcp" could be defined. Instead of issuing a 1150 query for "_ftp._tcp.<Domain>", the Web browser issues a query for 1151 "_anon._sub._ftp._tcp.<Domain>", where "_anon" is a defined subtype 1152 of "_ftp._tcp". The response to this query only includes the names of 1153 SRV records for FTP servers that are willing to allow anonymous 1154 login. 1155 1156 Note that the FTP server's Service Instance Name is unchanged -- it 1157 is still something of the form "The Server._ftp._tcp.example.com." 1158 The subdomain in which FTP server SRV records are registered defines 1159 the namespace within which FTP server names are unique. Additional 1160 subtypes (e.g. "_anon") of the basic service type (e.g. "_ftp._tcp") 1161 serve to narrow the list of results, not to create more namespace. 1162 1163 As with the TXT record name/value pairs, the list of possible 1164 subtypes, if any, are defined and specified separately for each basic 1165 service type. 1166 1167 1168 9. Flagship Naming 1169 1170 In some cases, there may be several network protocols available which 1171 all perform roughly the same logical function. For example, the 1172 printing world has the LPR protocol, and the Internet Printing 1173 Protocol (IPP), both of which cause printed sheets to be emitted from 1174 printers in much the same way. In addition, many printer vendors send 1175 their own proprietary page description language (PDL) data over a TCP 1176 connection to TCP port 9100, herein referred to as the 1177 1178 1179 Expires 7th December 2005 Cheshire & Krochmal [Page 20] 1180 1182 Internet Draft DNS-Based Service Discovery 7th June 2005 1183 1184 1185 "pdl-datastream" protocol. In an ideal world we would have only one 1186 network printing protocol, and it would be sufficiently good that no 1187 one felt a compelling need to invent a different one. However, in 1188 practice, multiple legacy protocols do exist, and a service discovery 1189 protocol has to accommodate that. 1190 1191 Many printers implement all three printing protocols: LPR, IPP, and 1192 pdl-datastream. For the benefit of clients that may speak only one of 1193 those protocols, all three are advertised. 1194 1195 However, some clients may implement two, or all three of those 1196 printing protocols. When a client looks for all three service types 1197 on the network, it will find three distinct services -- an LPR 1198 service, an IPP service, and a pdl-datastream service -- all of which 1199 cause printed sheets to be emitted from the same physical printer. 1200 1201 In the case of multiple protocols like this that all perform 1202 effectively the same function, the client should suppress duplicate 1203 names and display each name only once. When the user prints to a 1204 given named printer, the printing client is responsible for choosing 1205 the protocol which will best achieve the desired effect, without, for 1206 example, requiring the user to make a manual choice between LPR and 1207 IPP. 1208 1209 As described so far, this all works very well. However, consider some 1210 future printer that only supports IPP printing, and some other future 1211 printer that only supports pdl-datastream printing. The name spaces 1212 for different service types are intentionally disjoint -- it is 1213 acceptable and desirable to be able to have both a file server called 1214 "Sales Department" and a printer called "Sales Department". However, 1215 it is not desirable, in the common case, to have two different 1216 printers both called "Sales Department", just because those printers 1217 are implementing different protocols. 1218 1219 To help guard against this, when there are two or more network 1220 protocols which perform roughly the same logical function, one of the 1221 protocols is declared the "flagship" of the fleet of related 1222 protocols. Typically the flagship protocol is the oldest and/or 1223 best-known protocol of the set. 1224 1225 If a device does not implement the flagship protocol, then it instead 1226 creates a placeholder SRV record (priority=0, weight=0, port=0, 1227 target host = hostname of device) with that name. If, when it 1228 attempts to create this SRV record, it finds that a record with the 1229 same name already exists, then it knows that this name is already 1230 taken by some entity implementing at least one of the protocols from 1231 the class, and it must choose another. If no SRV record already 1232 exists, then the act of creating it stakes a claim to that name so 1233 that future devices in the same class will detect a conflict when 1234 they try to use it. The SRV record needs to contain the target host 1235 name in order for the conflict detection rules to operate. If two 1236 1237 1238 Expires 7th December 2005 Cheshire & Krochmal [Page 21] 1239 1241 Internet Draft DNS-Based Service Discovery 7th June 2005 1242 1243 1244 different devices were to create placeholder SRV records both using a 1245 null target host name (just the root label), then the two SRV records 1246 would be seen to be in agreement so no conflict would be registered. 1247 1248 By defining a common well-known flagship protocol for the class, 1249 future devices that may not even know about each other's protocols 1250 establish a common ground where they can coordinate to verify 1251 uniqueness of names. 1252 1253 No PTR record is created advertising the presence of empty flagship 1254 SRV records, since they do not represent a real service being 1255 advertised. 1256 1257 1258 10. Service Type Enumeration 1259 1260 In general, clients are not interested in finding *every* service on 1261 the network, just the services that the client knows how to talk to. 1262 (Software designers may *think* there's some value to finding *every* 1263 service on the network, but that's just wooly thinking.) 1264 1265 However, for problem diagnosis and network management tools, it may 1266 be useful for network administrators to find the list of advertised 1267 service types on the network, even if those service names are just 1268 opaque identifiers and not particularly informative in isolation. 1269 1270 For this reason, a special meta-query is defined. A DNS query for 1271 PTR records with the name "_services._dns-sd._udp.<Domain>" yields 1272 a list of PTR records, where the rdata of each PTR record is the 1273 name of a service type. A subsequent query for PTR records with 1274 one of those names yields a list of instances of that service type. 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 Expires 7th December 2005 Cheshire & Krochmal [Page 22] 1298 1300 Internet Draft DNS-Based Service Discovery 7th June 2005 1301 1302 1303 11. Populating the DNS with Information 1304 1305 How the SRV and PTR records that describe services and allow them to 1306 be enumerated make their way into the DNS is outside the scope of 1307 this document. However, it can happen easily in any of a number of 1308 ways, for example: 1309 1310 On some networks, the administrator might manually enter the records 1311 into the name server's configuration file. 1312 1313 A network monitoring tool could output a standard zone file to be 1314 read into a conventional DNS server. For example, a tool that can 1315 find Apple LaserWriters using AppleTalk NBP could find the list of 1316 printers, communicate with each one to find its IP address, 1317 PostScript version, installed options, etc., and then write out a DNS 1318 zone file describing those printers and their capabilities using DNS 1319 resource records. That information would then be available to DNS-SD 1320 clients that don't implement AppleTalk NBP, and don't want to. 1321 1322 Future IP printers could use Dynamic DNS Update [RFC 2136] to 1323 automatically register their own SRV and PTR records with the DNS 1324 server. 1325 1326 A printer manager device which has knowledge of printers on the 1327 network through some other management protocol could also use Dynamic 1328 DNS Update [RFC 2136]. 1329 1330 Alternatively, a printer manager device could implement enough of the 1331 DNS protocol that it is able to answer DNS queries directly, and 1332 Example Co.'s main DNS server could delegate the 1333 _ipp._tcp.example.com subdomain to the printer manager device. 1334 1335 Zeroconf printers answer Multicast DNS queries on the local link 1336 for appropriate PTR and SRV names ending with ".local." [mDNS] 1337 1338 1339 12. Relationship to Multicast DNS 1340 1341 DNS-Based Service Discovery is only peripherally related to Multicast 1342 DNS, in that the standard unicast DNS queries used by DNS-SD may also 1343 be performed using multicast when appropriate, which is particularly 1344 beneficial in Zeroconf environments [ZC]. 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 Expires 7th December 2005 Cheshire & Krochmal [Page 23] 1357 1359 Internet Draft DNS-Based Service Discovery 7th June 2005 1360 1361 1362 13. Discovery of Browsing and Registration Domains (Domain Enumeration) 1363 1364 One of the main reasons for DNS-Based Service Discovery is so that 1365 when a visiting client (e.g. a laptop computer) arrives at a new 1366 network, it can discover what services are available on that network 1367 without manual configuration. This logic that applies to discovering 1368 services without manual configuration also applies to discovering the 1369 domains in which services are registered without requiring manual 1370 configuration. 1371 1372 This discovery is performed recursively, using Unicast or Multicast 1373 DNS. Five special RR names are reserved for this purpose: 1374 1375 b._dns-sd._udp.<domain>. 1376 db._dns-sd._udp.<domain>. 1377 r._dns-sd._udp.<domain>. 1378 dr._dns-sd._udp.<domain>. 1379 lb._dns-sd._udp.<domain>. 1380 1381 By performing PTR queries for these names, a client can learn, 1382 respectively: 1383 1384 o A list of domains recommended for browsing 1385 1386 o A single recommended default domain for browsing 1387 1388 o A list of domains recommended for registering services using 1389 Dynamic Update 1390 1391 o A single recommended default domain for registering services. 1392 1393 o The final query shown yields the "legacy browsing" domain. 1394 Sophisticated client applications that care to present choices of 1395 domain to the user, use the answers learned from the previous four 1396 queries to discover those domains to present. In contrast, many 1397 current applications browse without specifying an explicit domain, 1398 allowing the operating system to automatically select an 1399 appropriate domain on their behalf. It is for this class of 1400 application that the "legacy browsing" query is provided, to allow 1401 the network administrator to communicate to the client operating 1402 systems which domain should be used for these applications. 1403 1404 These domains are purely advisory. The client or user is free to 1405 browse and/or register services in any domains. The purpose of these 1406 special queries is to allow software to create a user-interface that 1407 displays a useful list of suggested choices to the user, from which 1408 they may make a suitable selection, or ignore the offered suggestions 1409 and manually enter their own choice. 1410 1411 1412 1413 1414 1415 Expires 7th December 2005 Cheshire & Krochmal [Page 24] 1416 1418 Internet Draft DNS-Based Service Discovery 7th June 2005 1419 1420 1421 The <domain> part of the name may be "local" (meaning "perform the 1422 query using link-local multicast) or it may be learned through some 1423 other mechanism, such as the DHCP "Domain" option (option code 15) 1424 [RFC 2132] or the DHCP "Domain Search" option (option code 119) 1425 [RFC 3397]. 1426 1427 The <domain> part of the name may also be derived from the host's IP 1428 address. The host takes its IP address, and calculates the logical 1429 AND of that address and its subnet mask, to derive the 'base' address 1430 of the subnet. It then constructs the conventional DNS "reverse 1431 mapping" name corresponding to that base address, and uses that as 1432 the <domain> part of the name for the queries described above. 1433 For example, if a host has address 192.168.12.34, with subnet mask 1434 255.255.0.0, then the 'base' address of the subnet is 192.168.0.0, 1435 and to discover the recommended legacy browsing domain for devices 1436 on this subnet, the host issues a DNS PTR query for the name 1437 "lb._dns-sd._udp.0.0.168.192.in-addr.arpa." 1438 1439 Sophisticated clients may perform domain enumeration queries both in 1440 "local" and in one or more unicast domains, and then present the user 1441 with an aggregate result, combining the information received from all 1442 sources. 1443 1444 1445 14. DNS Additional Record Generation 1446 1447 DNS has an efficiency feature whereby a DNS server may place 1448 additional records in the Additional Section of the DNS Message. 1449 These additional records are typically records that the client did 1450 not explicitly request, but the server has reasonable grounds to 1451 expect that the client might request them shortly. 1452 1453 This section recommends which additional records should be generated 1454 to improve network efficiency for both unicast and multicast DNS-SD 1455 responses. 1456 1457 1458 14.1 PTR Records 1459 1460 When including a PTR record in a response packet, the 1461 server/responder SHOULD include the following additional records: 1462 1463 o The SRV record(s) named in the PTR rdata. 1464 o The TXT record(s) named in the PTR rdata. 1465 o All address records (type "A" and "AAAA") named in the SRV rdata. 1466 1467 1468 1469 1470 1471 1472 1473 1474 Expires 7th December 2005 Cheshire & Krochmal [Page 25] 1475 1477 Internet Draft DNS-Based Service Discovery 7th June 2005 1478 1479 1480 14.2 SRV Records 1481 1482 When including an SVR record in a response packet, the 1483 server/responder SHOULD include the following additional records: 1484 1485 o All address records (type "A" and "AAAA") named in the SRV rdata. 1486 1487 1488 14.3 TXT Records 1489 1490 When including a TXT record in a response packet, no additional 1491 records are required. 1492 1493 1494 14.4 Other Record Types 1495 1496 In response to address queries, or other record types, no additional 1497 records are required by this document. 1498 1499 1500 15. Comparison with Alternative Service Discovery Protocols 1501 1502 Over the years there have been many proposed ways to do network 1503 service discovery with IP, but none achieved ubiquity in the 1504 marketplace. Certainly none has achieved anything close to the 1505 ubiquity of today's deployment of DNS servers, clients, and other 1506 infrastructure. 1507 1508 The advantage of using DNS as the basis for service discovery is that 1509 it makes use of those existing servers, clients, protocols, 1510 infrastructure, and expertise. Existing network analyzer tools 1511 already know how to decode and display DNS packets for network 1512 debugging. 1513 1514 For ad-hoc networks such as Zeroconf environments, peer-to-peer 1515 multicast protocols are appropriate. The Zeroconf host profile [ZCHP] 1516 requires the use of a DNS-like protocol over IP Multicast for host 1517 name resolution in the absence of DNS servers. Given that Zeroconf 1518 hosts will have to implement this Multicast-based DNS-like protocol 1519 anyway, it makes sense for them to also perform service discovery 1520 using that same Multicast-based DNS-like software, instead of also 1521 having to implement an entirely different service discovery protocol. 1522 1523 In larger networks, a high volume of enterprise-wide IP multicast 1524 traffic may not be desirable, so any credible service discovery 1525 protocol intended for larger networks has to provide some facility to 1526 aggregate registrations and lookups at a central server (or servers) 1527 instead of working exclusively using multicast. This requires some 1528 service discovery aggregation server software to be written, 1529 debugged, deployed, and maintained. This also requires some service 1530 discovery registration protocol to be implemented and deployed for 1531 1532 1533 Expires 7th December 2005 Cheshire & Krochmal [Page 26] 1534 1536 Internet Draft DNS-Based Service Discovery 7th June 2005 1537 1538 1539 clients to register with the central aggregation server. Virtually 1540 every company with an IP network already runs a DNS server, and DNS 1541 already has a dynamic registration protocol [RFC 2136]. Given that 1542 virtually every company already has to operate and maintain a DNS 1543 server anyway, it makes sense to take advantage of this instead of 1544 also having to learn, operate and maintain a different service 1545 registration server. It should be stressed again that using the same 1546 software and protocols doesn't necessarily mean using the same 1547 physical piece of hardware. The DNS-SD service discovery functions 1548 do not have to be provided by the same piece of hardware that 1549 is currently providing the company's DNS name service. The 1550 "_tcp.<Domain>" subdomain may be delegated to a different piece of 1551 hardware. However, even when the DNS-SD service is being provided by 1552 a different piece of hardware, it is still the same familiar DNS 1553 server software that is running, with the same configuration file 1554 syntax, the same log file format, and so forth. 1555 1556 Service discovery needs to be able to provide appropriate security. 1557 DNS already has existing mechanisms for security [RFC 2535]. 1558 1559 In summary: 1560 1561 Service discovery requires a central aggregation server. 1562 DNS already has one: It's called a DNS server. 1563 1564 Service discovery requires a service registration protocol. 1565 DNS already has one: It's called DNS Dynamic Update. 1566 1567 Service discovery requires a query protocol 1568 DNS already has one: It's called DNS. 1569 1570 Service discovery requires security mechanisms. 1571 DNS already has security mechanisms: DNSSEC. 1572 1573 Service discovery requires a multicast mode for ad-hoc networks. 1574 Zeroconf environments already require a multicast-based DNS-like 1575 name lookup protocol for mapping host names to addresses, so it 1576 makes sense to let one multicast-based protocol do both jobs. 1577 1578 It makes more sense to use the existing software that every network 1579 needs already, instead of deploying an entire parallel system just 1580 for service discovery. 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 Expires 7th December 2005 Cheshire & Krochmal [Page 27] 1593 1595 Internet Draft DNS-Based Service Discovery 7th June 2005 1596 1597 1598 16. Real Example 1599 1600 The following examples were prepared using standard unmodified 1601 nslookup and standard unmodified BIND running on GNU/Linux. 1602 1603 Note: In real products, this information is obtained and presented to 1604 the user using graphical network browser software, not command-line 1605 tools, but if you wish you can try these examples for yourself as you 1606 read along, using the command-line tools already available on your 1607 own Unix machine. 1608 1609 16.1 Question: What FTP servers are being advertised from dns-sd.org? 1610 1611 nslookup -q=ptr _ftp._tcp.dns-sd.org. 1612 _ftp._tcp.dns-sd.org 1613 name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org 1614 _ftp._tcp.dns-sd.org 1615 name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org 1616 _ftp._tcp.dns-sd.org 1617 name = Registered\032Users'\032Only._ftp._tcp.dns-sd.org 1618 1619 Answer: There are three, called "Apple QuickTime Files", 1620 "Microsoft Developer Files" and "Registered Users' Only". 1621 1622 Note that nslookup escapes spaces as "\032" for display purposes, 1623 but a graphical DNS-SD browser does not. 1624 1625 16.2 Question: What FTP servers allow anonymous access? 1626 1627 nslookup -q=ptr _anon._sub._ftp._tcp.dns-sd.org 1628 _anon._sub._ftp._tcp.dns-sd.org 1629 name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org 1630 _anon._sub._ftp._tcp.dns-sd.org 1631 name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org 1632 1633 Answer: Only "Apple QuickTime Files" and "Microsoft Developer Files" 1634 allow anonymous access. 1635 1636 16.3 Question: How do I access "Apple QuickTime Files"? 1637 1638 nslookup -q=any "Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org." 1639 Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org 1640 text = "path=/quicktime" 1641 Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org 1642 priority = 0, weight = 0, port= 21 host = ftp.apple.com 1643 ftp.apple.com internet address = 17.254.0.27 1644 ftp.apple.com internet address = 17.254.0.31 1645 ftp.apple.com internet address = 17.254.0.26 1646 1647 Answer: You need to connect to ftp.apple.com, port 21, path 1648 "/quicktime". The addresses for ftp.apple.com are also given. 1649 1650 1651 Expires 7th December 2005 Cheshire & Krochmal [Page 28] 1652 1654 Internet Draft DNS-Based Service Discovery 7th June 2005 1655 1656 1657 17. IPv6 Considerations 1658 1659 IPv6 has no significant differences, except that the address of the 1660 SRV record's target host is given by the appropriate IPv6 address 1661 records instead of the IPv4 "A" record. 1662 1663 1664 18. Security Considerations 1665 1666 DNSSEC [RFC 2535] should be used where the authenticity of 1667 information is important. Since DNS-SD is just a naming and usage 1668 convention for records in the existing DNS system, it has no specific 1669 additional security requirements over and above those that already 1670 apply to DNS queries and DNS updates. 1671 1672 1673 19. IANA Considerations 1674 1675 This protocol builds on DNS SRV records [RFC 2782], and similarly 1676 requires IANA to assign unique application protocol names. 1677 Unfortunately, the "IANA Considerations" section of RFC 2782 says 1678 simply, "The IANA has assigned RR type value 33 to the SRV RR. 1679 No other IANA services are required by this document." 1680 Due to this oversight, IANA is currently prevented from carrying 1681 out the necessary function of assigning these unique identifiers. 1682 1683 This document proposes the following IANA allocation policy for 1684 unique application protocol names: 1685 1686 Allowable names: 1687 * Must be no more than fourteen characters long 1688 * Must consist only of: 1689 - lower-case letters 'a' - 'z' 1690 - digits '0' - '9' 1691 - the hyphen character '-' 1692 * Must begin and end with a lower-case letter or digit. 1693 * Must not already be assigned to some other protocol in the 1694 existing IANA "list of assigned application protocol names 1695 and port numbers" [ports]. 1696 1697 These identifiers are allocated on a First Come First Served basis. 1698 In the event of abuse (e.g. automated mass registrations, etc.), 1699 the policy may be changed without notice to Expert Review [RFC 2434]. 1700 1701 The textual nature of service/protocol names means that there are 1702 almost infinitely many more of them available than the finite set of 1703 65535 possible port numbers. This means that developers can produce 1704 experimental implementations using unregistered service names with 1705 little chance of accidental collision, providing service names are 1706 chosen with appropriate care. However, this document strongly 1707 advocates that on or before the date a product ships, developers 1708 should properly register their service names. 1709 1710 Expires 7th December 2005 Cheshire & Krochmal [Page 29] 1711 1713 Internet Draft DNS-Based Service Discovery 7th June 2005 1714 1715 1716 Some developers have expressed concern that publicly registering 1717 their service names (and port numbers today) with IANA before a 1718 product ships may give away clues about that product to competitors. 1719 For this reason, IANA should consider allowing service name 1720 applications to remain secret for some period of time, much as US 1721 patent applications remain secret for two years after the date of 1722 filing. 1723 1724 This proposed IANA allocation policy is not in force until this 1725 document is published as an RFC. In the meantime, unique application 1726 protocol names may be registered according to the instructions at 1727 <http://www.dns-sd.org/ServiceTypes.html>. As of January 2004, there 1728 are roughly 100 application protocols in currently shipping products 1729 that have been so registered as using DNS-SD for service discovery. 1730 1731 1732 20. Acknowledgments 1733 1734 The concepts described in this document have been explored, developed 1735 and implemented with help from Richard Brown, Erik Guttman, Paul 1736 Vixie, and Bill Woodcock. 1737 1738 Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, 1739 Roger Pantos and Kiren Sekar for their significant contributions. 1740 1741 1742 21. Copyright 1743 1744 Copyright (C) The Internet Society 2005. 1745 All Rights Reserved. 1746 1747 This document and translations of it may be copied and furnished to 1748 others, and derivative works that comment on or otherwise explain it 1749 or assist in its implementation may be prepared, copied, published 1750 and distributed, in whole or in part, without restriction of any 1751 kind, provided that the above copyright notice and this paragraph are 1752 included on all such copies and derivative works. However, this 1753 document itself may not be modified in any way, such as by removing 1754 the copyright notice or references to the Internet Society or other 1755 Internet organizations, except as needed for the purpose of 1756 developing Internet standards in which case the procedures for 1757 copyrights defined in the Internet Standards process must be 1758 followed, or as required to translate it into languages other than 1759 English. 1760 1761 The limited permissions granted above are perpetual and will not be 1762 revoked by the Internet Society or its successors or assigns. 1763 1764 This document and the information contained herein is provided on an 1765 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1766 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1767 1768 1769 Expires 7th December 2005 Cheshire & Krochmal [Page 30] 1770 1772 Internet Draft DNS-Based Service Discovery 7th June 2005 1773 1774 1775 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1776 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1777 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1778 1779 1780 22. Normative References 1781 1782 [ports] IANA list of assigned application protocol names and port 1783 numbers <http://www.iana.org/assignments/port-numbers> 1784 1785 [RFC 1033] Lottor, M., "Domain Administrators Operations Guide", 1786 RFC 1033, November 1987. 1787 1788 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 1789 Facilities", STD 13, RFC 1034, November 1987. 1790 1791 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 1792 Specifications", STD 13, RFC 1035, November 1987. 1793 1794 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1795 Requirement Levels", RFC 2119, March 1997. 1796 1797 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO 1798 10646", RFC 2279, January 1998. 1799 1800 [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the 1801 location of services (DNS SRV)", RFC 2782, February 2000. 1802 1803 1804 23. Informative References 1805 1806 [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS", 1807 Internet-Draft (work in progress), 1808 draft-cheshire-dnsext-multicastdns-05.txt, June 2005. 1809 1810 [NBP] Cheshire, S., and M. Krochmal, 1811 "Requirements for a Protocol to Replace AppleTalk NBP", 1812 Internet-Draft (work in progress), 1813 draft-cheshire-dnsext-nbp-04.txt, June 2005. 1814 1815 [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP 1816 Vendor Extensions", RFC 2132, March 1997. 1817 1818 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 1819 System (DNS UPDATE)", RFC 2136, April 1997. 1820 1821 [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing 1822 an IANA Considerations Section in RFCs", RFC 2434, 1823 October 1998. 1824 1825 1826 1827 1828 Expires 7th December 2005 Cheshire & Krochmal [Page 31] 1829 1831 Internet Draft DNS-Based Service Discovery 7th June 2005 1832 1833 1834 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", 1835 RFC 2535, March 1999. 1836 1837 [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS) 1838 Dynamic Update", RFC 3007, November 2000. 1839 1840 [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration 1841 Protocol (DHCP) Domain Search Option", RFC 3397, November 1842 2002. 1843 1844 [ZC] Williams, A., "Requirements for Automatic Configuration 1845 of IP Hosts", Internet-Draft (work in progress), 1846 draft-ietf-zeroconf-reqts-12.txt, September 2002. 1847 1848 [ZCHP] Guttman, E., "Zeroconf Host Profile Applicability 1849 Statement", Internet-Draft (work in progress), 1850 draft-ietf-zeroconf-host-prof-01.txt, July 2001. 1851 1852 1853 24. Authors' Addresses 1854 1855 Stuart Cheshire 1856 Apple Computer, Inc. 1857 1 Infinite Loop 1858 Cupertino 1859 California 95014 1860 USA 1861 1862 Phone: +1 408 974 3207 1863 EMail: rfc (a] stuartcheshire.org 1864 1865 1866 Marc Krochmal 1867 Apple Computer, Inc. 1868 1 Infinite Loop 1869 Cupertino 1870 California 95014 1871 USA 1872 1873 Phone: +1 408 974 4368 1874 EMail: marc (a] apple.com 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 Expires 7th December 2005 Cheshire & Krochmal [Page 32] 1888
