idnits 2.17.1 draft-cheshire-dnsext-dns-sd-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1409 has weird spacing: '...olo.net inte...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (27 February 2011) is 4807 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Unknown state RFC: RFC 1033 -- Obsolete informational reference (is this intentional?): RFC 2910 (Obsoleted by RFC 8010) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Cheshire 3 Internet-Draft M. Krochmal 4 Intended status: Standards Track Apple Inc. 5 Expires: 31 August 2011 27 February 2011 7 DNS-Based Service Discovery 9 11 Abstract 13 This document specifies how DNS resource records are named and 14 structured to facilitate service discovery. Given a type of service 15 that a client is looking for, and a domain in which the client is 16 looking for that service, this allows clients to discover a list of 17 named instances of that desired service, using standard DNS queries. 18 This is referred to as DNS-based Service Discovery, or DNS-SD. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on 31st August 2011. 43 Table of Contents 45 1. Introduction...................................................3 46 2. Conventions and Terminology Used in this Document..............5 47 3. Design Goals...................................................5 48 4. Service Instance Enumeration (Browsing)........................6 49 4.1 Structured Instance Names......................................6 50 4.2 User Interface Presentation....................................9 51 4.3 Internal Handling of Names.....................................9 52 5. Service Name Resolution.......................................10 53 6. Data Syntax for DNS-SD TXT Records............................11 54 6.1 General Format Rules for DNS TXT Records......................12 55 6.2 DNS-SD TXT Record Size........................................13 56 6.3 DNS TXT Record Format Rules for use in DNS-SD.................13 57 6.4 Rules for Names in DNS-SD Name/Value Pairs....................14 58 6.5 Rules for Values in DNS-SD Name/Value Pairs...................17 59 6.6 Example TXT Record............................................17 60 6.7 Version Tag...................................................18 61 6.8 Service Instances with Multiple TXT Records...................19 62 7. Application Protocol Names....................................20 63 7.1 Selective Instance Enumeration (Subtypes).....................22 64 7.2 Service Name Length Limits....................................24 65 8. Flagship Naming...............................................26 66 9. Service Type Enumeration......................................28 67 10. Populating the DNS with Information...........................29 68 11. Discovery of Browsing and Registration Domains................30 69 12. DNS Additional Record Generation..............................32 70 13. Working Examples..............................................34 71 14. IPv6 Considerations...........................................35 72 15. Security Considerations.......................................35 73 16. IANA Considerations...........................................36 74 17. Acknowledgments...............................................37 75 18. Copyright Notice..............................................37 76 19. Normative References..........................................38 77 20. Informative References........................................39 78 Appendix A. Rationale for using DNS as a basis for Service Disc....41 79 Appendix B. Ordering of Service Instance Name Components...........43 80 Appendix C. What You See Is What You Get...........................45 81 Appendix D. Choice of Factory-Default Names........................47 82 Appendix E. Name Encodings in the Domain Name System...............49 83 Appendix F. "Continuous Live Update" Browsing Model................50 84 Appendix G. Deployment History.....................................52 85 Authors' Addresses.................................................54 87 1. Introduction 89 This document specifies how DNS resource records are named and 90 structured to facilitate service discovery. Given a type of service 91 that a client is looking for, and a domain in which the client is 92 looking for that service, this allows clients to discover a list of 93 named instances of that desired service, using standard DNS queries. 94 This is referred to as DNS-based Service Discovery, or DNS-SD. 96 This document proposes no change to the structure of DNS messages, 97 and no new operation codes, response codes, resource record types, 98 or any other new DNS protocol values. 100 This document specifies that a particular service instance can be 101 described using a DNS SRV [RFC 2782] and DNS TXT [RFC 1035] record. 102 The SRV record has a name of the form ".." 103 and gives the target host and port where the service instance can 104 be reached. The DNS TXT record of the same name gives additional 105 information about this instance, in a structured form using 106 key/value pairs, described in Section 6. A client discovers 107 the list of available instances of a given service type using 108 a query for a DNS PTR [RFC 1035] record with a name of the form 109 ".", which returns a set of zero or more names, 110 which are the names of the aforementioned DNS SRV/TXT record pairs. 112 This specification is compatible with both Multicast DNS [mDNS] 113 and with today's existing unicast DNS server and client software. 115 When used with Multicast DNS, DNS-SD can provide zero-configuration 116 operation -- just connect a DNS-SD/mDNS device and its services 117 are advertised on the local link with no further user interaction 118 [Zeroconf]. 120 When used with conventional unicast DNS, some configuration will 121 usually be required -- such as configuring the device with the DNS 122 domain(s) in which it should advertise its services, and configuring 123 it with the DNS Update [RFC 2136] [RFC 3007] keys to give it 124 permission to do so. In rare cases, such as a secure corporate 125 network behind a firewall where no DNS Update keys are required, 126 zero-configuration operation may be achieved by simply having the 127 device register its services in a default registration domain learned 128 from the network (See Section 11 "Discovery of Browsing and 129 Registration Domains") but this is the exception and usually security 130 credentials will be required to perform DNS Updates. 132 Note that when using DNS-SD with unicast DNS, the unicast DNS-SD 133 service does NOT have to be provided by the same DNS server hardware 134 that is currently providing an organization's conventional host name 135 lookup service. When many people use the term "DNS" they are thinking 136 exclusively of mapping host names to IP addresses, but in fact, "the 137 DNS is a general (if somewhat limited) hierarchical database, and can 138 store almost any kind of data, for almost any purpose." [RFC 2181] 139 By delegating the "_tcp" and "_udp" subdomains, all the workload 140 related to DNS-SD can be offloaded to a different machine. This 141 flexibility, to handle DNS-SD on the main DNS server, or not, at the 142 network administrator's discretion, is one of the benefits of using 143 DNS. 145 Even when the DNS-SD functions are delegated to a different machine, 146 the benefits of using DNS remain: It is mature technology, well 147 understood, with multiple independent implementations from different 148 vendors, a wide selection of books published on the subject, and an 149 established workforce experienced in its operation. In contrast, 150 adopting some other service discovery technology would require every 151 site in the world to install, learn, configure, operate and maintain 152 some entirely new and unfamiliar server software. Faced with these 153 obstacles, it seems unlikely that any other service discovery 154 technology could hope to compete with the ubiquitous deployment 155 that DNS already enjoys. For further discussion of the rationale 156 for using DNS as the underlying technology for Service Discovery, 157 see Appendix A. 159 This document is written for two audiences: developers creating 160 application software that offers or accesses services on the network, 161 and developers creating DNS-SD libraries to implement the advertising 162 and discovery mechanisms. For both audiences, understanding the 163 entire document is helpful. For developers creating application 164 software this document provides guidance on choice of instance names, 165 service names, and other aspects that play a role in creating a good 166 overall user experience. However, also understanding the underlying 167 DNS mechanisms used to provide those facilities helps application 168 developers understand the capabilities and limitations of those 169 underlying mechanisms (e.g. name length limits). For library 170 developers writing software to construct the DNS records (to 171 advertise a service) and generate the DNS queries (to discover and 172 use a service), understanding the ultimate user-experience goals 173 helps them provide APIs that can meet those goals. 175 2. Conventions and Terminology Used in this Document 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in "Key words for use in 180 RFCs to Indicate Requirement Levels" [RFC 2119]. 182 3. Design Goals 184 Of the many properties a good service discovery protocol needs to 185 have, three in particular are: 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"). 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). 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. 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. 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 that are broadly applicable 214 to any potential service discovery protocol. 216 4. Service Instance Enumeration (Browsing) 218 Traditional DNS SRV records [RFC 2782] are useful for locating 219 instances of a particular type of service when all the instances are 220 effectively indistinguishable and provide the same service to the 221 client. 223 For example, SRV records with the (hypothetical) name 224 "_http._tcp.example.com." would allow a client to discover servers 225 implementing the "_http._tcp" service (i.e. web servers) for the 226 "example.com." domain. The unstated assumption is that all these 227 servers offer an identical set of web pages, and it doesn't matter to 228 the client which of the servers it uses, as long as it selects one at 229 random according to the weight and priority rules laid out in the DNS 230 SRV specification [RFC 2782]. 232 Instances of other kinds of service are less easily interchangeable. 233 If a word processing application were to look up the (hypothetical) 234 SRV record "_ipp._tcp.example.com." to find the list of IPP [RFC 235 2910] printers at Example Co., then picking one at random and 236 printing on it would probably not be what the user wanted. 238 The remainder of this section describes how SRV records may be used 239 in a slightly different way to allow a user to discover the names of 240 all available instances of a given type of service, to allow the user 241 to select the particular instance they desire. 243 4.1 Structured Instance Names 245 This document borrows the logical service naming syntax and semantics 246 from DNS SRV records, but adds one level of indirection. Instead of 247 requesting records of type "SRV" with name "_ipp._tcp.example.com.", 248 the client requests records of type "PTR" (pointer from one name to 249 another in the DNS namespace). 251 In effect, if one thinks of the domain name "_ipp._tcp.example.com." 252 as being analogous to an absolute path to a directory in a file 253 system, then DNS-SD's PTR lookup is akin to performing a listing of 254 that directory to find all the files it contains. (Remember that 255 domain names are expressed in reverse order compared to path names 256 -- an absolute path name starts with the root on the left and is read 257 from left to right, whereas a fully-qualified domain name starts with 258 the root on the right and is read from right to left. If the fully- 259 qualified domain name "_ipp._tcp.example.com." were expressed as a 260 file system path name, it would be "/com/example/_tcp/_ipp".) 261 The result of this PTR lookup for the name "." is a 262 set of zero or more PTR records giving Service Instance Names of the 263 form: 265 Service Instance Name = . . 267 For explanation of why the components are in this order, see Appendix 268 B. 270 4.1.1 Instance Names 272 The portion of the Service Instance Name is a user- 273 friendly name consisting of arbitrary Net-Unicode text [RFC 5198]. 274 It MUST NOT contain ASCII control characters (byte values 0x00-0x1F 275 and 0x7F) [RFC 20] but otherwise is allowed to contain any 276 characters, without restriction, including spaces, upper case, lower 277 case, punctuation -- including dots -- accented characters, non-roman 278 text, and anything else that may be represented using Net-Unicode. 279 For discussion of why the name should be a user-visible 280 user-friendly name rather than an invisible machine-generated opaque 281 identifier, see Appendix C. 283 The portion of the name of a service being offered on the 284 network SHOULD be configurable by the user setting up the service, so 285 that he or she may give it an informative name. However, the device 286 or service SHOULD NOT require the user to configure a name before it 287 can be used. A sensible choice of default name can allow the device 288 or service to be accessed in many cases without any manual 289 configuration at all. The default name should be short and 290 descriptive, and SHOULD NOT include the device's MAC address, serial 291 number, or any similar incomprehensible hexadecimal string in an 292 attempt to make the name globally unique. For discussion of why 293 names don't need to be (and SHOULD NOT be) made unique 294 at the factory, see Appendix D. 296 This portion of the Service Instance Name is stored 297 directly in the DNS as a single DNS label of canonical precomposed 298 UTF-8 [RFC 3629] "Net-Unicode" (Unicode Normalization Form C) [RFC 299 5198] text. For further discussion of text encodings see Appendix E. 301 DNS labels are currently limited to 63 octets in length. UTF-8 302 encoding can require up to four octets per Unicode character, which 303 means that in the worst case, the portion of a name could 304 be limited to fifteen Unicode characters. However, the Unicode 305 characters with longer octet length under UTF-8 encoding tend to be 306 the more rarely-used ones, and tend to be the ones that convey 307 greater meaning per character. 309 Note that any character in the commonly-used 16-bit Unicode Basic 310 Multilingual Plane [Unicode6] can be encoded with no more than three 311 octets of UTF-8 encoding. This means that an Instance name can 312 contain up to 21 Kanji characters, which is a sufficiently expressive 313 name for most purposes. 315 4.1.2 Service Names 317 The portion of the Service Instance Name consists of a 318 pair of DNS labels, following the convention already established for 319 SRV records [RFC 2782], namely: the first label of the pair is an 320 underscore character followed by the Application Protocol Name 321 [iana], and the second label is either "_tcp" (for application 322 protocols that run over TCP) or "_udp" (for all others). More details 323 are given in Section 7, "Application Protocol Names". 325 4.1.3 Domain Names 327 The portion of the Service Instance Name specifies the DNS 328 subdomain within which the service names are registered. It may be 329 "local.", meaning "link-local Multicast DNS" [mDNS], or it may be 330 a conventional unicast DNS domain name, such as "ietf.org.", 331 "cs.stanford.edu.", or "eng.us.ibm.com." Because service names are 332 not host names, they are not constrained by the usual rules for host 333 names [RFC 1033][RFC 1034][RFC 1035], and rich-text service 334 subdomains are allowed and encouraged, for example: 336 Building 2, 1st Floor . example . com . 337 Building 2, 2nd Floor . example . com . 338 Building 2, 3rd Floor . example . com . 339 Building 2, 4th Floor . example . com . 341 In addition, because Service Instance Names are not constrained by 342 the limitations of host names, this document recommends that they 343 be stored in the DNS, and communicated over the wire, encoded 344 as straightforward canonical precomposed UTF-8 [RFC 3629] 345 "Net-Unicode" (Unicode Normalization Form C) [RFC 5198] text. 346 In cases where the DNS server returns a negative response for the 347 name in question, client software MAY choose to retry the query using 348 the "Punycode" algorithm [RFC 3492] to convert the UTF-8 name to an 349 IDNA "A-label" [RFC 5890], beginning with the top-level label, and 350 then issuing the query repeatedly, with successively more labels 351 translated to IDNA A-labels each time, and giving up if it has 352 converted all labels to IDNA A-labels and the query still fails. 354 4.2 User Interface Presentation 356 The names resulting from the PTR lookup are presented to the user in 357 a list for the user to select one (or more). Typically only the first 358 label is shown (the user-friendly portion of the name). 360 In the common case, the and are already known to 361 the client software, these having been provided implicitly by the 362 user in the first place, by the act of indicating the service being 363 sought, and the domain in which to look for it. Note: The software 364 handling the response should be careful not to make invalid 365 assumptions though, since it *is* possible, though rare, for a 366 service enumeration in one domain to return the names of services in 367 a different domain. Similarly, when using subtypes (see "Selective 368 Instance Enumeration") the of the discovered instance may 369 not be exactly the same as the that was requested. 371 For further discussion of Service Instance Enumeration (Browsing) 372 user-interface considerations, particularly, the "continuous live 373 update" user-experience model, see Appendix F. 375 Once the user has selected the desired named instance, the Service 376 Instance Name may then be used immediately, or saved away in some 377 persistent user-preference data structure for future use, depending 378 on what is appropriate for the application in question. 380 4.3 Internal Handling of Names 382 If client software takes the , and 383 portions of a Service Instance Name and internally concatenates them 384 together into a single string, then because the portion is 385 allowed to contain any characters, including dots, appropriate 386 precautions MUST be taken to ensure that DNS label boundaries are 387 properly preserved. Client software can do this in a variety of ways, 388 such as character escaping. 390 This document RECOMMENDS that if concatenating the three portions of 391 a Service Instance Name, any dots in the portion should 392 be escaped following the customary DNS convention for text files: 393 by preceding literal dots with a backslash (so "." becomes "\."). 394 Likewise, any backslashes in the portion should also be 395 escaped by preceding them with a backslash (so "\" becomes "\\"). 396 Having done this, the three components of the name may be safely 397 concatenated. The backslash-escaping allows literal dots in the name 398 (escaped) to be distinguished from label-separator dots (not 399 escaped), and the resulting concatenated string may be safely passed 400 to standard DNS APIs like res_query(), which will interpret the 401 backslash-escaped string as intended. 403 5. Service Name Resolution 405 When a client needs to contact a particular service, identified by 406 a Service Instance Name, previously discovered via Service Instance 407 Enumeration (browsing), it queries for the SRV and TXT records of 408 that name. The SRV record for a service gives the port number and 409 target host name where the service may be found. The TXT record gives 410 additional information about the service, as described in Section 6 411 below, "Data Syntax for DNS-SD TXT Records". 413 SRV records are extremely useful because they remove the need for 414 preassigned port numbers. There are only 65535 TCP port numbers 415 available. These port numbers are being allocated one-per- 416 application-protocol. Some protocols like the X Window System have 417 a block of 64 TCP ports allocated (6000-6063). Using a different TCP 418 port for each different instance of a given service on a given 419 machine is entirely sensible, but allocating each application its own 420 large static range is not a practical way to do that. On any given 421 host, most TCP ports are reserved for services that will never run on 422 that particular host in its lifetime. This is very poor utilization 423 of the limited port space. Using SRV records allows each host to 424 allocate its available port numbers dynamically to those services 425 actually running on that host that need them, and then advertise the 426 allocated port numbers via SRV records. Allocating the available 427 listening port numbers locally on a per-host basis as needed allows 428 much better utilization of the available port space than today's 429 centralized global allocation. 431 In the event that more than one SRV is returned, clients MUST 432 correctly interpret the priority and weight fields -- i.e. lower 433 numbered priority servers should be used in preference to higher 434 numbered priority servers, and servers with equal priority should be 435 selected randomly in proportion to their relative weights. However, 436 in the overwhelmingly common case, a single advertised DNS-SD service 437 instance is described by exactly one SRV record, and in this common 438 case the priority and weight fields of the SRV record SHOULD both be 439 set to zero. 441 6. Data Syntax for DNS-SD TXT Records 443 Some services discovered via Service Instance Enumeration may need 444 more than just an IP address and port number to completely identify 445 the service instance. For example, printing via the old Unix LPR 446 (port 515) protocol [RFC 1179] often specifies a queue name [BJP]. 447 This queue name is typically short and cryptic, and need not be shown 448 to the user. It should be regarded the same way as the IP address and 449 port number -- it is another component of the addressing information 450 required to identify a specific instance of a service being offered 451 by some piece of hardware. Similarly, a file server may have multiple 452 volumes, each identified by its own volume name. A web server 453 typically has multiple pages, each identified by its own URL. In 454 these cases, the necessary additional data is stored in a TXT record 455 with the same name as the SRV record. The specific nature of that 456 additional data, and how it is to be used, is service-dependent, but 457 the overall syntax of the data in the TXT record is standardized, as 458 described below. 460 Every DNS-SD service MUST have a TXT record in addition to its SRV 461 record, with the same name, even if the service has no additional 462 data to store and the TXT record contains no more than a single zero 463 byte. This allows a service to have explicit control over the TTL of 464 its (empty) TXT record, rather than using the default negative 465 caching TTL which would otherwise be used for a "no error no answer" 466 DNS response. 468 Note that this requirement for a mandatory TXT record applies 469 exclusively to DNS-SD service advertising, i.e. services advertised 470 using the PTR+SRV+TXT convention specified in this document. 471 It is not a requirement of SRV records in general. The DNS SRV record 472 datatype [RFC 2782] may still be used in other contexts without any 473 requirement for accompanying PTR and TXT records. 475 6.1 General Format Rules for DNS TXT Records 477 A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total 478 length is indicated by the length given in the resource record header 479 in the DNS message. There is no way to tell directly from the data 480 alone how long it is (e.g. there is no length count at the start, or 481 terminating NULL byte at the end). 483 Note that when using Multicast DNS [mDNS] the maximum packet size is 484 9000 bytes, including IP header, UDP header, and DNS message header, 485 which imposes an upper limit on the size of TXT records of about 8900 486 bytes. In practice the maximum sensible size of a DNS-SD TXT record 487 size is smaller even than this, typically at most a few hundred 488 bytes, as described below in Section 6.2. 490 The format of the data within a DNS TXT record is one or more 491 strings, packed together in memory without any intervening gaps 492 or padding bytes for word alignment. 494 The format of each constituent string within the DNS TXT record is 495 a single length byte, followed by 0-255 bytes of text data. 497 These format rules are defined in Section 3.3.14 of the DNS 498 specification [RFC 1035], and are not specific to DNS-SD. DNS-SD 499 specifies additional rules for what data should be stored in those 500 constituent strings when used for DNS-SD service advertising, i.e. 501 when used to describe services advertised using the PTR+SRV+TXT 502 convention specified in this document. 504 An empty TXT record containing zero strings is disallowed by RFC 505 1035. DNS-SD implementations MUST NOT emit empty TXT records. 506 DNS-SD clients MUST treat the following as equivalent: 508 o A TXT record containing a single zero byte. 509 (i.e. a single empty string.) 511 o An empty (zero-length) TXT record 512 (This is not strictly legal, but should one be received it should 513 be interpreted as the same as a single empty string.) 515 o No TXT record. 516 (i.e. an NXDOMAIN or no-error-no-answer response.) 518 6.2 DNS-SD TXT Record Size 520 The total size of a typical DNS-SD TXT record is intended to be small 521 -- 200 bytes or less. 523 In cases where more data is justified (e.g. LPR printing [BJP]), 524 keeping the total size under 400 bytes should allow it to fit in a 525 single 512-byte DNS message [RFC 1035]. 527 In extreme cases where even this is not enough, keeping the size of 528 the TXT record under 1300 bytes should allow it to fit in a single 529 1500-byte Ethernet packet. 531 Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this 532 time. 534 Note that some Ethernet hardware vendors offer chipsets with 535 Multicast DNS [mDNS] offload, so that computers can sleep and still 536 be discoverable on the network. Early versions of such chipsets were 537 sometimes quite limited, and, for example, some were (unwisely) 538 limited to handling TXT records no larger than 256 bytes (which meant 539 that LPR printer services with larger TXT records did not work). 540 Developers should be aware of this real-world limitation, and should 541 understand that even on hardware which is otherwise perfectly 542 capable, it may have low-power and sleep modes that are more limited. 544 6.3 DNS TXT Record Format Rules for use in DNS-SD 546 DNS-SD uses DNS TXT records to store arbitrary key/value pairs 547 conveying additional information about the named service. Each 548 key/value pair is encoded as its own constituent string within the 549 DNS TXT record, in the form "key=value" (without the quotation 550 marks). Everything up to the first '=' character is the key (Section 551 6.4). Everything after the first '=' character to the end of the 552 string (including subsequent '=' characters, if any) is the value. 553 No quotation marks are required around the value, even if it contains 554 spaces, '=' characters, or other punctuation marks (see Section 6.5). 555 Each author defining a DNS-SD profile for discovering instances of a 556 particular type of service should define the base set of key/value 557 attributes that are valid for that type of service. 559 Using this standardized key/value syntax within the TXT record makes 560 it easier for these base definitions to be expanded later by defining 561 additional named attributes. If an implementation sees unknown 562 keys in a service TXT record, it MUST silently ignore them. 564 The target host name and TCP (or UDP) port number of the service are 565 given in the SRV record. This information -- target host name and 566 port number -- MUST NOT be duplicated using key/value attributes 567 in the TXT record. 569 The intention of DNS-SD TXT records is to convey a small amount of 570 useful additional information about a service. Ideally it should not 571 be necessary for a client to retrieve this additional information 572 before it can usefully establish a connection to the service. For a 573 well-designed application protocol, even if there is no information 574 at all in the TXT record, it should be possible, knowing only the 575 host name, port number, and protocol being used, to communicate with 576 that listening process, and then perform version- or feature- 577 negotiation to determine any further options or capabilities of the 578 service instance. For example, when connecting to an Apple Filing 579 Protocol (AFP) [AFP] server over TCP, the client enters into a 580 protocol exchange with the server to determine which version of AFP 581 the server implements, and which optional features or capabilities 582 (if any) are available. 584 For protocols designed with adequate in-band version- and feature- 585 negotiation, any information in the TXT record should be viewed as a 586 performance optimization -- when a client discovers many instances of 587 a service, the TXT record allows the client to know some rudimentary 588 information about each instance without having to open a TCP 589 connection to each one and interrogate every service instance 590 separately. Care should be taken when doing this to ensure that the 591 information in the TXT record is in agreement with the information 592 that would be retrieved by a client connecting over TCP. 594 There are legacy protocols which provide no feature negotiation 595 capability, and in these cases it may be useful to convey necessary 596 information in the TXT record. For example, when printing using LPR 597 [RFC 1179], the LPR protocol provides no way for the client to 598 determine whether a particular printer accepts PostScript, or what 599 version of PostScript, etc. In this case it is appropriate to embed 600 this information in the TXT record [BJP], because the alternative 601 would be worse -- passing around written instructions to the users, 602 arcane manual configuration of "/etc/printcap" files, etc. 604 6.4 Rules for Keys in DNS-SD Key/Value Pairs 606 The "Key" MUST be at least one character. Strings beginning with an 607 '=' character (i.e. the key is missing) MUST be silently ignored. 609 The "Key" SHOULD be no more than nine characters long. This is 610 because it is beneficial to keep packet sizes small for the sake of 611 network efficiency. When using DNS-SD in conjunction with Multicast 612 DNS [mDNS] this is important because on 802.11 wireless networks 613 multicast traffic is especially expensive [IEEE W], but even when 614 using conventional Unicast DNS, keeping the TXT records small helps 615 improve the chance that responses will fit within the original DNS 616 512-byte size limit [RFC 1035]. Also, each constituent string of a 617 DNS TXT record is limited to 255 bytes, so excessively long keys 618 reduce the space available for that key's values. 620 The Keys in Key/Value Pairs can be as short as a single character. 621 A key name needs only to be unique and unambiguous within the context 622 of the service type for which it is defined. A key name is intended 623 solely to be a machine-readable identifier, not a human-readable 624 essay giving detailed discussion of the purpose of a parameter, with 625 a URL for a web page giving yet more details of the specification. 626 For ease of development and debugging it can be valuable to use key 627 names that are mnemonic textual names, but excessively verbose keys 628 are wasteful and inefficient, hence the recommendation to keep them 629 to nine characters or fewer. 631 The characters of "Key" MUST be printable US-ASCII values 632 (0x20-0x7E) [RFC 20], excluding '=' (0x3D). 634 Spaces in the key are significant, whether leading, trailing, or in 635 the middle -- so don't include any spaces unless you really intend 636 that. 638 Case is ignored when interpreting a key, so "papersize=A4", 639 "PAPERSIZE=A4" and "Papersize=A4" are all identical. 641 If there is no '=', then it is a boolean attribute, and is simply 642 identified as being present, with no value. 644 A given key may appear at most once in a TXT record. The reason for 645 this simplifying rule is to facilitate the creation of client 646 libraries that parse the TXT record into an internal data structure, 647 such as a hash table or dictionary object that maps from keys to 648 values, and then make that abstraction available to client code. The 649 rule that a given key may not appear more than once simplifies these 650 abstractions because they aren't required to support the case of 651 returning more than one value for a given key. 653 If a client receives a TXT record containing the same key more than 654 once, then the client MUST silently ignore all but the first 655 occurrence of that attribute. For client implementations that process 656 a DNS-SD TXT record from start to end, placing key/value pairs into a 657 hash table, using the key as the hash table key, this means that if 658 the implementation attempts to add a new key/value pair into the 659 table and finds an entry with the same key already present, then the 660 new entry being added should be silently discarded instead. For 661 client implementations that retrieve key/value pairs by searching the 662 TXT record for the requested key, they should search the TXT record 663 from the start, and simply return the first matching key they find. 665 When examining a TXT record for a given key, there are therefore four 666 categories of results which may be returned: 668 * Attribute not present (Absent) 670 * Attribute present, with no value 671 (e.g. "passreq" -- password required for this service) 673 * Attribute present, with empty value (e.g. "PlugIns=" -- 674 server supports plugins, but none are presently installed) 676 * Attribute present, with non-empty value 677 (e.g. "PlugIns=JPEG,MPEG2,MPEG4") 679 Each author defining a DNS-SD profile for discovering instances of a 680 particular type of service should define the interpretation of these 681 different kinds of result. For example, for some keys, there may be 682 a natural true/false boolean interpretation: 684 * Absent implies 'false' 685 * Present implies 'true' 687 For other keys it may be sensible to define other semantics, such as 688 value/no-value/unknown: 690 * Present with value implies that value. 691 E.g. "Color=4" for a four-color ink-jet printer, 692 or "Color=6" for a six-color ink-jet printer. 694 * Present with empty value implies 'false'. E.g. Not a color printer. 696 * Absent implies 'Unknown'. E.g. A print server connected to some 697 unknown printer where the print server doesn't actually know if the 698 printer does color or not (which gives a very bad user experience 699 and should be avoided wherever possible). 701 Note that this is a hypothetical example, not an example of actual 702 key/value keys used by DNS-SD network printers, which are documented 703 in the "Bonjour Printing Specification" [BJP]. 705 6.5 Rules for Values in DNS-SD Key/Value Pairs 707 If there is an '=', then everything after the first '=' to the end of 708 the string is the value. The value can contain any eight-bit values 709 including '='. The value MUST NOT be enclosed in quotation marks or 710 any similar punctuation, and any quotation marks, or leading or 711 trailing spaces, are part of the value. 713 The value is opaque binary data. Often the value for a particular 714 attribute will be US-ASCII [RFC 20] (or UTF-8 [RFC 3629]) text, but 715 it is legal for a value to be any binary data. 717 Generic debugging tools should generally display all attribute values 718 as a hex dump, with accompanying text alongside displaying the UTF-8 719 interpretation of those bytes, except for attributes where the 720 debugging tool has embedded knowledge that the value is some other 721 kind of data. 723 Authors defining DNS-SD profiles SHOULD NOT generically convert 724 binary attribute data types into printable text using hexadecimal 725 representation, Base-64 [RFC 4648] or UU encoding, merely for the 726 sake of making the data be printable text when seen in a generic 727 debugging tool. Doing this simply bloats the size of the TXT record, 728 without actually making the data any more understandable to someone 729 looking at it in a generic debugging tool. 731 6.6 Example TXT Record 733 The TXT record below contains three syntactically valid key/value 734 pairs. (The meaning of these key/value pairs, if any, would depend 735 on the definitions pertaining to the service in question that is 736 using them.) 738 ------------------------------------------------------- 739 | 0x09 | key=value | 0x08 | paper=A4 | 0x07 | passreq | 740 ------------------------------------------------------- 742 6.7 Version Tag 744 It is recommended that authors defining DNS-SD profiles include an 745 attribute of the form "txtvers=x" in their definition, and require 746 it to be the first key/value pair in the TXT record. This 747 information in the TXT record can be useful to help clients maintain 748 backwards compatibility with older implementations if it becomes 749 necessary to change or update the specification over time. Even if 750 the profile author doesn't anticipate the need for any future 751 incompatible changes, having a version number in the TXT record 752 provides useful insurance should incompatible changes become 753 unavoidable. Clients SHOULD ignore TXT records with a txtvers number 754 higher (or lower) than the version(s) they know how to interpret. 756 Note that the version number in the txtvers tag describes the version 757 of the specification governing the defined keys and the meaning of 758 those keys for that particular TXT record, not the version of the 759 application protocol that will be used if the client subsequently 760 decides to contact that service. Ideally, every DNS-SD TXT record 761 specification starts at txtvers=1 and stays that way forever. 762 Improvements can be made by defining new keys that older clients 763 silently ignore. The only reason to increment the version number is 764 if the old specification is subsequently found to be so horribly 765 broken that there's no way to do a compatible forward revision, so 766 the txtvers number has to be incremented to tell all the old clients 767 they should just not even try to understand this new TXT record. 769 If there is a need to indicate which version number(s) of the 770 application protocol the service implements, the recommended key 771 for this is "protovers". 773 6.8 Service Instances with Multiple TXT Records 775 Generally speaking every DNS-SD service instance has exactly one TXT 776 record. However it is possible for a particular protocol's DNS-SD 777 advertising specification to state that it allows multiple TXT 778 records. In this case, each TXT record describes a different variant 779 of the same logical service, offered using the same underlying 780 protocol on the same port, described by the same SRV record. 782 Having multiple TXT records to describe a single service instance is 783 very rare, and to date, of the many hundreds of registered DNS-SD 784 service types [services], only one makes use of this capability, 785 namely LPR printing [BJP]. This capability is used when a printer 786 conceptually supports multiple logical queue names, where each 787 different logical queue name implements a different page description 788 language, such as 80-column monospaced plain text, seven-bit Adobe 789 PostScript, eight-bit ("binary") PostScript, or some proprietary page 790 description language. When multiple TXT records are used to describe 791 multiple logical LPR queue names for the same underlying service, 792 printers include two additional keys in each TXT record, 'qtotal', 793 which specifies the total number of TXT records associated with this 794 SRV record, and 'priority', which gives the printer's relative 795 preference for this particular TXT record. Clients then select the 796 most preferred TXT record which meets the client's needs [BJP]. The 797 only reason multiple TXT records are used is because the LPR protocol 798 lacks in-band feature-negotiation capabilities for the client and 799 server to agree on a data representation for the print job, so this 800 information has to be communicated out-of-band instead using the 801 DNS-SD TXT records. Future protocol designs should not emulate this 802 inadequacy of the LPR printing protocol. 804 7. Application Protocol Names 806 The portion of a Service Instance Name consists of a pair 807 of DNS labels, following the convention already established for 808 SRV records [RFC 2782], namely: the first label of the pair is an 809 underscore character followed by the Application Protocol Name 810 [iana], and the second label is either "_tcp" or "_udp". 812 For applications using other transport protocols, such as SCTP 813 [RFC 4960], DCCP [RFC 4340], Adobe's RTMFP, etc., the second label 814 of the portion of its DNS-SD name should be "_udp". (In 815 retrospect perhaps the SRV specification should not have used the 816 "_tcp" and "_udp" labels at all, and instead should have used a 817 single label "_srv" to carve off subdomains of DNS namespace for this 818 use, but that specification is already published and deployed. Thus 819 it makes sense to use "_tcp" for TCP-based services and "_udp" for 820 all other transport protocols -- which are in fact, in today's world, 821 often encapsulated over UDP -- rather than defining new a subdomain 822 for every new transport protocol. At this point there is no benefit 823 in changing established practice. While "_srv" might be aesthetically 824 nicer than "_udp", it is not a user-visible string, and all that is 825 required protocol-wise is that it be a label which can form a DNS 826 delegation point, and that it be short so that it does not take up 827 too much space in the packet, and in this respect either string is 828 equally good.) Note that this usage of the "_udp" label for all 829 protocols other than TCP applies exclusively to DNS-SD service 830 advertising, i.e. services advertised using the PTR+SRV+TXT 831 convention specified in this document. It is not a requirement of 832 SRV records in general. Other specifications that are independent of 833 DNS-SD and not intended to interoperate with DNS-SD records are not 834 in any way constrained by how DNS-SD works just because they also use 835 the DNS SRV record datatype [RFC 2782], and they are free to specify 836 their own naming conventions as appropriate. 838 As defined the rules for service names [iana], Application Protocol 839 Names may be no more than fifteen characters (not counting the 840 mandatory underscore), consisting of only letters, digits, and 841 hyphens, must begin and end with a letter or digit, and must contain 842 at least one letter. The requirement to contain at least one letter 843 is to disallow service names such as "80" or "6000-6063" which could 844 be misinterpreted as port numbers or port number ranges. While both 845 upper case and lower case letters may be used for mnemonic clarity, 846 case is ignored for comparison purposes, so the strings "HTTP" and 847 "http" refer to the same service. 849 Wise selection of an Application Protocol Name is important, and the 850 choice is not always as obvious as it may appear. 852 In many cases, the Application Protocol Name merely names and refers 853 to the on-the-wire message format and semantics being used. FTP is 854 "ftp", IPP printing is "ipp", and so on. 856 However, it is common to "borrow" an existing protocol and repurpose 857 it for a new task. This is entirely sensible and sound engineering 858 practice, but that doesn't mean that the new protocol is providing 859 the same semantic service as the old one, even if it borrows the same 860 message formats. For example, the network music sharing protocol 861 implemented by iTunes on Macintosh and Windows is built upon 862 "HTTP GET" commands. However, that does *not* mean that it is 863 sensible or useful to try to access one of these music servers by 864 connecting to it with a standard web browser. Consequently, the 865 DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp" 866 (Digital Audio Access Protocol), not "_http._tcp". Advertising 867 "_http._tcp" service would cause iTunes servers to show up in 868 conventional web browsers (Safari, Camino, OmniWeb, Internet 869 Explorer, Firefox, Chrome, etc.) which is of little use since it 870 offers no pages containing human-readable content. Equally, if 871 iTunes were to browse for "_http._tcp" service, that would cause it 872 to find generic web servers, such as the embedded web servers in 873 devices like printers, which is of little use since printers 874 generally don't have much music to offer. 876 Analogously, NFS is built on top of SUN RPC, but that doesn't mean it 877 makes sense for an NFS server to advertise that it provides "SUN RPC" 878 service. Likewise, Microsoft SMB file service is built on top of 879 Netbios running over IP, but that doesn't mean it makes sense for 880 an SMB file server to advertise that it provides "Netbios-over-IP" 881 service. The DNS-SD name of a service needs to encapsulate both the 882 "what" (semantics) and the "how" (protocol implementation) of the 883 service, since knowledge of both is necessary for a client to 884 usefully use the service. Merely advertising that a service was 885 built on top of SUN RPC is no use if the client has no idea what 886 the service actually does. 888 Another common question is whether the service type advertised 889 by iTunes should be "_daap._http._tcp." This would also be incorrect. 890 Similarly, a protocol designer implementing a network service that 891 happens to use Simple Object Access Protocol [SOAP] should not feel 892 compelled to have "_soap" appear somewhere in the Application 893 Protocol Name. Part of the confusion here is that the presence of 894 "_tcp" or "_udp" in the portion of a Service Instance Name 895 has led people to assume that the visible structure of a service name 896 has to reflect the private internal structure of how the protocol was 897 implemented. This is not correct. All that is required is that the 898 service be identified by some unique opaque Application Protocol 899 Name. Making the Application Protocol Name be English text which 900 is at least marginally descriptive of what the service does may be 901 convenient, but it is by no means essential. 903 7.1. Selective Instance Enumeration (Subtypes) 905 This document does not attempt to define a sophisticated (e.g. Turing 906 Complete, or even regular expression) query language for service 907 discovery, nor do we believe one is necessary. 909 However, there are some limited circumstances where narrowing the 910 set of results may be useful. For example, many network printers 911 offer a web-based user interface, for management and administration, 912 using HTML/HTTP. A web browser wanting to discover all advertised web 913 pages on the local network issues a query for "_http._tcp.". 914 On the other hand, there are cases where users wish to manage 915 printers specifically, not to discover web pages in general, and it 916 would be good accommodate this. In this case we define the "_printer" 917 subtype of "_http._tcp", and the web browser issues a query for 918 "_printer._sub._http._tcp.", to discover only the subset 919 of pages advertised as having that subtype property. 921 The Safari web browser on Mac OS X 10.5 "Leopard" uses subtypes 922 in this way. If an "_http._tcp" service is discovered both via 923 "_printer._sub._http._tcp" browsing and via "_http._tcp" browsing 924 then it is displayed in the "Printers" section of Safari's UI. 925 If a service is discovered only via "_http._tcp" browsing then it is 926 displayed in the "Webpages" section of Safari's UI. This can be seen 927 by using the commands below on Mac OS X to advertise two "fake" 928 services. The service instance "A web page" is displayed in the 929 "Webpages" section of Safari's Bonjour list, while the instance 930 "A printer's web page" is displayed in the "Printers" section. 932 dns-sd -R "A web page" _http._tcp local 100 933 dns-sd -R "A printer's web page" _http._tcp,_printer local 101 935 Note that the advertised web page's Service Instance Name is 936 unchanged by the use of subtypes -- it is still something of the form 937 "The Server._http._tcp.example.com.", and the advertised web page is 938 still discoverable using a standard browsing query for services of 939 type "_http._tcp". The subdomain in which HTTP server SRV records are 940 registered defines the namespace within which HTTP server names are 941 unique. Additional subtypes (e.g. "_printer") of the basic service 942 type (e.g. "_http._tcp") serve to allow certain clients to query for 943 a narrower set of results, not to create more namespace. 945 Using DNS zone file syntax, the service instance "A web page" is 946 advertised using one PTR record, while the instance "A printer's web 947 page" is advertised using two: the primary service type and the 948 additional subtype. Even though the "A printer's web page" service is 949 advertised two different ways, both PTR records refer to the name of 950 the same SRV+TXT record pair: 952 ; One PTR record advertises "A web page" 953 _http._tcp.local. PTR A\032web\032page._http._tcp.local. 955 ; Two different PTR records advertise "A printer's web page" 956 _http._tcp.local. PTR A\032printer's\032web\032page._http._tcp.local. 957 _printer._sub._http._tcp.local. 958 PTR A\032printer's\032web\032page._http._tcp.local. 960 Subtypes are appropriate when it is desirable for different kinds of 961 clients to be able to browse for services at two levels of 962 granularity. In the example above, we describe two classes of HTTP 963 clients: general web browsing clients that are interested in all web 964 pages, and specific printer management tools that would like to 965 discover only web UI pages advertised by printers. The set of HTTP 966 servers on the network is the same in both cases; the difference is 967 that some clients want to discover all of them, whereas other clients 968 only want to find the subset of HTTP servers whose purpose is printer 969 administration. 971 Subtypes are only appropriate in two-level scenarios such as this 972 one, where some clients want to find the full set of services of a 973 given type, and at the same time other clients only want to find some 974 subset. Generally speaking, if there is no client that wants to find 975 the entire set, then it's neither necessary nor desirable to use the 976 subtype mechanism. If all clients are browsing for some particular 977 subtype, and no client exists that browses for the parent type, then 978 a new Application Protocol Name representing the logical service 979 should be defined, and software should simply advertise and browse 980 for that particular service type directly. In particular, just 981 because a particular network service happens to be implemented in 982 terms of some other underlying protocol, like HTTP, Sun RPC, or SOAP, 983 doesn't mean that it's sensible for that service to be defined as a 984 subtype of "_http", "_sunrpc", or "_soap". That would only be useful 985 if there were some class of client for which it is sensible to say, 986 "I want to discover a service on the network, and I don't care what 987 it does, as long as it does it using the SOAP XML RPC mechanism." 989 As with the TXT record key/value pairs, the list of possible 990 subtypes, if any, are defined and specified separately for each 991 basic service type. 993 Subtype strings (e.g. "_printer" in the example above) may be 994 constructed using arbitrary 8-bit data values. These data values may 995 in many cases be UTF-8 [RFC 3629] representations of text, or even 996 (as in the example above) plain ASCII [RFC 20], but they do not have 997 to be. Note however that even when using arbitrary 8-bit data for 998 subtype strings, DNS name comparisons are still case-insensitive, so 999 (for example) the byte values 0x41 and 0x61 will be considered 1000 equivalent for subtype comparison purposes. 1002 7.2 Service Name Length Limits 1004 As specified above, application protocol names are allowed to be no 1005 more than fifteen characters long. The reason for this limit is to 1006 leave as many bytes of the domain name as possible available for use 1007 by both the network administrator (choosing service domain names) and 1008 the end user (choosing instance names). 1010 A domain name may be up to 255 bytes long, plus one byte for the 1011 final terminating root label at the end. Domain names used by DNS-SD 1012 take the following forms: 1014 ._tcp . . . 1015 . ._tcp . . . 1016 ._sub . ._tcp . . . 1018 The first example shows the name used for PTR queries. The second 1019 shows a service instance name, i.e. the name of the service's SRV and 1020 TXT records. The third shows a subtype browsing name, i.e. the name 1021 of a PTR record pointing to a service instance name (see Section 7.1 1022 "Selective Instance Enumeration"). 1024 The instance name may be up to 63 bytes. Including the 1025 length byte used by the DNS format when the name is stored in a 1026 packet, that makes 64 bytes. 1028 When using subtypes, the subtype identifier is allowed to be up to 1029 63 bytes, plus the length byte, making 64. Including the "_sub" 1030 and its length byte, this makes 69 bytes. 1032 The application protocol name may be up to 15 bytes, plus 1033 the underscore and length byte, making a total of 17. Including 1034 the "_udp" or "_tcp" and its length byte, this makes 22 bytes. 1036 Typically, DNS-SD service records are placed into subdomains of their 1037 own beneath a company's existing domain name. Since these subdomains 1038 are intended to be accessed through graphical user interfaces, not 1039 typed on a command-line, they are frequently long and descriptive. 1040 Including the length byte, the user-visible service domain may be up 1041 to 64 bytes. 1043 Of our available 255 bytes, we have now accounted for 69+22+64 = 1044 155 bytes. This leaves 100 bytes to accommodate the organization's 1045 existing domain name . When used with Multicast DNS, 1046 is "local.", which easily fits. When used with parent 1047 domains of 100 bytes or less, the full functionality of DNS-SD is 1048 available without restriction. When used with parent domains longer 1049 than 100 bytes, the protocol risks exceeding the maximum possible 1050 length of domain names, causing failures. In this case, careful 1051 choice of short names can help avoid overflows. 1052 If the and are too long, then service 1053 instances with long instance names will not be discoverable or 1054 resolvable, and applications making use of long subtype names 1055 may fail. 1057 Because of this constraint, we choose to limit Application Protocol 1058 Names to 15 characters or less. Allowing more characters would not 1059 increase the expressive power of the protocol, and would needlessly 1060 reduce the maximum length that may be safely used. 1062 Note that name lengths affect the maximum number of 1063 services of a given type that can be discovered in a given 1064 . The largest unicast DNS response than can be sent 1065 (typically using TCP, not UDP) is 64kB. Using DNS name compression, 1066 a Service Instance Enumeration PTR record requires 2 bytes for the 1067 (compressed) name, plus 10 bytes for type, class, ttl and rdata 1068 length. The rdata of the PTR record requires up to 64 bytes for the 1069 part of the name, plus 2 bytes for a name compression 1070 pointer to the common suffix, making a maximum of 78 bytes total. 1071 This means that using maximum-sized names, up to 839 1072 instances of a given service type can be discovered in a given 1073 . 1075 Multicast DNS aggregates response packets, so it does not have the 1076 same hard limit, but in practice it is also useful for up to a few 1077 hundred instances of a given service type, but probably not 1078 thousands. 1080 However, displaying even 100 instances in a flat list is probably too 1081 many to be helpful to a typical user. If a network has more than 1082 100 instances of a given service type, it's probably appropriate to 1083 divide those services into logical subdomains by building, by floor, 1084 by department, etc. 1086 8. Flagship Naming 1088 In some cases, there may be several network protocols available which 1089 all perform roughly the same logical function. For example, the 1090 printing world has the LPR protocol [RFC 1179], and the Internet 1091 Printing Protocol (IPP) [RFC 2910], both of which cause printed 1092 sheets to be emitted from printers in much the same way. In addition, 1093 many printer vendors send their own proprietary page description 1094 language (PDL) data over a TCP connection to TCP port 9100, herein 1095 referred to generically as the "pdl-datastream" protocol. In an ideal 1096 world we would have only one network printing protocol, and it would 1097 be sufficiently good that no one felt a compelling need to invent a 1098 different one. However, in practice, multiple legacy protocols do 1099 exist, and a service discovery protocol has to accommodate that. 1101 Many printers implement all three printing protocols: LPR, IPP, and 1102 pdl-datastream. For the benefit of clients that may speak only one of 1103 those protocols, all three are advertised. 1105 However, some clients may implement two, or all three of those 1106 printing protocols. When a client looks for all three service types 1107 on the network, it will find three distinct services -- an LPR 1108 service, an IPP service, and a pdl-datastream service -- all of which 1109 cause printed sheets to be emitted from the same physical printer. 1111 In the case of multiple protocols like this that all perform 1112 effectively the same function, the client should suppress duplicate 1113 names and display each name only once. When the user prints to a 1114 given named printer, the printing client is responsible for choosing 1115 the protocol which will best achieve the desired effect, without, for 1116 example, requiring the user to make a manual choice between LPR and 1117 IPP. 1119 As described so far, this all works very well. However, consider some 1120 future printer that only supports IPP printing, and some other future 1121 printer that only supports pdl-datastream printing. The name spaces 1122 for different service types are intentionally disjoint (it is 1123 acceptable and desirable to be able to have both a file server 1124 called "Sales Department" and a printer called "Sales Department"). 1125 However, it is not desirable, in the common case, to allow two 1126 different printers both called "Sales Department", just because 1127 those printers implement different protocols. 1129 To help guard against this, when there are two or more network 1130 protocols which perform roughly the same logical function, one of 1131 the protocols is declared the "flagship" of the fleet of related 1132 protocols. Typically the flagship protocol is the oldest and/or 1133 best-known protocol of the set. 1135 If a device does not implement the flagship protocol, then it instead 1136 creates a placeholder SRV record (priority=0, weight=0, port=0, 1137 target host = host name of device) with that name. If, when it 1138 attempts to create this SRV record, it finds that a record with the 1139 same name already exists, then it knows that this name is already 1140 taken by some other entity implementing at least one of the protocols 1141 from the fleet, and it must choose another. If no SRV record already 1142 exists, then the act of creating it stakes a claim to that name so 1143 that future devices in the same protocol fleet will detect a conflict 1144 when they try to use it. 1146 Note: When used with Multicast DNS [mDNS], the target host field of 1147 the placeholder SRV record MUST NOT be the empty root label. The SRV 1148 record needs to contain a real target host name in order for the 1149 Multicast DNS conflict detection rules to operate. If two different 1150 devices were to create placeholder SRV records both using a null 1151 target host name (just the root label), then the two SRV records 1152 would be seen to be in agreement so no conflict would be detected. 1154 By defining a common well-known flagship protocol for the class, 1155 future devices that may not even know about each other's protocols 1156 establish a common ground where they can coordinate to verify 1157 uniqueness of names. 1159 No PTR record is created advertising the presence of empty flagship 1160 SRV records, since they do not represent a real service being 1161 advertised, and hence are not (and should not be) discoverable via 1162 Service Instance Enumeration (browsing). 1164 9. Service Type Enumeration 1166 In general, normal clients are not interested in finding *every* 1167 service on the network, just the services that the client knows how 1168 to use. 1170 However, for problem diagnosis and network management tools, it may 1171 be useful for network administrators to find the list of advertised 1172 service types on the network, even if those service names are just 1173 opaque identifiers and not particularly informative in isolation. 1175 For this reason, a special meta-query is defined. A DNS query 1176 for PTR records with the name "_services._dns-sd._udp." 1177 yields a set of PTR records, where the rdata of each PTR record 1178 is the two-label name, plus the same domain, 1179 e.g. "_http._tcp.". Including the domain in the PTR rdata 1180 allows for better name compression in DNS packets, but only the first 1181 two labels are relevant for the purposes of service type enumeration. 1182 These two-label service types can then be used to construct 1183 subsequent Service Instance Enumeration PTR queries, in this 1184 or others, to discover instances of that service type. 1186 10. Populating the DNS with Information 1188 How a service's PTR, SRV and TXT records make their way into the DNS 1189 is outside the scope of this document, but for illustrative purposes 1190 some examples are given here: 1192 On some networks, the administrator might manually enter the records 1193 into the name server's configuration file. 1195 A network monitoring tool could output a standard zone file to be 1196 read into a conventional DNS server. For example, a tool that can 1197 find networked PostScript laser printers using AppleTalk NBP, could 1198 find the list of printers, communicate with each one to find its IP 1199 address, PostScript version, installed options, etc., and then write 1200 out a DNS zone file describing those printers and their capabilities 1201 using DNS resource records. That information would then be available 1202 to DNS-SD clients that don't implement AppleTalk NBP. 1204 A printer manager device which has knowledge of printers on the 1205 network through some other management protocol could also use Dynamic 1206 DNS Update [RFC 2136] [RFC 3007]. 1208 Alternatively, a printer manager device could implement enough of 1209 the DNS protocol that it is able to answer DNS queries directly, 1210 and Example Co.'s main DNS server could delegate the 1211 _ipp._tcp.example.com subdomain to the printer manager device. 1213 IP printers could use Dynamic DNS Update [RFC 2136] [RFC 3007] to 1214 automatically register their own PTR, SRV and TXT records with the 1215 DNS server. 1217 Zeroconf printers answer Multicast DNS queries on the local link 1218 for appropriate PTR, SRV and TXT names ending with ".local." [mDNS] 1220 11. Discovery of Browsing and Registration Domains (Domain Enumeration) 1222 One of the motivations for DNS-based Service Discovery is to enable 1223 a visiting client (e.g. a Wi-Fi-equipped laptop computer, tablet, or 1224 telephone) arriving on a new network to discover what services are 1225 available on that network, without any manual configuration. 1226 This logic (discovering services without manual configuration) 1227 also applies to discovering the domains in which services may be 1228 discovered, also without manual configuration. 1230 This discovery is performed using DNS queries, using Unicast or 1231 Multicast DNS. Five special RR names are reserved for this purpose: 1233 b._dns-sd._udp.. 1234 db._dns-sd._udp.. 1235 r._dns-sd._udp.. 1236 dr._dns-sd._udp.. 1237 lb._dns-sd._udp.. 1239 By performing PTR queries for these names, a client can learn, 1240 respectively: 1242 o A list of domains recommended for browsing 1244 o A single recommended default domain for browsing 1246 o A list of domains recommended for registering services using 1247 Dynamic Update 1249 o A single recommended default domain for registering services. 1251 o The final query shown yields the "legacy browsing" or "automatic 1252 browsing" domain. Sophisticated client applications that care to 1253 present choices of domain to the user, use the answers learned 1254 from the previous four queries to discover the domains to present. 1255 In contrast, many current applications browse without specifying 1256 an explicit domain, allowing the operating system to automatically 1257 select an appropriate domain on their behalf. It is for this class 1258 of application that the "automatic browsing" query is provided, to 1259 allow the network administrator to communicate to the client 1260 operating systems which domain(s) should be used automatically for 1261 these applications. 1263 These domains are purely advisory. The client or user is free to 1264 browse and/or register services in any domains. The purpose of these 1265 special queries is to allow software to create a user-interface that 1266 displays a useful list of suggested choices to the user, from which 1267 the user may make an informed selection, or ignore the offered 1268 suggestions and manually enter their own choice. 1270 The part of the Domain Enumeration query name may be 1271 "local." (meaning "perform the query using link-local multicast) or 1272 it may be learned through some other mechanism, such as the DHCP 1273 "Domain" option (option code 15) [RFC 2132], the DHCP "Domain Search" 1274 option (option code 119) [RFC 3397], or IPv6 Router Advertisement 1275 Options [RFC 6106]. 1277 The part of the query name may also be derived a different 1278 way, from the host's IP address. The host takes its IP address, and 1279 calculates the logical AND of that address and its subnet mask, to 1280 derive the 'base' address of the subnet (the 'network address' of 1281 that subnet, or equivalently the IP address of the 'all-zero' host 1282 address on that subnet). It then constructs the conventional DNS 1283 "reverse mapping" name corresponding to that base address, and uses 1284 that as the part of the name for the queries described 1285 above. For example, if a host has address 192.168.12.34, with 1286 subnet mask 255.255.0.0, then the 'base' address of the subnet is 1287 192.168.0.0, and to discover the recommended automatic browsing 1288 domain for devices on this subnet, the host issues a DNS PTR query 1289 for the name "lb._dns-sd._udp.0.0.168.192.in-addr.arpa." 1291 Equivalent address-derived Domain Enumeration queries should also be 1292 done for the host's IPv6 address(es). 1294 Address-derived Domain Enumeration queries SHOULD NOT be done for 1295 IPv4 link-local addresses [RFC 3927] or IPv6 link-local addresses 1296 [RFC 4862]. 1298 Sophisticated clients may perform domain enumeration queries both 1299 in "local." and in one or more unicast domains, using both 1300 name-derived and address-derived queries, and then present the 1301 user with an aggregate result, combining the information received 1302 from all sources. 1304 12. DNS Additional Record Generation 1306 DNS has an efficiency feature whereby a DNS server may place 1307 additional records in the Additional Section of the DNS Message. 1308 These additional records are records that the client did not 1309 explicitly request, but the server has reasonable grounds to 1310 expect that the client might request them shortly, so including 1311 them can save the client from having to issue additional queries. 1313 This section recommends which additional records SHOULD be generated 1314 to improve network efficiency, for both unicast and multicast DNS-SD 1315 responses. 1317 Note that while servers SHOULD add these additional records for 1318 efficiency purposes, as with all DNS additional records it is 1319 the client's responsibility to determine whether it trusts them. 1321 Generally speaking, stub resolvers that talk to a single recursive 1322 name server for all their queries will trust all records they receive 1323 from that recursive name server (whom else would they ask?) Recursive 1324 name servers that talk to multiple authoritative name servers should 1325 verify that any records they receive from a given authoritative name 1326 server are "in bailiwick" for that server, and ignore them if not. 1328 Clients MUST be capable of functioning correctly with DNS Servers 1329 (and Multicast DNS Responders) that fail to generate these additional 1330 records automatically, by issuing subsequent queries for any further 1331 record(s) they require. The additional-record generation rules in 1332 this section are RECOMMENDED for improving network efficiency, but 1333 are not required for correctness. 1335 12.1 PTR Records 1337 When including a DNS-SD Service Instance Enumeration or Selective 1338 Instance Enumeration (subtype) PTR record in a response packet, the 1339 server/responder SHOULD include the following additional records: 1341 o The SRV record(s) named in the PTR rdata. 1342 o The TXT record(s) named in the PTR rdata. 1343 o All address records (type "A" and "AAAA") named in the SRV rdata. 1345 12.2 SRV Records 1347 When including an SRV record in a response packet, the 1348 server/responder SHOULD include the following additional records: 1350 o All address records (type "A" and "AAAA") named in the SRV rdata. 1352 12.3 TXT Records 1354 When including a TXT record in a response packet, no additional 1355 records are required. 1357 12.4 Other Record Types 1359 In response to address queries, or other record types, no additional 1360 records are recommended by this document. 1362 13. Working Examples 1364 The following examples were prepared using standard unmodified 1365 nslookup and standard unmodified BIND running on GNU/Linux. 1367 Note: In real products, this information is obtained and presented to 1368 the user using graphical network browser software, not command-line 1369 tools, but if you wish you can try these examples for yourself as you 1370 read along, using the nslookup command already available on most Unix 1371 machines. 1373 13.1 Question: What web pages are being advertised from dns-sd.org? 1375 nslookup -q=ptr _http._tcp.dns-sd.org. 1376 _http._tcp.dns-sd.org 1377 name = Zeroconf._http._tcp.dns-sd.org 1378 _http._tcp.dns-sd.org 1379 name = Multicast\032DNS._http._tcp.dns-sd.org 1380 _http._tcp.dns-sd.org 1381 name = DNS\032Service\032Discovery._http._tcp.dns-sd.org 1382 _http._tcp.dns-sd.org 1383 name = Stuart's\032Printer._http._tcp.dns-sd.org 1385 Answer: There are four, called "Zeroconf", "Multicast DNS", 1386 "DNS Service Discovery" and "Stuart's Printer". 1388 Note that nslookup escapes spaces as "\032" for display purposes, 1389 but a graphical DNS-SD browser should not. 1391 13.2 Question: What printer-configuration web pages are there? 1393 nslookup -q=ptr _printer._sub._http._tcp.dns-sd.org 1394 _printer._sub._http._tcp.dns-sd.org 1395 name = Stuart's\032Printer._http._tcp.dns-sd.org 1397 Answer: "Stuart's Printer" is the web configuration UI of a network 1398 printer. 1400 13.3 Question: How do I access the "DNS Service Discovery" web page? 1402 nslookup -q=any "DNS\032Service\032Discovery._http._tcp.dns-sd.org." 1403 DNS\032Service\032Discovery._http._tcp.dns-sd.org 1404 priority = 0, weight = 0, port = 80, host = dns-sd.org 1405 DNS\032Service\032Discovery._http._tcp.dns-sd.org 1406 text = "txtvers=1" "path=/" 1407 dns-sd.org nameserver = ns1.bolo.net 1408 dns-sd.org internet address = 64.142.82.154 1409 ns1.bolo.net internet address = 64.142.82.152 1411 Answer: You need to connect to dns-sd.org port 80, path "/". 1412 The address for dns-sd.org is also given (64.142.82.154). 1414 14. IPv6 Considerations 1416 IPv6 has only minor differences. 1418 The address of the SRV record's target host is given by the 1419 appropriate IPv6 "AAAA" address records instead of (or in addition 1420 to) IPv4 "A" records. 1422 Address-based Domain Enumeration queries are performed using names 1423 under the IPv6 reverse-mapping tree, which is different to the IPv4 1424 reverse-mapping tree and has longer names in it. 1426 15. Security Considerations 1428 Since DNS-SD is just a specification for how to name and use records 1429 in the existing DNS system, it has no specific additional security 1430 requirements over and above those that already apply to DNS queries 1431 and DNS updates. 1433 For DNS queries, DNSSEC [RFC 4033] should be used where the 1434 authenticity of information is important. 1436 For DNS updates, secure updates [RFC 2136] [RFC 3007] should 1437 generally be used to control which clients have permission to update 1438 DNS records. 1440 16. IANA Considerations 1442 Until draft-ietf-tsvwg-iana-ports [iana] is approved for publication 1443 unique application protocol names may be registered according to the 1444 instructions at . As of 1445 December 2010, about 500 application protocols have been registered. 1446 These will be migrated to the IANA registry once draft-ietf-tsvwg- 1447 iana-ports is published and the IANA registry is operational. 1449 When a protocol service advertising specification includes subtypes, 1450 these should be documented in the protocol specification in question 1451 and/or in the "notes" field of the IANA-recorded registration. 1452 In the event that a new subtype becomes relevant after a protocol 1453 specification has been published, this can be recorded by requesting 1454 IANA to add it to the "notes" field. For example, vendors of network 1455 printers advertise their embedded web servers using the subtype 1456 _printer. This allows printer management clients to browse for only 1457 printer-related web servers by browsing for the _printer subtype. 1458 While the existence of the _printer subtype of _http._tcp is not 1459 directly relevant to the HTTP protocol specification, it is useful 1460 to record this usage in the IANA registry to help avoid another 1461 community of developers inadvertently using the same subtype string 1462 for a different purpose. The namespace of possible subtypes is 1463 separate for each different service type. For example, the existence 1464 of the _printer subtype of _http._tcp does not imply that the 1465 _printer subtype is defined or has any meaning for any other service 1466 type. 1468 When IANA records an application protocol name registration, if the 1469 new application protocol is one that conceptually duplicates existing 1470 functionality of an older protocol, and the implementers desire the 1471 Flagship Naming behavior described in Section 8, then the registrant 1472 should request IANA to note the name of the flagship protocol in the 1473 "notes" field of the new registration. For example, the registrations 1474 for "ipp" and "pdl-datastream" both reference "printer" as the 1475 flagship name for this family of printing-related protocols. 1477 17. Acknowledgments 1479 The concepts described in this document have been explored, developed 1480 and implemented with help from Ran Atkinson, Richard Brown, Freek 1481 Dijkstra, Ralph Droms, Erik Guttman, Pasi Sarolahti, Pekka Savola, 1482 Mark Townsley, Paul Vixie, Bill Woodcock, and others. Special thanks 1483 go to Bob Bradley, Josh Graessley, Scott Herscher, Rory McGuire, 1484 Roger Pantos and Kiren Sekar for their significant contributions. 1486 18. Copyright Notice 1488 Copyright (c) 2011 IETF Trust and the persons identified as the 1489 document authors. All rights reserved. 1491 This document is subject to BCP 78 and the IETF Trust's Legal 1492 Provisions Relating to IETF Documents 1493 (http://trustee.ietf.org/license-info) in effect on the date of 1494 publication of this document. Please review these documents 1495 carefully, as they describe your rights and restrictions with respect 1496 to this document. 1498 19. Normative References 1500 [iana] M. Cotton, et al., "Internet Assigned Numbers Authority 1501 (IANA) Procedures for the Management of the Service Name 1502 and Transport Protocol Port Number Registry", 1503 draft-ietf-tsvwg-iana-ports-09.txt, December 2010. 1505 [RFC 20] Cerf, V., "ASCII format for network interchange", RFC 20, 1506 October 1969. 1508 [RFC 1033] Lottor, M., "Domain Administrators Operations Guide", 1509 RFC 1033, November 1987. 1511 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 1512 Facilities", STD 13, RFC 1034, November 1987. 1514 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 1515 Specifications", STD 13, RFC 1035, November 1987. 1517 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1518 Requirement Levels", RFC 2119, March 1997. 1520 [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the 1521 location of services (DNS SRV)", RFC 2782, February 2000. 1523 [RFC 3492] Costello, A., "Punycode: A Bootstring encoding of 1524 Unicode for use with Internationalized Domain Names in 1525 Applications (IDNA)", RFC 3492, March 2003. 1527 [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO 1528 10646", RFC 3629, November 2003. 1530 [RFC 3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1531 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1532 May 2005. 1534 [RFC 4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1535 Address Autoconfiguration", RFC 4862, September 2007. 1537 [RFC 5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 1538 Interchange", RFC 5198, March 2008. 1540 [RFC 5890] Klensin, J., "Internationalized Domain Names for 1541 Applications (IDNA): Definitions and Document Framework", 1542 RFC 5890, August 2010. 1544 20. Informative References 1546 [AFP] Apple Filing Protocol 1549 [B4W] Bonjour for Windows 1551 [BJP] Bonjour Printing Specification 1554 [IEEE W] 1556 [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS", 1557 Internet-Draft (work in progress), 1558 draft-cheshire-dnsext-multicastdns-14.txt, February 2011. 1560 [NBP] Cheshire, S., and M. Krochmal, 1561 "Requirements for a Protocol to Replace AppleTalk NBP", 1562 Internet-Draft (work in progress), 1563 draft-cheshire-dnsext-nbp-10.txt, January 2011. 1565 [ports] IANA list of assigned application protocol names and port 1566 numbers 1568 [services] List of registered DNS-SD service types 1569 1571 [RFC 1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, 1572 August 1990. 1574 [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP 1575 Vendor Extensions", RFC 2132, March 1997. 1577 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 1578 System (DNS UPDATE)", RFC 2136, April 1997. 1580 [RFC 2181] Elz, R., and Bush, R., "Clarifications to the DNS 1581 Specification", RFC 2181, July 1997. 1583 [Unicode6] The Unicode Consortium, "The Unicode Standard, Version 1584 6.0.0", October 2010. 1586 [RFC 2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J. 1587 Wenn, "Internet Printing Protocol/1.1: Encoding and 1588 Transport", RFC 2910, September 2000. 1590 [RFC 4960] Stewart, R., "Stream Control Transmission Protocol", 1591 RFC 4960, September 2007. 1593 [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS) 1594 Dynamic Update", RFC 3007, November 2000. 1596 [RFC 4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1597 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1599 [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration 1600 Protocol (DHCP) Domain Search Option", RFC 3397, November 1601 2002. 1603 [RFC 4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1604 Rose, "DNS Security Introduction and Requirements", 1605 RFC 4033, March 2005. 1607 [RFC 4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1608 Encodings", RFC 4648, October 2006 1610 [RFC 4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1611 Multicast Name Resolution (LLMNR)", RFC 4795, 1612 January 2007. 1614 [RFC 6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1615 "IPv6 Router Advertisement Options for DNS Configuration", 1616 RFC 6106, November 2010. 1618 [SOAP] Nilo Mitra, "SOAP Version 1.2 Part 0: Primer", 1619 W3C Proposed Recommendation, 24 June 2003 1620 http://www.w3.org/TR/2003/REC-soap12-part0-20030624 1622 [Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration 1623 Networking: The Definitive Guide", O'Reilly Media, Inc. , 1624 ISBN 0-596-10100-7, December 2005. 1626 Appendix A. Rationale for using DNS as a basis for Service Discovery 1628 Over the years there have been many proposed ways to do network 1629 service discovery with IP, but none achieved ubiquity in the 1630 marketplace. Certainly none has achieved anything close to the 1631 ubiquity of today's deployment of DNS servers, clients, and other 1632 infrastructure. 1634 The advantage of using DNS as the basis for service discovery is 1635 that it makes use of those existing servers, clients, protocols, 1636 infrastructure, and expertise. Existing network analyzer tools 1637 already know how to decode and display DNS packets for network 1638 debugging. 1640 For ad hoc networks such as Zeroconf environments, peer-to-peer 1641 multicast protocols are appropriate. Using DNS-SD running over 1642 Multicast DNS [mDNS] provides zero-configuration ad hoc service 1643 discovery, while maintaining the DNS-SD semantics and record types 1644 described here. 1646 In larger networks, a high volume of enterprise-wide IP multicast 1647 traffic may not be desirable, so any credible service discovery 1648 protocol intended for larger networks has to provide some facility to 1649 aggregate registrations and lookups at a central server (or servers) 1650 instead of working exclusively using multicast. This requires some 1651 service discovery aggregation server software to be written, 1652 debugged, deployed, and maintained. This also requires some service 1653 discovery registration protocol to be implemented and deployed for 1654 clients to register with the central aggregation server. Virtually 1655 every company with an IP network already runs a DNS server, and DNS 1656 already has a dynamic registration protocol [RFC 2136] [RFC 3007]. 1657 Given that virtually every company already has to operate and 1658 maintain a DNS server anyway, it makes sense to take advantage of 1659 this expertise instead of also having to learn, operate and maintain 1660 a different service registration server. It should be stressed again 1661 that using the same software and protocols doesn't necessarily mean 1662 using the same physical piece of hardware. The DNS-SD service 1663 discovery functions do not have to be provided by the same piece of 1664 hardware that is currently providing the company's DNS name service. 1665 The "_tcp." and "_udp." subdomains may be delegated 1666 to a different piece of hardware. However, even when the DNS-SD 1667 service is being provided by a different piece of hardware, it is 1668 still the same familiar DNS server software, with the same 1669 configuration file syntax, the same log file format, and so forth. 1671 Service discovery needs to be able to provide appropriate security. 1672 DNS already has existing mechanisms for security [RFC 4033]. 1674 In summary: 1676 Service discovery requires a central aggregation server. 1677 DNS already has one: It's called a DNS server. 1679 Service discovery requires a service registration protocol. 1680 DNS already has one: It's called DNS Dynamic Update. 1682 Service discovery requires a query protocol. 1683 DNS already has one: It's called DNS. 1685 Service discovery requires security mechanisms. 1686 DNS already has security mechanisms: DNSSEC. 1688 Service discovery requires a multicast mode for ad hoc networks. 1689 Using DNS-SD in conjunction with Multicast DNS provides this, 1690 using peer-to-peer multicast instead of a DNS server. 1692 It makes more sense to use the existing software that every network 1693 needs already, instead of deploying an entire parallel system just 1694 for service discovery. 1696 Appendix B. Ordering of Service Instance Name Components 1698 There have been questions about why services are named using DNS 1699 Service Instance Names of the form: 1701 Service Instance Name = . . 1703 instead of: 1705 Service Instance Name = . . 1707 There are three reasons why it is beneficial to name service 1708 instances with the parent domain as the most-significant (rightmost) 1709 part of the name, then the abstract service type as the next-most 1710 significant, and then the specific instance name as the 1711 least-significant (leftmost) part of the name: 1713 B.1. Semantic Structure 1715 The facility being provided by browsing ("Service Instance 1716 Enumeration") is effectively enumerating the leaves of a tree 1717 structure. A given domain offers zero or more services. For each 1718 of those service types, there may be zero or more instances of 1719 that service. 1721 The user knows what type of service they are seeking. (If they are 1722 running an FTP client, they are looking for FTP servers. If they have 1723 a document to print, they are looking for entities that speak some 1724 known printing protocol.) The user knows in which organizational or 1725 geographical domain they wish to search. (The user does not want a 1726 single flat list of every single printer on the planet, even if such 1727 a thing were possible.) What the user does not know in advance is 1728 whether the service they seek is offered in the given domain, or if 1729 so, how many instances are offered, and the names of those instances. 1731 Hence having the instance names be the leaves of the tree is 1732 consistent with this semantic model. 1734 Having the service types be the terminal leaves of the tree would 1735 imply that the user knows the domain name, and already knows the 1736 name of the service instance, but doesn't have any idea what the 1737 service does. We would argue that this is a less useful model. 1739 B.2. Network Efficiency 1741 When a DNS response contains multiple answers, name compression works 1742 more effectively if all the names contain a common suffix. If many 1743 answers in the packet have the same and , then each 1744 occurrence of a Service Instance Name can be expressed using only 1745 the part followed by a two-byte compression pointer 1746 referencing a previous appearance of ".". This 1747 efficiency would not be possible if the component appeared 1748 first in each name. 1750 B.3. Operational Flexibility 1752 This name structure allows subdomains to be delegated along logical 1753 service boundaries. For example, the network administrator at Example 1754 Co. could choose to delegate the "_tcp.example.com." subdomain to a 1755 different machine, so that the machine handling service discovery 1756 doesn't have to be the machine that handles other day-to-day 1757 DNS operations. (It *can* be the same machine if the administrator 1758 so chooses, but the administrator is free to make that choice.) 1759 Furthermore, if the network administrator wishes to delegate all 1760 information related to IPP printers to a machine dedicated to 1761 that specific task, this is easily done by delegating the 1762 "_ipp._tcp.example.com." subdomain to the desired machine. It is 1763 also convenient to set security policies on a per-zone/per-subdomain 1764 basis. For example, the administrator may choose to enable DNS 1765 Dynamic Update [RFC 2136] [RFC 3007] for printers registering 1766 in the "_ipp._tcp.example.com." subdomain, but not for other 1767 zones/subdomains. This easy flexibility would not exist if the 1768 component appeared first in each name. 1770 Appendix C. What You See Is What You Get 1772 Some service discovery protocols decouple the true service identifier 1773 from the name presented to the user. The true service identifier used 1774 by the protocol is an opaque unique identifier, often represented 1775 using a long string of hexadecimal digits, which should never be seen 1776 by the typical user. The name presented to the user is merely one of 1777 the decorative ephemeral attributes attached to this opaque 1778 identifier. 1780 The problem with this approach is that it decouples user perception 1781 from reality: 1783 * What happens if there are two service instances, with different 1784 unique ids, but they have inadvertently been given the same 1785 user-visible name? If two instances appear in an on-screen list 1786 with the same name, how does the user know which is which? 1788 * Suppose a printer breaks down, and the user replaces it with 1789 another printer of the same make and model, and configures the 1790 new printer with the exact same name as the one being replaced: 1791 "Stuart's Printer". Now, when the user tries to print, the 1792 on-screen print dialog tells them that their selected default 1793 printer is "Stuart's Printer". When they browse the network to see 1794 what is there, they see a printer called "Stuart's Printer", yet 1795 when the user tries to print, they are told that the printer 1796 "Stuart's Printer" can't be found. The hidden internal unique 1797 identifier that the software is trying to find on the network 1798 doesn't match the hidden internal unique identifier of the new 1799 printer, even though its apparent "name" and its logical purpose 1800 for being there are the same. To remedy this, the user typically 1801 has to delete the print queue they have created, and then create a 1802 new (apparently identical) queue for the new printer, so that the 1803 new queue will contain the right hidden internal unique identifier. 1804 Having all this hidden information that the user can't see makes 1805 for a confusing and frustrating user experience, and exposing long 1806 ugly hexadecimal strings to the user and forcing them to understand 1807 what they mean is even worse. 1809 * Suppose an existing printer is moved to a new department, and given 1810 a new name and a new function. Changing the user-visible name of 1811 that piece of hardware doesn't change its hidden internal unique 1812 identifier. Users who had previously created print queues for that 1813 printer will still be accessing the same hardware by its unique 1814 identifier, even though the logical service that used to be offered 1815 by that hardware has ceased to exist. 1817 Solving these problems requires the user or administrator to be 1818 aware of the supposedly hidden unique identifier, and to set its 1819 value correctly as hardware is moved around, repurposed, or replaced, 1820 thereby contradicting the notion that it is a hidden identifier that 1821 human users never need to deal with. Requiring the user to understand 1822 this expert behind-the-scenes knowledge of what is *really* going on 1823 is just one more burden placed on the user when they are trying to 1824 diagnose why their computers and network devices are not working as 1825 expected. 1827 These anomalies and counter-intuitive behaviors can be eliminated by 1828 maintaining a tight bidirectional one-to-one mapping between what 1829 the user sees on the screen and what is really happening "behind 1830 the curtain". If something is configured incorrectly, then that is 1831 apparent in the familiar day-to-day user interface that everyone 1832 understands, not in some little-known rarely-used "expert" interface. 1834 In summary: In DNS-SD the user-visible name is also the primary 1835 identifier for a service. If the user-visible name is changed, then 1836 conceptually the service being offered is a different logical service 1837 -- even though the hardware offering the service stayed the same. If 1838 the user-visible name doesn't change, then conceptually the service 1839 being offered is the same logical service -- even if the hardware 1840 offering the service is new hardware brought in to replace some old 1841 equipment. 1843 There are certainly arguments on both sides of this debate. 1844 Nonetheless, the designers of any service discovery protocol have 1845 to make a choice between having the primary identifiers be hidden, or 1846 having them be visible, and these are the reasons that we chose to 1847 make them visible. We're not claiming that there are no disadvantages 1848 of having primary identifiers be visible. We considered both 1849 alternatives, and we believe that the few disadvantages of visible 1850 identifiers are far outweighed by the many problems caused by use of 1851 hidden identifiers. 1853 Appendix D. Choice of Factory-Default Names 1855 When a DNS-SD service is advertised using Multicast DNS [mDNS], 1856 automatic name conflict and resolution will occur if there is already 1857 another service of the same type advertising with the same name. 1858 As described in the Multicast DNS specification [mDNS], upon a 1859 conflict, the service should: 1861 1. Automatically select a new name (typically by appending 1862 or incrementing a digit at the end of the name), 1863 2. Try advertising with the new name, and 1864 3. Upon success, record the new name in persistent storage. 1866 This renaming behavior is very important, because it is the key 1867 to providing user-friendly service names in the out-of-the-box 1868 factory-default configuration. Some product developers have 1869 not realized this, because there are some products today where 1870 the factory-default name is distinctly unfriendly, containing 1871 random-looking strings of characters, like the device's Ethernet 1872 address in hexadecimal. This is unnecessary, and undesirable, because 1873 the point of the user-visible name is that it should be friendly and 1874 meaningful to human users. If the name is not unique on the local 1875 network then the protocol will remedy this as necessary. It is 1876 ironic that many of the devices with this design mistake are network 1877 printers, given that these same printers also simultaneously support 1878 AppleTalk-over-Ethernet, with nice user-friendly default names (and 1879 automatic conflict detection and renaming). Some examples of good 1880 factory-default names are: 1882 Brother 5070N 1883 Canon W2200 1884 HP LaserJet 4600 1885 Lexmark W840 1886 Okidata C5300 1887 Ricoh Aficio CL7100 1888 Xerox Phaser 6200DX 1890 To make the case for why adding long ugly factory-unique serial 1891 numbers to the end of names is neither necessary nor desirable, 1892 consider the cases where the user has (a) only one network printer, 1893 (b) two network printers, and (c) many network printers. 1895 (a) In the case where the user has only one network printer, a simple 1896 name like (to use a vendor-neutral example) "Printer" is more 1897 user-friendly than an ugly name like "Printer 0001E68C74FB". 1898 Appending ugly hexadecimal goop to the end of the name to make 1899 sure the name is unique is irrelevant to a user who only has one 1900 printer anyway. 1902 (b) In the case where the user gets a second network printer, 1903 having it detect that the name "Printer" is already in use 1904 and automatically instead name itself "Printer (2)" provides a 1905 good user experience. For most users, remembering that the old 1906 printer is "Printer" and the new one is "Printer (2)" is easy 1907 and intuitive. Seeing two printers called "Printer 0001E68C74FB" 1908 and "Printer 00306EC3FD1C" is a lot less helpful. 1910 (c) In the case of a network with ten network printers, seeing a 1911 list of ten names all of the form "Printer xxxxxxxxxxxx" has 1912 effectively taken what was supposed to be a list of user-friendly 1913 rich-text names (supporting mixed case, spaces, punctuation, 1914 non-Roman characters and other symbols) and turned it into 1915 just about the worst user-interface imaginable: a list of 1916 incomprehensible random-looking strings of letters and digits. 1917 In a network with a lot of printers, it would be desirable for 1918 the people setting up the printers to take a moment to give each 1919 one a descriptive name, but in the event they don't, presenting 1920 the users with a list of sequentially-numbered printers is a much 1921 more desirable default user experience than showing a list of raw 1922 Ethernet addresses. 1924 Appendix E. Name Encodings in the Domain Name System 1926 Although the original DNS specifications [RFC 1033][RFC 1034][RFC 1927 1035] recommended that host names contain only letters, digits and 1928 hyphens (because of the limitations of the typing-based user 1929 interfaces of that era), Service Instance Names are not host names. 1930 Users generally access a service not by typing in the Instance Name, 1931 but by selecting it from a list presented by a user interface. 1932 "Clarifications to the DNS Specification" [RFC 2181] directly 1933 discusses the subject of allowable character set in Section 11 ("Name 1934 syntax"), and explicitly states that the traditional letters-digits- 1935 hyphens rule only applies to conventional host names: 1937 Occasionally it is assumed that the Domain Name System serves only 1938 the purpose of mapping Internet host names to data, and mapping 1939 Internet addresses to host names. This is not correct, the DNS is 1940 a general (if somewhat limited) hierarchical database, and can 1941 store almost any kind of data, for almost any purpose. 1943 The DNS itself places only one restriction on the particular 1944 labels that can be used to identify resource records. That one 1945 restriction relates to the length of the label and the full name. 1946 The length of any one label is limited to between 1 and 63 octets. 1947 A full domain name is limited to 255 octets (including the 1948 separators). The zero length full name is defined as representing 1949 the root of the DNS tree, and is typically written and displayed 1950 as ".". Those restrictions aside, any binary string whatever can 1951 be used as the label of any resource record. Similarly, any 1952 binary string can serve as the value of any record that includes a 1953 domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, 1954 and any others that may be added). Implementations of the DNS 1955 protocols must not place any restrictions on the labels that can 1956 be used. In particular, DNS servers must not refuse to serve a 1957 zone because it contains labels that might not be acceptable to 1958 some DNS client programs. 1960 Note that just because DNS-based Service Discovery supports arbitrary 1961 UTF-8-encoded names doesn't mean that any particular user or 1962 administrator is obliged to make use of that capability. Any user is 1963 free, if they wish, to continue naming their services using only 1964 letters, digits and hyphens, with no spaces, capital letters, or 1965 other punctuation. 1967 Appendix F. "Continuous Live Update" Browsing Model 1969 Of particular concern in the design of DNS-SD, particularly when 1970 used in conjunction with ad hoc Multicast DNS, was the dynamic nature 1971 of service discovery in a changing network environment. Other service 1972 discovery protocols seem to have been designed with an implicit 1973 unstated assumption that the usage model is: 1975 (a) client software calls the service discovery code 1976 (b) service discovery code spends a few seconds getting list of 1977 instances available at a particular moment in time, and then 1978 (c) client software displays list for user to select from 1980 Superficially this usage model seems reasonable, but the problem is 1981 that it's too optimistic. It only considers the success case, where 1982 the software immediately finds the service instance the user is 1983 looking for. 1985 In the case where the user is looking for (say) a particular printer, 1986 and that printer's not turned on or not connected, the user first has 1987 to attempt to remedy the problem, and then has to click a "refresh" 1988 button to retry the service discovery to find out whether they were 1989 successful. Because nothing happens instantaneously in networking, 1990 and packets can be lost, necessitating some number of 1991 retransmissions, a service discovery search is not instantaneous and 1992 typically takes a few seconds. A fairly typical user experience is: 1994 (a) display an empty window, 1995 (b) display some animation like a searchlight 1996 sweeping back and forth for ten seconds, and then 1997 (c) at the end of the ten-second search, display 1998 a static list showing what was discovered. 2000 Every time the user clicks the "refresh" button they have to endure 2001 another ten-second wait, and every time the discovered list is 2002 finally shown at the end of the ten-second wait, the moment it's 2003 displayed on the screen it's already beginning to get stale and 2004 out-of-date. 2006 The service discovery user experience that the DNS-SD designers had 2007 in mind has some rather different properties: 2009 1. Displaying the initial list of discovered services should be 2010 effectively instantaneous -- i.e. typically 0.1 seconds, not 2011 10 seconds. 2013 2. The list of discovered services should not be getting stale 2014 and out-of-date from the moment it's displayed. The list 2015 should be 'live' and should continue to update as new services 2016 are discovered. Because of the delays, packet losses, and 2017 retransmissions inherent in networking, it is to be expected 2018 that sometimes, after the initial list is displayed showing 2019 the majority of discovered services, a few remaining stragglers 2020 may continue to trickle in during the subsequent few seconds. 2021 Even after this stable list has been built and displayed, it 2022 should remain 'live' and should continue to update. At any future 2023 time, be it minutes, hours, or even days later, if a new service 2024 of the desired type is discovered, it should be displayed in the 2025 list automatically, without the user having to click a "refresh" 2026 button or take any other explicit action to update the display. 2028 3. With users getting to be in the habit of leaving service discovery 2029 windows open, and coming to expect to be able to rely on them to 2030 show a continuous 'live' view of current network reality, this 2031 gives us an additional requirement: deletion of stale services. 2032 When a service discovery list shows just a static snapshot at a 2033 moment in time, then the situation is simple: either a service was 2034 discovered and appears in the list, or it was not, and does not. 2035 However, when our list is live and updates continuously with the 2036 discovery of new services, then this implies the corollary: when 2037 a service goes away, it needs to *disappear* from the service 2038 discovery list. Otherwise, the service discovery list would simply 2039 grow monotonically over time, accreting stale data, and would 2040 require a periodic "refresh" (or complete dismissal and 2041 recreation) to restore correct display. 2043 4. With users getting to be in the habit of leaving service discovery 2044 windows open, these windows need to update not only in response 2045 to services coming and going, but also in response to changes 2046 in configuration and connectivity of the client machine itself. 2047 For example, if a user opens a service discovery window when no 2048 Ethernet cable is connected to the client machine, and the window 2049 appears empty with no discovered services, then when the user 2050 connects the cable the window should automatically populate with 2051 discovered services without requiring any explicit user action. 2052 If the user disconnects the Ethernet cable, all the services 2053 discovered via that network interface should automatically 2054 disappear. If the user switches from one 802.11 [IEEE W] wireless 2055 base station to another, the service discovery window should 2056 automatically update to remove all the services discovered via the 2057 old wireless base station, and add all the services discovered via 2058 the new one. 2060 Appendix G. Deployment History 2062 In July 1997, in an email to the net-thinkers@thumper.vmeng.com 2063 mailing list, Stuart Cheshire first proposed the idea of running 2064 AppleTalk Name Binding Protocol [NBP] over IP. As a result of this 2065 and related IETF discussions, the IETF Zeroconf Working Group was 2066 chartered September 1999. After various working group discussions and 2067 other informal IETF discussions, several Internet Drafts were 2068 written, which were loosely-related to the general themes of DNS and 2069 multicast, but did not address the service discovery aspect of NBP. 2071 In April 2000 Stuart Cheshire registered IPv4 multicast address 2072 224.0.0.251 with IANA [mcast4] and began writing code to test and 2073 develop the idea of performing NBP-like service discovery using 2074 Multicast DNS, which was documented in a group of three Internet 2075 Drafts: 2077 o "draft-cheshire-dnsext-nbp-00.txt", was an overview explaining 2078 AppleTalk Name Binding Protocol, because many in the IETF 2079 community had little first-hand experience using AppleTalk, and 2080 confusion in the IETF community about what AppleTalk NBP did was 2081 causing confusion about what would be required in an IP-based 2082 replacement. 2084 o "draft-cheshire-dnsext-nias-00.txt" ("Named Instances of Abstract 2085 Services") proposed a way to perform NBP-like service discovery 2086 using DNS-compatible names and record types. 2088 o "draft-cheshire-dnsext-multicastdns-00.txt" proposed a way to 2089 transport those DNS-compatible queries and responses using IP 2090 multicast, for Zero Configuration environments where no 2091 conventional unicast DNS server was available. 2093 In 2001 an update to Mac OS 9 added resolver library support for host 2094 name lookup using Multicast DNS. If the user typed a name such as 2095 "MyPrinter.local." into any piece of networking software that used 2096 the standard Mac OS 9 name lookup APIs, then those name lookup APIs 2097 would recognize the name as a dot-local name and query for it by 2098 sending simple one-shot Multicast DNS Queries to 224.0.0.251:5353. 2099 This enabled the user to, for example, enter the name 2100 "MyPrinter.local." into their web browser in order to view a 2101 printer's status and configuration web page, or enter the name 2102 "MyPrinter.local." into the printer setup utility to create a print 2103 queue for printing documents on that printer. 2105 Multicast DNS Responder software, with full service discovery, first 2106 began shipping to end users in volume with the launch of Mac OS X 2107 10.2 "Jaguar" in August 2002, and network printer makers (who had 2108 historically supported AppleTalk in their network printers, and were 2109 receptive to IP-based technologies that could offer them similar 2110 ease-of-use) started adopting Multicast DNS shortly thereafter. 2112 In September 2002 Apple released the source code for the 2113 mDNSResponder daemon as Open Source under Apple's standard Apple 2114 Public Source License (APSL). 2116 Multicast DNS Responder software became available for Microsoft 2117 Windows users in June 2004 with the launch of Apple's "Rendezvous for 2118 Windows" (now "Bonjour for Windows"), both in executable form (a 2119 downloadable installer for end users) and as Open Source (one of the 2120 supported platforms within Apple's body of cross-platform code in the 2121 publicly-accessible mDNSResponder CVS source code repository) [B4W]. 2123 In August 2006, Apple re-licensed the cross-platform mDNSResponder 2124 source code under the Apache License, Version 2.0. 2126 In January 2007, the IETF published the Informational RFC "Link-Local 2127 Multicast Name Resolution", which is substantially similar to 2128 Multicast DNS, but incompatible in some small but important ways. In 2129 particular, the LLMNR design explicitly excluded support for service 2130 discovery [RFC 4795], which made it an unsuitable candidate for a 2131 protocol to replace AppleTalk NBP [NBP]. 2133 In addition to desktop and laptop computers running Mac OS X and 2134 Microsoft Windows, Multicast DNS is now implemented in a wide range 2135 of hardware devices, such as Apple's "AirPort" wireless base 2136 stations, iPhone and iPad, and in home gateways from other vendors, 2137 network printers, network cameras, TiVo DVRs, etc. 2139 The Open Source community has produced many independent 2140 implementations of Multicast DNS, some in C like Apple's 2141 mDNSResponder daemon, and others in a variety of different languages 2142 including Java, Python, Perl, and C#/Mono. 2144 While the original focus of Multicast DNS and DNS-based Service 2145 Discovery was for Zero Configuration environments without a 2146 conventional unicast DNS server, DNS-based Service Discovery also 2147 works using unicast DNS servers, using DNS Update [RFC 2136] 2148 [RFC 3007] to create service discovery records and standard DNS 2149 queries to query for them. Apple's Back to My Mac service, launched 2150 with Mac OS X 10.5 "Leopard" in October 2007, uses DNS-based Service 2151 Discovery over unicast DNS. 2153 Authors' Addresses 2155 Stuart Cheshire 2156 Apple Inc. 2157 1 Infinite Loop 2158 Cupertino 2159 California 95014 2160 USA 2162 Phone: +1 408 974 3207 2163 EMail: cheshire@apple.com 2165 Marc Krochmal 2166 Apple Inc. 2167 1 Infinite Loop 2168 Cupertino 2169 California 95014 2170 USA 2172 Phone: +1 408 974 4368 2173 EMail: marc@apple.com