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