idnits 2.17.1 draft-cheshire-dnsext-dns-sd-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1782. 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 9 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 1 instance 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 Copyright Line does not match the current year == Line 1431 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 (10 September 2008) is 5708 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 3492' is mentioned on line 324, but not defined == Outdated reference: A later version (-10) exists of draft-cheshire-dnsext-nbp-06 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Document: draft-cheshire-dnsext-dns-sd-05.txt Stuart Cheshire 2 Internet-Draft Marc Krochmal 3 Category: Informational Apple Inc. 4 Expires: 10 March 2009 10 September 2008 6 DNS-Based Service Discovery 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 For the purposes of this document, the term "BCP 79" refers 17 exclusively to RFC 3979, "Intellectual Property Rights in IETF 18 Technology", published March 2005. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This document describes a convention for naming and structuring DNS 39 resource records. Given a type of service that a client is looking 40 for, and a domain in which the client is looking for that service, 41 this convention allows clients to discover a list of named instances 42 of that desired service, using standard DNS queries. In short, this 43 is referred to as DNS-based Service Discovery, or DNS-SD. 45 Table of Contents 47 1. Introduction...................................................3 48 2. Conventions and Terminology Used in this Document..............4 49 3. Design Goals...................................................4 50 4. Service Instance Enumeration (Browsing)........................5 51 4.1 Structured Instance Names......................................5 52 4.2 User Interface Presentation....................................8 53 4.3 Internal Handling of Names.....................................8 54 4.4 What You See Is What You Get...................................9 55 4.5 Ordering of Service Instance Name Components..................10 56 5. Service Name Resolution.......................................12 57 6. Data Syntax for DNS-SD TXT Records............................13 58 6.1 General Format Rules for DNS TXT Records......................13 59 6.2 DNS TXT Record Format Rules for use in DNS-SD.................14 60 6.3 DNS-SD TXT Record Size........................................15 61 6.4 Rules for Names in DNS-SD Name/Value Pairs....................16 62 6.5 Rules for Values in DNS-SD Name/Value Pairs...................18 63 6.6 Example TXT Record............................................19 64 6.7 Version Tag...................................................19 65 7. Application Protocol Names....................................20 66 7.1 Selective Instance Enumeration................................21 67 7.2 Service Name Length Limits....................................22 68 8. Flagship Naming...............................................24 69 9. Service Type Enumeration......................................25 70 10. Populating the DNS with Information...........................26 71 11. Relationship to Multicast DNS.................................26 72 12. Discovery of Browsing and Registration Domains................27 73 13. DNS Additional Record Generation..............................28 74 14. Comparison with Alternative Service Discovery Protocols.......29 75 15. Working Examples..............................................31 76 16. User Interface Considerations.................................32 77 16.1 Service Advertising User-Interface Considerations.............32 78 16.2 Client Browsing User-Interface Considerations.................33 79 17. IPv6 Considerations...........................................36 80 18. Security Considerations.......................................36 81 19. IANA Considerations...........................................36 82 20. Acknowledgments...............................................37 83 21. Deployment History............................................37 84 22. Copyright Notice..............................................38 85 23. Intellectual Property Notice..................................38 86 24. Normative References..........................................39 87 25. Informative References........................................39 88 26. Authors' Addresses............................................40 90 1. Introduction 92 This document describes a convention for naming and structuring DNS 93 resource records. Given a type of service that a client is looking 94 for, and a domain in which the client is looking for that service, 95 this convention allows clients to discover a list of named instances 96 of a that desired service, using standard DNS queries. In short, this 97 is referred to as DNS-based Service Discovery, or DNS-SD. 99 This document proposes no change to the structure of DNS messages, 100 and no new operation codes, response codes, resource record types, 101 or any other new DNS protocol values. This document simply specifies 102 a convention for how existing resource record types can be named and 103 structured to facilitate service discovery. 105 This document specifies that a particular service instance can be 106 described using a DNS SRV [RFC 2782] and DNS TXT [RFC 1035] record. 107 The SRV record has a name of the form ".." 108 and gives the target host and port where the service instance can 109 be reached. The DNS TXT record of the same name gives additional 110 information about this instance, in a structured form using 111 key/value pairs, described in Section 6. A client discovers 112 the list of available instances of a given service type using 113 a query for a DNS PTR [RFC 1035] record with a name of the form 114 ".", which returns a list of zero or more names, 115 which are the names of the aforementioned DNS SRV/TXT record pairs. 117 This specification is compatible with both Multicast DNS [mDNS] and 118 with today's existing unicast DNS server and client software. 120 Note that when using DNS-SD with unicast DNS, the unicast DNS-SD 121 service does NOT have to be provided by the same DNS server hardware 122 that is currently providing an organization's conventional host name 123 lookup service (the service we traditionally think of when we say 124 "DNS"). By delegating the "_tcp" subdomain, all the workload related 125 to DNS-SD can be offloaded to a different machine. This flexibility, 126 to handle DNS-SD on the main DNS server, or not, at the network 127 administrator's discretion, is one of the things that makes DNS-SD 128 compelling. 130 Even when the DNS-SD functions are delegated to a different machine, 131 the benefits of using DNS remain: It is mature technology, well 132 understood, with multiple independent implementations from different 133 vendors, a wide selection of books published on the subject, and an 134 established workforce experienced in its operation. In contrast, 135 adopting some other service discovery technology would require every 136 site in the world to install, learn, configure, operate and maintain 137 some entirely new and unfamiliar server software. Faced with these 138 obstacles, it seems unlikely that any other service discovery 139 technology could hope to compete with the ubiquitous deployment 140 that DNS already enjoys. 142 2. Conventions and Terminology Used in this Document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in "Key words for use in 147 RFCs to Indicate Requirement Levels" [RFC 2119]. 149 3. Design Goals 151 Of the many properties a good service discovery protocol needs to 152 have, three in particular are: 154 (i) The ability to query for services of a certain type in a certain 155 logical domain and receive in response a list of named instances 156 (network browsing, or "Service Instance Enumeration"). 158 (ii) Given a particular named instance, the ability to efficiently 159 resolve that instance name to the required information a client needs 160 to actually use the service, i.e. IP address and port number, at the 161 very least (Service Name Resolution). 163 (iii) Instance names should be relatively persistent. If a user 164 selects their default printer from a list of available choices today, 165 then tomorrow they should still be able to print on that printer -- 166 even if the IP address and/or port number where the service resides 167 have changed -- without the user (or their software) having to repeat 168 the network browsing step a second time. 170 In addition, if it is to become successful, a service discovery 171 protocol should be so simple to implement that virtually any 172 device capable of implementing IP should not have any trouble 173 implementing the service discovery software as well. 175 These goals are discussed in more detail in the remainder of this 176 document. A more thorough treatment of service discovery requirements 177 may be found in "Requirements for Replacing AppleTalk" [ATalk]. 178 That document draws upon examples from two decades of operational 179 experience with AppleTalk Name Binding Protocol to develop a list of 180 universal requirements which are broadly applicable to any potential 181 service discovery protocol. 183 4. Service Instance Enumeration (Browsing) 185 DNS SRV records [RFC 2782] are useful for locating instances of a 186 particular type of service when all the instances are effectively 187 indistinguishable and provide the same service to the client. 189 For example, SRV records with the (hypothetical) name 190 "_http._tcp.example.com." would allow a client to discover a list of 191 all servers implementing the "_http._tcp" service (i.e. web servers) 192 for the "example.com." domain. The unstated assumption is that all 193 these servers offer an identical set of web pages, and it doesn't 194 matter to the client which of the servers it uses, as long as it 195 selects one at random according to the weight and priority rules 196 laid out in the DNS SRV specification [RFC 2782]. 198 Instances of other kinds of service are less easily interchangeable. 199 If a word processing application were to look up the (hypothetical) 200 SRV record "_ipp._tcp.example.com." to find the list of IPP printers 201 at Example Co., then picking one at random and printing on it would 202 probably not be what the user wanted. 204 The remainder of this section describes how SRV records may be used 205 in a slightly different way to allow a user to discover the names 206 of all available instances of a given type of service, in order to 207 select the particular instance the user desires. 209 4.1 Structured Instance Names 211 This document borrows the logical service naming syntax and semantics 212 from DNS SRV records, but adds one level of indirection. Instead of 213 requesting records of type "SRV" with name "_ipp._tcp.example.com.", 214 the client requests records of type "PTR" (pointer from one name to 215 another in the DNS namespace). 217 In effect, if one thinks of the domain name "_ipp._tcp.example.com." 218 as being analogous to an absolute path to a directory in a file 219 system, then DNS-SD's PTR lookup is akin to performing a listing of 220 that directory to find all the files it contains. (Remember that 221 domain names are expressed in reverse order compared to path names: 222 An absolute path name is read from left to right, beginning with a 223 leading slash on the left, and then the top level directory, then the 224 next level directory, and so on. A fully-qualified domain name is 225 read from right to left, beginning with the dot on the right -- the 226 root label -- and then the top level domain to the left of that, and 227 the second level domain to the left of that, and so on. If the fully- 228 qualified domain name "_ipp._tcp.example.com." were expressed as a 229 file system path name, it would be "/com/example/_tcp/_ipp".) 230 The result of this PTR lookup for the name "." is a 231 list of zero or more PTR records giving Service Instance Names of the 232 form: 234 Service Instance Name = . . 236 The portion of the Service Instance Name is a single DNS 237 label, containing arbitrary precomposed (Unicode Normalization Form C 238 [UAX15]) UTF-8-encoded text [RFC 3629]. It is a user-friendly name, 239 meaning that it is allowed to contain any characters, without 240 restriction, including spaces, upper case, lower case, punctuation -- 241 including dots -- accented characters, non-roman text, and anything 242 else that may be represented using UTF-8. Although the original DNS 243 specifications [RFC 1033][RFC 1034][RFC 1035] recommended that host 244 names contain only letters, digits and hyphens (because of the 245 limitations of the typing-based user interfaces of that era), Service 246 Instance Names are not host names. Service Instance Names are not 247 intended to ever be typed in by a user accessing a service; the user 248 accesses a service by selecting its name from a list of choices 249 presented on the screen. "Clarifications to the DNS Specification" 250 [RFC 2181] directly discusses the subject of allowable character set 251 in Section 11 ("Name syntax"), and explicitly states that the 252 traditional letters-digits-hyphens rule only applies to conventional 253 host names: 255 Occasionally it is assumed that the Domain Name System serves only 256 the purpose of mapping Internet host names to data, and mapping 257 Internet addresses to host names. This is not correct, the DNS is 258 a general (if somewhat limited) hierarchical database, and can 259 store almost any kind of data, for almost any purpose. 261 The DNS itself places only one restriction on the particular 262 labels that can be used to identify resource records. That one 263 restriction relates to the length of the label and the full name. 264 The length of any one label is limited to between 1 and 63 octets. 265 A full domain name is limited to 255 octets (including the 266 separators). The zero length full name is defined as representing 267 the root of the DNS tree, and is typically written and displayed 268 as ".". Those restrictions aside, any binary string whatever can 269 be used as the label of any resource record. Similarly, any 270 binary string can serve as the value of any record that includes a 271 domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, 272 and any others that may be added). Implementations of the DNS 273 protocols must not place any restrictions on the labels that can 274 be used. In particular, DNS servers must not refuse to serve a 275 zone because it contains labels that might not be acceptable to 276 some DNS client programs. 278 Note that just because this protocol supports arbitrary UTF-8-encoded 279 names doesn't mean that any particular user or administrator is 280 obliged to make use of that capability. Any user is free, if they 281 wish, to continue naming their services using only letters, digits 282 and hyphens, with no spaces, capital letters, or other punctuation. 284 DNS labels are currently limited to 63 octets in length. UTF-8 285 encoding can require up to four octets per Unicode character, which 286 means that in the worst case, the portion of a name could 287 be limited to fifteen Unicode characters. However, the Unicode 288 characters with longer UTF-8 encodings tend to be the more obscure 289 ones, and tend to be the ones that convey greater meaning per 290 character. 292 Note that any character in the commonly-used 16-bit Unicode space 293 can be encoded with no more than three octets of UTF-8 encoding. This 294 means that an Instance name can contain up to 21 Kanji characters, 295 which is a sufficiently expressive name for most purposes. 297 The portion of the Service Instance Name consists of a pair 298 of DNS labels, following the established convention for SRV records 299 [RFC 2782], namely: the first label of the pair is the Application 300 Protocol Name, and the second label is either "_tcp" or "_udp", 301 depending on the transport protocol used by the application. 302 More details are given in Section 7, "Application Protocol Names". 304 The portion of the Service Instance Name specifies the DNS 305 subdomain within which the service names are registered. It may be 306 "local.", meaning "link-local Multicast DNS" [mDNS], or it may be 307 a conventional unicast DNS domain name, such as "apple.com.", 308 "cs.stanford.edu.", or "eng.us.ibm.com." Because service names are 309 not host names, they are not constrained by the usual rules for host 310 names [RFC 1033][RFC 1034][RFC 1035], and rich-text service 311 subdomains are allowed and encouraged, for example: 313 Building 2, 1st Floor.apple.com. 314 Building 2, 2nd Floor.apple.com. 315 Building 2, 3rd Floor.apple.com. 316 Building 2, 4th Floor.apple.com. 318 In addition, because Service Instance Names are not constrained by 319 the limitations of host names, this document recommends that they 320 be stored in the DNS, and communicated over the wire, encoded as 321 straightforward canonical precomposed UTF-8, Unicode Normalization 322 Form C [UAX15]. In cases where the DNS server returns a negative 323 response for the name in question, client software MAY choose to 324 retry the query using "Punycode" [RFC 3492] encoding, beginning with 325 using Punycode encoding for the top level label, and then issuing 326 the query repeatedly, with successively more labels converted to 327 Punycode each time, only giving up after it has converted all labels 328 to Punycode and the query still fails. 330 4.2 User Interface Presentation 332 The names resulting from the PTR lookup are presented to the user in 333 a list for the user to select one (or more). Typically only the first 334 label is shown (the user-friendly portion of the name). In 335 the common case, the and are already known to the 336 client software, these having been provided implicitly by the user in 337 the first place, by the act of indicating the service being sought, 338 and the domain in which to look for it. Note: The software handling 339 the response should be careful not to make invalid assumptions 340 though, since it *is* possible, though rare, for a service 341 enumeration in one domain to return the names of services in a 342 different domain. Similarly, when using subtypes (see "Selective 343 Instance Enumeration") the of the discovered instance may 344 not be exactly the same as the that was requested. 346 Having chosen the desired named instance, the Service Instance 347 Name may then be used immediately, or saved away in some persistent 348 user-preference data structure for future use, depending on what is 349 appropriate for the application in question. 351 4.3 Internal Handling of Names 353 If the , and portions are internally 354 concatenated together into a single string, then care must be taken 355 with the portion, since it is allowed to contain any 356 characters, including dots. 358 Any dots in the portion should be escaped by preceding 359 them with a backslash ("." becomes "\."). Likewise, any backslashes 360 in the portion should also be escaped by preceding them 361 with a backslash ("\" becomes "\\"). Having done this, the three 362 components of the name may be safely concatenated. The backslash- 363 escaping allows literal dots in the name (escaped) to be 364 distinguished from label-separator dots (not escaped). 366 The resulting concatenated string may be safely passed to standard 367 DNS APIs like res_query(), which will interpret the string correctly 368 provided it has been escaped correctly, as described here. 370 4.4 What You See Is What You Get 372 Some service discovery protocols decouple the true service identifier 373 from the name presented to the user. The true service identifier used 374 by the protocol is an opaque unique id, often represented using a 375 long string of hexadecimal digits, and should never be seen by the 376 typical user. The name presented to the user is merely one of the 377 ephemeral attributes attached to this opaque identifier. 379 The problem with this approach is that it decouples user perception 380 from reality: 382 * What happens if there are two service instances, with different 383 unique ids, but they have inadvertently been given the same 384 user-visible name? If two instances appear in an on-screen list 385 with the same name, how does the user know which is which? 387 * Suppose a printer breaks down, and the user replaces it with 388 another printer of the same make and model, and configures the 389 new printer with the exact same name as the one being replaced: 390 "Stuart's Printer". Now, when the user tries to print, the 391 on-screen print dialog tells them that their selected default 392 printer is "Stuart's Printer". When they browse the network to see 393 what is there, they see a printer called "Stuart's Printer", yet 394 when the user tries to print, they are told that the printer 395 "Stuart's Printer" can't be found. The hidden internal unique id 396 that the software is trying to find on the network doesn't match 397 the hidden internal unique id of the new printer, even though its 398 apparent "name" and its logical purpose for being there are the 399 same. To remedy this, the user typically has to delete the print 400 queue they have created, and then create a new (apparently 401 identical) queue for the new printer, so that the new queue will 402 contain the right hidden internal unique id. Having all this hidden 403 information that the user can't see makes for a confusing and 404 frustrating user experience, and exposing long ugly hexadecimal 405 strings to the user and forcing them to understand what they mean 406 is even worse. 408 * Suppose an existing printer is moved to a new department, and given 409 a new name and a new function. Changing the user-visible name of 410 that piece of hardware doesn't change its hidden internal unique 411 id. Users who had previously created print queues for that printer 412 will still be accessing the same hardware by its unique id, even 413 though the logical service that used to be offered by that hardware 414 has ceased to exist. 416 To solve these problems requires the user or administrator to be 417 aware of the supposedly hidden unique id, and to set its value 418 correctly as hardware is moved around, repurposed, or replaced, 419 thereby contradicting the notion that it is a hidden identifier that 420 human users never need to deal with. Requiring the user to understand 421 this expert behind-the-scenes knowledge of what is *really* going on 422 is just one more burden placed on the user when they are trying to 423 diagnose why their computers and network devices are not working as 424 expected. 426 These anomalies and counter-intuitive behaviors can be eliminated by 427 maintaining a tight bidirectional one-to-one mapping between what 428 the user sees on the screen and what is really happening "behind 429 the curtain". If something is configured incorrectly, then that is 430 apparent in the familiar day-to-day user interface that everyone 431 understands, not in some little-known rarely-used "expert" interface. 433 In summary: The user-visible name is the primary identifier for a 434 service. If the user-visible name is changed, then conceptually 435 the service being offered is a different logical service -- even 436 though the hardware offering the service stayed the same. If the 437 user-visible name doesn't change, then conceptually the service being 438 offered is the same logical service -- even if the hardware offering 439 the service is new hardware brought in to replace some old equipment. 441 There are certainly arguments on both sides of this debate. 442 Nonetheless, the designers of any service discovery protocol have 443 to make a choice between having the primary identifiers be hidden, or 444 having them be visible, and these are the reasons that we chose to 445 make them visible. We're not claiming that there are no disadvantages 446 of having primary identifiers be visible. We considered both 447 alternatives, and we believe that the few disadvantages of visible 448 identifiers are far outweighed by the many problems caused by use of 449 hidden identifiers. 451 4.5 Ordering of Service Instance Name Components 453 There have been questions about why services are named using DNS 454 Service Instance Names of the form: 456 Service Instance Name = . . 458 instead of: 460 Service Instance Name = . . 462 There are three reasons why it is beneficial to name service 463 instances with the parent domain as the most-significant (rightmost) 464 part of the name, then the abstract service type as the next-most 465 significant, and then the specific instance name as the 466 least-significant (leftmost) part of the name: 468 4.5.1. Semantic Structure 470 The facility being provided by browsing ("Service Instance 471 Enumeration") is effectively enumerating the leaves of a tree 472 structure. A given domain offers zero or more services. For each 473 of those service types, there may be zero or more instances of 474 that service. 476 The user knows what type of service they are seeking. (If they are 477 running an FTP client, they are looking for FTP servers. If they have 478 a document to print, they are looking for entities that speak some 479 known printing protocol.) The user knows in which organizational or 480 geographical domain they wish to search. (The user does not want a 481 single flat list of every single printer on the planet, even if such 482 a thing were possible.) What the user does not know in advance is 483 whether the service they seek is offered in the given domain, or if 484 so, how many instances are offered, and the names of those instances. 485 Hence having the instance names be the leaves of the tree is 486 consistent with this semantic model. 488 Having the service types be the terminal leaves of the tree would 489 imply that the user knows the domain name, and already knows the 490 name of the service instance, but doesn't have any idea what the 491 service does. We would argue that this is a less useful model. 493 4.5.2. Network Efficiency 495 When a DNS response contains multiple answers, name compression works 496 more effectively if all the names contain a common suffix. If many 497 answers in the packet have the same and , then each 498 occurrence of a Service Instance Name can be expressed using only 499 the part followed by a two-byte compression pointer 500 referencing a previous appearance of ".". This 501 efficiency would not be possible if the component appeared 502 first in each name. 504 4.5.3. Operational Flexibility 506 This name structure allows subdomains to be delegated along logical 507 service boundaries. For example, the network administrator at Example 508 Co. could choose to delegate the "_tcp.example.com." subdomain to a 509 different machine, so that the machine handling service discovery 510 doesn't have to be the same as the machine handling other day-to-day 511 DNS operations. (It *can* be the same machine if the administrator 512 so chooses, but the administrator is free to make that choice.) 513 Furthermore, if the network administrator wishes to delegate all 514 information related to IPP printers to a machine dedicated to 515 that specific task, this is easily done by delegating the 516 "_ipp._tcp.example.com." subdomain to the desired machine. It is 517 also convenient to set security policies on a per-zone/per-subdomain 518 basis. For example, the administrator may choose to enable DNS 519 Dynamic Update [RFC 2136] [RFC 3007] for printers registering 520 in the "_ipp._tcp.example.com." subdomain, but not for other 521 zones/subdomains. This easy flexibility would not exist if the 522 component appeared first in each name. 524 5. Service Name Resolution 526 Given a particular Service Instance Name, when a client needs to 527 contact that service, it queries for the SRV and TXT records of that 528 name. The SRV record for a service gives the port number and target 529 host where the service may be found. The TXT record gives additional 530 information about the service, as described in Section 6 below, "Data 531 Syntax for DNS-SD TXT Records". 533 SRV records are extremely useful because they remove the need for 534 preassigned port numbers. There are only 65535 TCP port numbers 535 available. These port numbers are being allocated one-per- 536 application-protocol at an alarming rate. Some protocols like the 537 X Window System have a block of 64 TCP ports allocated (6000-6063). 538 Using a different TCP port for each different instance of a given 539 service on a given machine is entirely sensible, but allocating each 540 application its own large static range is not a practical way to do 541 that. On any given host, most TCP ports are reserved for services 542 that will never run on that particular host in its lifetime. This is 543 very poor utilization of the limited port space. Using SRV records 544 allows each host to allocate its available port numbers dynamically 545 to those services actually running on that host that need them, and 546 then advertise the allocated port numbers via SRV records. Allocating 547 the available listening port numbers locally on a per-host basis as 548 needed allows much better utilization of the available port space 549 than today's centralized global allocation. 551 In the event that more than one SRV is returned, clients SHOULD 552 correctly interpret the priority and weight fields -- i.e. lower 553 numbered priority servers should be used in preference to higher 554 numbered priority servers, and servers with equal priority should be 555 selected randomly in proportion to their relative weights. However, 556 in the overwhelmingly common case, a single advertised DNS-SD service 557 instance is described by exactly one SRV record, and in this common 558 case the priority and weight fields of the SRV record SHOULD both be 559 set to zero. 561 6. Data Syntax for DNS-SD TXT Records 563 Some services discovered via Service Instance Enumeration may need 564 more than just an IP address and port number to properly identify the 565 service. For example, printing via the LPR protocol often specifies a 566 queue name. This queue name is typically short and cryptic, and need 567 not be shown to the user. It should be regarded the same way as the 568 IP address and port number -- it is one component of the addressing 569 information required to identify a specific instance of a service 570 being offered by some piece of hardware. Similarly, a file server may 571 have multiple volumes, each identified by its own volume name. A web 572 server typically has multiple pages, each identified by its own URL. 573 In these cases, the necessary additional data is stored in a TXT 574 record with the same name as the SRV record. The specific nature of 575 that additional data, and how it is to be used, is service-dependent, 576 but the overall syntax of the data in the TXT record is standardized, 577 as described below. Every DNS-SD service MUST have a TXT record in 578 addition to its SRV record, with the same name, even if the service 579 has no additional data to store and the TXT record contains no more 580 than a single zero byte. 582 6.1 General Format Rules for DNS TXT Records 584 A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total 585 length is indicated by the length given in the resource record header 586 in the DNS message. There is no way to tell directly from the data 587 alone how long it is (e.g. there is no length count at the start, or 588 terminating NULL byte at the end). 590 Note that when using Multicast DNS [mDNS] the maximum packet size is 591 9000 bytes, including IP header, UDP header, and DNS message header, 592 which imposes an upper limit on the size of TXT records of about 8900 593 bytes. In practice the sensible maximum size of a DNS-SD TXT record 594 size is smaller even than this, typically at most a few hundred 595 bytes, as described in Section 6.3. 597 The format of the data within a DNS TXT record is one or more 598 strings, packed together in memory without any intervening gaps 599 or padding bytes for word alignment. 601 The format of each constituent string within the DNS TXT record is a 602 single length byte, followed by 0-255 bytes of text data. 604 These format rules are defined in Section 3.3.14 of RFC 1035, and are 605 not specific to DNS-SD. DNS-SD simply specifies a usage convention 606 for what data should be stored in those constituent strings. 608 An empty TXT record containing zero strings is disallowed by RFC 609 1035. DNS-SD implementations MUST NOT emit empty TXT records. 610 DNS-SD implementations receiving empty TXT records MUST treat them 611 as equivalent to a one-byte TXT record containing a single zero byte 612 (i.e. a single empty string). 614 6.2 DNS TXT Record Format Rules for use in DNS-SD 616 DNS-SD uses DNS TXT records to store arbitrary key/value pairs 617 conveying additional information about the named service. Each 618 key/value pair is encoded as its own constituent string within the 619 DNS TXT record, in the form "key=value". Everything up to the first 620 '=' character is the key. Everything after the first '=' character 621 to the end of the string (including subsequent '=' characters, if 622 any) is the value. Specific rules governing keys and values are 623 given below. Each author defining a DNS-SD profile for discovering 624 instances of a particular type of service should define the base set 625 of key/value attributes that are valid for that type of service. 627 Using this standardized key/value syntax within the TXT record makes 628 it easier for these base definitions to be expanded later by defining 629 additional named attributes. If an implementation sees unknown 630 keys in a service TXT record, it MUST silently ignore them. 632 The TCP (or UDP) port number of the service, and target host name, 633 are given in the SRV record. This information -- target host name and 634 port number -- MUST NOT be duplicated using key/value attributes in 635 the TXT record. 637 The intention of DNS-SD TXT records is to convey a small amount of 638 useful additional information about a service. Ideally it SHOULD NOT 639 be necessary for a client to retrieve this additional information 640 before it can usefully establish a connection to the service. For a 641 well-designed TCP-based application protocol, it should be possible, 642 knowing only the host name and port number, to open a connection 643 to that listening process, and then perform version- or feature- 644 negotiation to determine the capabilities of the service instance. 645 For example, when connecting to an Apple Filing Protocol (AFP) [AFP] 646 server over TCP, the client enters into a protocol exchange with the 647 server to determine which version of AFP the server implements, and 648 which optional features or capabilities (if any) are available. For a 649 well-designed application protocol, clients should be able to connect 650 and use the service even if there is no information at all in the TXT 651 record. In this case, the information in the TXT record should be 652 viewed as a performance optimization -- when a client discovers many 653 instances of a service, the TXT record allows the client to know some 654 rudimentary information about each instance without having to open a 655 TCP connection to each one and interrogate every service instance 656 separately. Extreme care should be taken when doing this to ensure 657 that the information in the TXT record is in agreement with the 658 information retrieved by a client connecting over TCP. 660 There are legacy protocols which provide no feature negotiation 661 capability, and in these cases it may be useful to convey necessary 662 information in the TXT record. For example, when printing using the 663 old Unix LPR (port 515) protocol, the LPR service provides no way 664 for the client to determine whether a particular printer accepts 665 PostScript, or what version of PostScript, etc. In this case it is 666 appropriate to embed this information in the TXT record, because the 667 alternative is worse -- passing around written instructions to the 668 users, arcane manual configuration of "/etc/printcap" files, etc. 670 6.3 DNS-SD TXT Record Size 672 The total size of a typical DNS-SD TXT record is intended to be small 673 -- 200 bytes or less. 675 In cases where more data is justified (e.g. LPR printing), keeping 676 the total size under 400 bytes should allow it to fit in a single 677 standard 512-byte DNS message. (This standard DNS message size is 678 defined in RFC 1035.) 680 In extreme cases where even this is not enough, keeping the size of 681 the TXT record under 1300 bytes should allow it to fit in a single 682 1500-byte Ethernet packet. 684 Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this 685 time. 687 6.4 Rules for Keys in DNS-SD Key/Value Pairs 689 The "Key" MUST be at least one character. Strings beginning with an 690 '=' character (i.e. the key is missing) SHOULD be silently ignored. 692 The "Key" SHOULD be no more than nine characters long. This is 693 because it is beneficial to keep packet sizes small for the sake of 694 network efficiency. When using DNS-SD in conjunction with Multicast 695 DNS [mDNS] this is important because on 802.11 wireless networks 696 multicast traffic is especially expensive [IEEE W], but even when 697 using conventional Unicast DNS, keeping the TXT records small helps 698 improve the chance that responses will fit within the standard DNS 699 512-byte size limit [RFC 1035]. Also, each constituent string of a 700 DNS TXT record is limited to 255 bytes, so excessively long keys 701 reduce the space available for that key's values. 703 The Keys in Key/Value Pairs can be as short as a single character. 704 A key name needs only to be unique and unambiguous within the context 705 of the service type for which it is defined. A key name is intended 706 solely to be a machine-readable identifier, not a human-readable 707 essay giving detailed discussion of the purpose of a parameter, with 708 a URL to a web page giving yet more details of the specification. 709 For ease of development and debugging it can be valuable to use key 710 names that are mnemonic textual names, but excessively verbose keys 711 are wasteful and inefficient, hence the recommendation to keep them 712 to nine characters or fewer. 714 The characters of "Key" MUST be printable US-ASCII values 715 (0x20-0x7E), excluding '=' (0x3D). 717 Spaces in the key are significant, whether leading, trailing, or in 718 the middle -- so don't include any spaces unless you really intend 719 that. 721 Case is ignored when interpreting a key, so "papersize=A4", 722 "PAPERSIZE=A4" and "Papersize=A4" are all identical. 724 If there is no '=', then it is a boolean attribute, and is simply 725 identified as being present, with no value. 727 A given key may appear at most once in a TXT record. The reason for 728 this simplifying rule is to facilitate the creation of client 729 libraries that parse the TXT record into an internal data structure, 730 such as a hash table or dictionary object that maps from keys to 731 values, and then make that abstraction available to client code. The 732 rule that a given key may not appear more than once simplifies these 733 abstractions because they aren't required to support the case of 734 returning more than one value for a given key. 736 If a client receives a TXT record containing the same key more than 737 once, then the client MUST silently ignore all but the first 738 occurrence of that attribute. For client implementations that process 739 a DNS-SD TXT record from start to end, placing key/value pairs into a 740 hash table, using the key as the hash table key, this means that if 741 the implementation attempts to add a new key/value pair into the 742 table and finds an entry with the same key already present, then the 743 new entry being added should be silently discarded instead. For 744 client implementations that retrieve key/value pairs by searching the 745 TXT record for the requested key, they should search the TXT record 746 from the start, and simply return the first matching key they find. 748 When examining a TXT record for a given key, there are therefore four 749 categories of results which may be returned: 751 * Attribute not present (Absent) 753 * Attribute present, with no value 754 (e.g. "passreq" -- password required for this service) 756 * Attribute present, with empty value (e.g. "PlugIns=" -- 757 server supports plugins, but none are presently installed) 759 * Attribute present, with non-empty value 760 (e.g. "PlugIns=JPEG,MPEG2,MPEG4") 762 Each author defining a DNS-SD profile for discovering instances of a 763 particular type of service should define the interpretation of these 764 different kinds of result. For example, for some keys, there may be 765 a natural true/false boolean interpretation: 767 * Absent implies 'false' 768 * Present implies 'true' 769 For other keys it may be sensible to define other semantics, such as 770 value/no-value/unknown: 772 * Present with value implies that value. 773 E.g. "Color=4" for a four-color ink-jet printer, 774 or "Color=6" for a six-color ink-jet printer. 776 * Present with empty value implies 'false'. E.g. Not a color printer. 778 * Absent implies 'Unknown'. E.g. A print server connected to some 779 unknown printer where the print server doesn't actually know if the 780 printer does color or not -- which gives a very bad user experience 781 and should be avoided wherever possible. 783 (Note that this is a hypothetical example, not an example of actual 784 key/value keys used by DNS-SD network printers.) 786 6.5 Rules for Values in DNS-SD Key/Value Pairs 788 If there is an '=', then everything after the first '=' to the end 789 of the string is the value. The value can contain any eight-bit 790 values including '='. Leading or trailing spaces are part of the 791 value, so don't put them there unless you intend them to be there. 792 Any quotation marks around the value are part of the value, so don't 793 put them there unless you intend them to be part of the value. 795 The value is opaque binary data. Often the value for a particular 796 attribute will be US-ASCII (or UTF-8) text, but it is legal for a 797 value to be any binary data. For example, if the value of a key is an 798 IPv4 address, that address should simply be stored as four bytes of 799 binary data, not as a variable-length 7-15 byte ASCII string giving 800 the address represented in textual dotted decimal notation. 802 Generic debugging tools should generally display all attribute values 803 as a hex dump, with accompanying text alongside displaying the UTF-8 804 interpretation of those bytes, except for attributes where the 805 debugging tool has embedded knowledge that the value is some other 806 kind of data. 808 Authors defining DNS-SD profiles SHOULD NOT convert binary attribute 809 data types into printable text (e.g. using hexadecimal, Base-64 or UU 810 encoding) merely for the sake of making the data be printable text 811 when seen in a generic debugging tool. Doing this simply bloats the 812 size of the TXT record, without actually making the data any more 813 understandable to someone looking at it in a generic debugging tool. 815 6.6 Example TXT Record 817 The TXT record below contains three syntactically valid key/value 818 pairs. (The meaning of these key/value pairs, if any, would depend 819 on the definitions pertaining to the service in question that is 820 using them.) 822 ------------------------------------------------------- 823 | 0x09 | key=value | 0x08 | paper=A4 | 0x07 | passreq | 824 ------------------------------------------------------- 826 6.7 Version Tag 828 It is recommended that authors defining DNS-SD profiles include an 829 attribute of the form "txtvers=xxx" in their definition, and require 830 it to be the first key/value pair in the TXT record. This 831 information in the TXT record can be useful to help clients maintain 832 backwards compatibility with older implementations if it becomes 833 necessary to change or update the specification over time. Even if 834 the profile author doesn't anticipate the need for any future 835 incompatible changes, having a version number in the specification 836 provides useful insurance should incompatible changes become 837 unavoidable. Clients SHOULD ignore TXT records with a txtvers number 838 higher (or lower) than the version(s) they know how to interpret. 840 Note that the version number in the txtvers tag describes the version 841 of the TXT record specification being used to create this TXT record, 842 not the version of the application protocol that will be used if the 843 client subsequently decides to contact that service. Ideally, every 844 DNS-SD TXT record specification starts at txtvers=1 and stays that 845 way forever. Improvements can be made by defining new keys that older 846 clients silently ignore. The only reason to increment the version 847 number is if the old specification is subsequently found to be so 848 horribly broken that there's no way to do a compatible forward 849 revision, so the txtvers number has to be incremented to tell all the 850 old clients they should just not even try to understand this new TXT 851 record. 853 If there is a need to indicate which version number(s) of the 854 application protocol the service implements, the recommended key 855 for this is "protovers". 857 7. Application Protocol Names 859 The portion of a Service Instance Name consists of a pair 860 of DNS labels, following the established convention for SRV records 861 [RFC 2782], namely: the first label of the pair is an underscore 862 character followed by the Application Protocol Name, and the second 863 label is either "_tcp" or "_udp". 865 Application Protocol Names may be no more than fourteen characters 866 (not counting the mandatory underscore), conforming to normal DNS 867 host name rules: Only lower-case letters, digits, and hyphens; must 868 begin and end with lower-case letter or digit. 870 Wise selection of an Application Protocol Name is very important, 871 and the choice is not always as obvious as it may appear. 873 In many cases, the Application Protocol Name merely names and refers 874 to the on-the-wire message format and semantics being used. FTP is 875 "ftp", IPP printing is "ipp", and so on. 877 However, it is common to "borrow" an existing protocol and repurpose 878 it for a new task. This is entirely sensible and sound engineering 879 practice, but that doesn't mean that the new protocol is providing 880 the same semantic service as the old one, even if it borrows the same 881 message formats. For example, the local network music sharing 882 protocol implemented by iTunes on Macintosh and Windows is little 883 more than "HTTP GET" commands. However, that does *not* mean that it 884 is sensible or useful to try to access one of these music servers by 885 connecting to it with a standard web browser. Consequently, the 886 DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp" 887 (Digital Audio Access Protocol), not "_http._tcp". Advertising 888 "_http._tcp" service would cause iTunes servers to show up in 889 conventional web browsers (Safari, Camino, OmniWeb, Internet 890 Explorer, Firefox, Chrome, etc.) which is of little use since it 891 offers no pages containing human-readable content. Similarly, if 892 iTunes were to browse for "_http._tcp" service, that would cause it 893 to find generic web servers, such as the embedded web servers in 894 devices like printers, which is of little use since printers 895 generally don't have much music to offer. 897 Similarly, NFS is built on top of SUN RPC, but that doesn't mean it 898 makes sense for an NFS server to advertise that it provides "SUN RPC" 899 service. Likewise, Microsoft SMB file service is built on top of 900 Netbios running over IP, but that doesn't mean it makes sense for 901 an SMB file server to advertise that it provides "Netbios-over-IP" 902 service. The DNS-SD name of a service needs to encapsulate both the 903 "what" (semantics) and the "how" (protocol implementation) of the 904 service, since knowledge of both is necessary for a client to 905 usefully use the service. Merely advertising that a service was 906 built on top of SUN RPC is no use if the client has no idea what 907 the service actually does. 909 Another common question is to ask whether the service type advertised 910 by iTunes should be "_daap._http._tcp." This would also be incorrect. 911 Similarly, a protocol designer implementing a network service that 912 happens to use Simple Object Access Protocol [SOAP] should not feel 913 compelled to have "_soap" appear somewhere in the Application 914 Protocol Name. Part of the confusion here is that the presence of 915 "_tcp" or "_udp" in the portion of a Service Instance Name 916 has led people to assume that the structure of a service name has to 917 reflect the internal structure of how the protocol was implemented. 918 This is not correct. All that is required is that the service be 919 identified by a unique Application Protocol Name. Making the 920 Application Protocol Name at least marginally descriptive of 921 what the service does is desirable, though not essential. 923 The "_tcp" or "_udp" should be regarded as little more than 924 boilerplate text, and care should be taken not to attach too much 925 importance to it. Some might argue that the "_tcp" or "_udp" should 926 not be there at all, but this format is defined by RFC 2782, and 927 this document does not propose to change that. In addition, the 928 presence of "_tcp" has the useful side-effect that it provides a 929 convenient delegation point to hand off responsibility for service 930 discovery to a different DNS server, if so desired. 932 7.1. Selective Instance Enumeration 934 This document does not attempt to define an arbitrary query language 935 for service discovery, nor do we believe one is necessary. 937 However, there are some circumstances where narrowing the list of 938 results may be useful. For example, many network printers offer a 939 web-based user interface, for management and administration, using 940 HTML/HTTP. A web browser wanting to discover all advertised web pages 941 on the local network issues a query for "_http._tcp.". 942 On the other hand, there are cases where users wish to manage 943 printers specifically, not to discover web pages in general, and it 944 would be good accommodate this. In this case we define the "_printer" 945 subtype of "_http._tcp", and the web browser issues a query for 946 "_printer._sub._http._tcp.", to discover only pages 947 advertised using that subtype. 949 The Safari web browser on Mac OS X Leopard uses subtypes in this way. 950 This can be seen by using the commands below on Mac OS X (or on 951 Windows with Bonjour for Windows installed) to advertise two "fake" 952 services. The service instance "A web page" is displayed in the 953 "Webpages" section of Safari's Bonjour list, while the instance 954 "A printer's web page" is displayed in the "Printers" section. 956 dns-sd -R "A web page" _http._tcp local 123 957 dns-sd -R "A printer's web page" _http._tcp,_printer local 123 959 Note that the advertised web page's Service Instance Name is 960 unchanged by the use of subtypes -- it is still something of the form 961 "The Server._http._tcp.example.com." The subdomain in which HTTP 962 server SRV records are registered defines the namespace within which 963 HTTP server names are unique. Additional subtypes (e.g. "_printer") 964 of the basic service type (e.g. "_http._tcp") serve to narrow the 965 list of results, not to create more namespace. 967 Subtypes are appropriate when it is desirable for different kinds of 968 clients to be able to browse for services at two levels of 969 granularity. In the example above, we describe two classes of HTTP 970 clients: general web browsing clients that are interested in all web 971 pages, and specific printer management tools that would like to 972 discover only web UI pages advertised by printers. The set of HTTP 973 servers on the network is the same in both cases; the difference is 974 that some clients want to discover all of them, whereas other clients 975 only want to find the subset of HTTP servers whose purpose is printer 976 administration. 978 Subtypes are only appropriate in two-level scenarios such as this 979 one, where some clients want to find the full set of services of a 980 given type, and at the same time other clients only want to find some 981 subset. Generally speaking, if there is no client that wants to find 982 the entire set, then it's neither necessary nor desirable to use the 983 subtype mechanism. If all clients are browsing for some particular 984 subtype, and no client exists that browses for the parent type, then 985 an Application Protocol Name representing the logical service should 986 be defined, and software should simply advertise and browse for that 987 particular service type directly. In particular, just because a 988 particular network service happens to be implemented in terms of some 989 other underlying protocol, like HTTP, Sun RPC, or SOAP, doesn't mean 990 that it's sensible for that service to be defined as a subtype of 991 "_http", "_sunrpc", or "_soap". That would only be useful if there 992 were some class of client for which it is sensible to say, "I want to 993 discover a service on the network, and I don't care what it does, as 994 long as it does it using the SOAP XML RPC mechanism." 996 As with the TXT record key/value pairs, the list of possible 997 subtypes, if any, are defined and specified separately for each basic 998 service type. 1000 7.2 Service Name Length Limits 1002 As specified above, application protocol names are allowed to be up 1003 to fourteen characters long. The reason for this limit is to leave 1004 as many bytes of the domain name as possible available for use 1005 by both the network administrator (choosing service domain names) 1006 and the end user (choosing instance names). 1008 A domain name may be up to 256 bytes long, including the final 1009 terminating root label at the end. Domain names used by DNS-SD 1010 take the following forms: 1012 ._tcp... 1013 .._tcp... 1014 ._sub.._tcp... 1016 The first example shows the name used for PTR queries. The second 1017 shows a service instance name, i.e. the name of the service's SRV and 1018 TXT records. The third shows a subtype browsing name, i.e. the name 1019 of a PTR record pointing to service instance names (see "Selective 1020 Instance Enumeration"). 1022 The instance name may be up to 63 bytes. Including the 1023 length byte used by the DNS format when the name is stored in a 1024 packet, that makes 64 bytes. 1026 When using subtypes, the subtype identifier is allowed to be up to 1027 63 bytes, plus the length byte, making 64. Including the "_sub" 1028 and its length byte, this makes 69 bytes. 1030 The application protocol name may be up to 14 bytes, plus the 1031 underscore and length byte, making 16. Including the "_udp" or "_tcp" 1032 and its length byte, this makes 21 bytes. 1034 Typically, DNS-SD service records are placed into subdomains of their 1035 own beneath a company's existing domain name. Since these subdomains 1036 are intended to be accessed through graphical user interfaces, not 1037 typed on a command-line, they are frequently long and descriptive. 1038 Including the length byte, the user-visible service domain may be up 1039 to 64 bytes. 1041 The terminating root label at the end counts as one byte. 1043 Of our available 256 bytes, we have now accounted for 69+21+64+1 = 1044 155 bytes. This leaves 101 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 14 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 8. Flagship Naming 1064 In some cases, there may be several network protocols available 1065 which all perform roughly the same logical function. For example, 1066 the printing world has the LPR protocol, and the Internet Printing 1067 Protocol (IPP), both of which cause printed sheets to be emitted 1068 from printers in much the same way. In addition, many printer vendors 1069 send their own proprietary page description language (PDL) data 1070 over a TCP connection to TCP port 9100, herein referred to as the 1071 "pdl-datastream" protocol. In an ideal world we would have only one 1072 network printing protocol, and it would be sufficiently good that no 1073 one felt a compelling need to invent a different one. However, in 1074 practice, multiple legacy protocols do exist, and a service discovery 1075 protocol has to accommodate that. 1077 Many printers implement all three printing protocols: LPR, IPP, and 1078 pdl-datastream. For the benefit of clients that may speak only one of 1079 those protocols, all three are advertised. 1081 However, some clients may implement two, or all three of those 1082 printing protocols. When a client looks for all three service types 1083 on the network, it will find three distinct services -- an LPR 1084 service, an IPP service, and a pdl-datastream service -- all of which 1085 cause printed sheets to be emitted from the same physical printer. 1087 In the case of multiple protocols like this that all perform 1088 effectively the same function, the client should suppress duplicate 1089 names and display each name only once. When the user prints to a 1090 given named printer, the printing client is responsible for choosing 1091 the protocol which will best achieve the desired effect, without, for 1092 example, requiring the user to make a manual choice between LPR and 1093 IPP. 1095 As described so far, this all works very well. However, consider some 1096 future printer that only supports IPP printing, and some other future 1097 printer that only supports pdl-datastream printing. The name spaces 1098 for different service types are intentionally disjoint -- it is 1099 acceptable and desirable to be able to have both a file server called 1100 "Sales Department" and a printer called "Sales Department". However, 1101 it is not desirable, in the common case, to have two different 1102 printers both called "Sales Department", just because those printers 1103 implement different protocols. 1105 To help guard against this, when there are two or more network 1106 protocols which perform roughly the same logical function, one of 1107 the protocols is declared the "flagship" of the fleet of related 1108 protocols. Typically the flagship protocol is the oldest and/or 1109 best-known protocol of the set. 1111 If a device does not implement the flagship protocol, then it instead 1112 creates a placeholder SRV record (priority=0, weight=0, port=0, 1113 target host = hostname of device) with that name. If, when it 1114 attempts to create this SRV record, it finds that a record with the 1115 same name already exists, then it knows that this name is already 1116 taken by some other entity implementing at least one of the protocols 1117 from the fleet, and it must choose another. If no SRV record already 1118 exists, then the act of creating it stakes a claim to that name so 1119 that future devices in the same protocol fleet will detect a conflict 1120 when they try to use it. 1122 Note: When used with Multicast DNS [mDNS], the target host field of 1123 the placeholder SRV record MUST NOT be the empty root label. The SRV 1124 record needs to contain a real target host name in order for the 1125 Multicast DNS conflict detection rules to operate. If two different 1126 devices were to create placeholder SRV records both using a null 1127 target host name (just the root label), then the two SRV records 1128 would be seen to be in agreement so no conflict would be registered. 1130 By defining a common well-known flagship protocol for the class, 1131 future devices that may not even know about each other's protocols 1132 establish a common ground where they can coordinate to verify 1133 uniqueness of names. 1135 No PTR record is created advertising the presence of empty flagship 1136 SRV records, since they do not represent a real service being 1137 advertised. 1139 9. Service Type Enumeration 1141 In general, clients are not interested in finding *every* service on 1142 the network, just the services that the client knows how to talk to. 1144 However, for problem diagnosis and network management tools, it may 1145 be useful for network administrators to find the list of advertised 1146 service types on the network, even if those service names are just 1147 opaque identifiers and not particularly informative in isolation. 1149 For this reason, a special meta-query is defined. A DNS query for PTR 1150 records with the name "_services._dns-sd._udp." yields a list 1151 of PTR records, where the rdata of each PTR record is the two-label 1152 name of a service type, e.g. "_http._tcp." These two-label service 1153 types can then be used to construct subsequent Service Instance 1154 Enumeration PTR queries, in this or others, to discover 1155 a list of instances of that service type. 1157 A Service Type Enumeration PTR record's rdata SHOULD contain just two 1158 labels, without any additional "" suffix. Clients processing 1159 received Service Type Enumeration PTR records with more than two 1160 labels SHOULD interpret the first two labels as a service type and 1161 silently ignore any additional labels in the PTR rdata. 1163 10. Populating the DNS with Information 1165 How a service's PTR, SRV and TXT records make their way into the DNS 1166 is outside the scope of this document. It can happen in a number of 1167 ways, for example: 1169 On some networks, the administrator might manually enter the records 1170 into the name server's configuration file. 1172 A network monitoring tool could output a standard zone file to be 1173 read into a conventional DNS server. For example, a tool that can 1174 find Apple LaserWriters using AppleTalk NBP could find the list 1175 of printers, communicate with each one to find its IP address, 1176 PostScript version, installed options, etc., and then write out a 1177 DNS zone file describing those printers and their capabilities using 1178 DNS resource records. That information would then be available to 1179 DNS-SD clients that don't implement AppleTalk NBP, and don't want to. 1181 IP printers could use Dynamic DNS Update [RFC 2136] to automatically 1182 register their own PTR, SRV and TXT records with the DNS server. 1184 A printer manager device which has knowledge of printers on the 1185 network through some other management protocol could also use Dynamic 1186 DNS Update [RFC 2136]. 1188 Alternatively, a printer manager device could implement enough of 1189 the DNS protocol that it is able to answer DNS queries directly, 1190 and Example Co.'s main DNS server could delegate the 1191 _ipp._tcp.example.com subdomain to the printer manager device. 1193 Zeroconf printers answer Multicast DNS queries on the local link 1194 for appropriate PTR, SRV and TXT names ending with ".local." [mDNS] 1196 11. Relationship to Multicast DNS 1198 DNS-Based Service Discovery is only peripherally related to Multicast 1199 DNS, in that the standard unicast DNS queries used by DNS-SD may also 1200 be performed using multicast when appropriate, which is particularly 1201 beneficial in Zeroconf environments. 1203 12. Discovery of Browsing and Registration Domains (Domain Enumeration) 1205 One of the motivations for DNS-Based Service Discovery is so that 1206 when a visiting client (e.g. a laptop computer) arrives at a new 1207 network, it can discover what services are available on that network 1208 without manual configuration. This logic (discovering services 1209 without manual configuration) also applies to discovering the domains 1210 in which services are registered without requiring manual 1211 configuration. 1213 This discovery is performed recursively, using Unicast or Multicast 1214 DNS. Five special RR names are reserved for this purpose: 1216 b._dns-sd._udp.. 1217 db._dns-sd._udp.. 1218 r._dns-sd._udp.. 1219 dr._dns-sd._udp.. 1220 lb._dns-sd._udp.. 1222 By performing PTR queries for these names, a client can learn, 1223 respectively: 1225 o A list of domains recommended for browsing 1227 o A single recommended default domain for browsing 1229 o A list of domains recommended for registering services using 1230 Dynamic Update 1232 o A single recommended default domain for registering services. 1234 o The final query shown yields the "legacy browsing" or "automatic 1235 browsing" domain. Sophisticated client applications that care to 1236 present choices of domain to the user, use the answers learned 1237 from the previous four queries to discover the domains to present. 1238 In contrast, many current applications browse without specifying 1239 an explicit domain, allowing the operating system to automatically 1240 select an appropriate domain on their behalf. It is for this class 1241 of application that the "automatic browsing" query is provided, to 1242 allow the network administrator to communicate to the client 1243 operating systems which domain(s) should be used automatically for 1244 these applications. 1246 These domains are purely advisory. The client or user is free to 1247 browse and/or register services in any domains. The purpose of these 1248 special queries is to allow software to create a user-interface that 1249 displays a useful list of suggested choices to the user, from which 1250 the user may make a suitable selection, or ignore the offered 1251 suggestions and manually enter their own choice. 1253 The part of the Domain Enumeration query name may be 1254 "local." (meaning "perform the query using link-local multicast) or 1255 it may be learned through some other mechanism, such as the DHCP 1256 "Domain" option (option code 15) [RFC 2132] or the DHCP "Domain 1257 Search" option (option code 119) [RFC 3397]. 1259 The part of the name may also be derived from the host's IP 1260 address. The host takes its IP address, and calculates the logical 1261 AND of that address and its subnet mask, to derive the 'base' address 1262 of the subnet. It then constructs the conventional DNS "reverse 1263 mapping" name corresponding to that base address, and uses that 1264 as the part of the name for the queries described above. 1265 For example, if a host has address 192.168.12.34, with subnet mask 1266 255.255.0.0, then the 'base' address of the subnet is 192.168.0.0, 1267 and to discover the recommended automatic browsing domain for devices 1268 on this subnet, the host issues a DNS PTR query for the name 1269 "lb._dns-sd._udp.0.0.168.192.in-addr.arpa." 1271 Sophisticated clients may perform domain enumeration queries both in 1272 "local." and in one or more unicast domains, and then present the 1273 user with an aggregate result, combining the information received 1274 from all sources. 1276 13. DNS Additional Record Generation 1278 DNS has an efficiency feature whereby a DNS server may place 1279 additional records in the Additional Section of the DNS Message. 1280 These additional records are typically records that the client did 1281 not explicitly request, but the server has reasonable grounds to 1282 expect that the client might request them shortly. 1284 This section recommends which additional records should be generated 1285 to improve network efficiency for both unicast and multicast DNS-SD 1286 responses. 1288 13.1 PTR Records 1290 When including a DNS-SD PTR record in a response packet, the 1291 server/responder SHOULD include the following additional records: 1293 o The SRV record(s) named in the PTR rdata. 1294 o The TXT record(s) named in the PTR rdata. 1295 o All address records (type "A" and "AAAA") named in the SRV rdata. 1297 13.2 SRV Records 1299 When including an SRV record in a response packet, the 1300 server/responder SHOULD include the following additional records: 1302 o All address records (type "A" and "AAAA") named in the SRV rdata. 1304 13.3 TXT Records 1306 When including a TXT record in a response packet, no additional 1307 records are required. 1309 13.4 Other Record Types 1311 In response to address queries, or other record types, no additional 1312 records are recommended by this document. 1314 14. Comparison with Alternative Service Discovery Protocols 1316 Over the years there have been many proposed ways to do network 1317 service discovery with IP, but none achieved ubiquity in the 1318 marketplace. Certainly none has achieved anything close to the 1319 ubiquity of today's deployment of DNS servers, clients, and other 1320 infrastructure. 1322 The advantage of using DNS as the basis for service discovery is 1323 that it makes use of those existing servers, clients, protocols, 1324 infrastructure, and expertise. Existing network analyzer tools 1325 already know how to decode and display DNS packets for network 1326 debugging. 1328 For ad hoc networks such as Zeroconf environments, peer-to-peer 1329 multicast protocols are appropriate. Using DNS-SD running over 1330 Multicast DNS [mDNS] provides zero-configuration ad hoc service 1331 discovery, while maintaining the DNS-SD semantics and record types 1332 described here. 1334 In larger networks, a high volume of enterprise-wide IP multicast 1335 traffic may not be desirable, so any credible service discovery 1336 protocol intended for larger networks has to provide some facility to 1337 aggregate registrations and lookups at a central server (or servers) 1338 instead of working exclusively using multicast. This requires some 1339 service discovery aggregation server software to be written, 1340 debugged, deployed, and maintained. This also requires some service 1341 discovery registration protocol to be implemented and deployed for 1342 clients to register with the central aggregation server. Virtually 1343 every company with an IP network already runs a DNS server, and DNS 1344 already has a dynamic registration protocol [RFC 2136]. Given that 1345 virtually every company already has to operate and maintain a DNS 1346 server anyway, it makes sense to take advantage of this instead of 1347 also having to learn, operate and maintain a different service 1348 registration server. It should be stressed again that using the 1349 same software and protocols doesn't necessarily mean using the same 1350 physical piece of hardware. The DNS-SD service discovery functions 1351 do not have to be provided by the same piece of hardware that 1352 is currently providing the company's DNS name service. The 1353 "_tcp." subdomain may be delegated to a different piece of 1354 hardware. However, even when the DNS-SD service is being provided 1355 by a different piece of hardware, it is still the same familiar DNS 1356 server software that is running, with the same configuration file 1357 syntax, the same log file format, and so forth. 1359 Service discovery needs to be able to provide appropriate security. 1360 DNS already has existing mechanisms for security [RFC 2535]. 1362 In summary: 1364 Service discovery requires a central aggregation server. 1365 DNS already has one: It's called a DNS server. 1367 Service discovery requires a service registration protocol. 1368 DNS already has one: It's called DNS Dynamic Update. 1370 Service discovery requires a query protocol. 1371 DNS already has one: It's called DNS. 1373 Service discovery requires security mechanisms. 1374 DNS already has security mechanisms: DNSSEC. 1376 Service discovery requires a multicast mode for ad hoc networks. 1377 Using DNS-SD in conjunction with Multicast DNS provides this, 1378 using peer-to-peer multicast instead of a DNS server. 1380 It makes more sense to use the existing software that every network 1381 needs already, instead of deploying an entire parallel system just 1382 for service discovery. 1384 15. Working Examples 1386 The following examples were prepared using standard unmodified 1387 nslookup and standard unmodified BIND running on GNU/Linux. 1389 Note: In real products, this information is obtained and presented to 1390 the user using graphical network browser software, not command-line 1391 tools, but if you wish you can try these examples for yourself as you 1392 read along, using the nslookup command already available on most Unix 1393 machines. 1395 15.1 Question: What web pages are being advertised from dns-sd.org? 1397 nslookup -q=ptr _http._tcp.dns-sd.org. 1398 _http._tcp.dns-sd.org 1399 name = Zeroconf._http._tcp.dns-sd.org 1400 _http._tcp.dns-sd.org 1401 name = Multicast\032DNS._http._tcp.dns-sd.org 1402 _http._tcp.dns-sd.org 1403 name = DNS\032Service\032Discovery._http._tcp.dns-sd.org 1404 _http._tcp.dns-sd.org 1405 name = Stuart's\032Printer._http._tcp.dns-sd.org 1407 Answer: There are four, called "Zeroconf", "Multicast DNS", 1408 "DNS Service Discovery" and "Stuart's Printer". 1410 Note that nslookup escapes spaces as "\032" for display purposes, 1411 but a graphical DNS-SD browser does not. 1413 15.2 Question: What printer configuration web pages are there? 1415 nslookup -q=ptr _printer._sub._http._tcp.dns-sd.org 1416 _printer._sub._http._tcp.dns-sd.org 1417 name = Stuart's\032Printer._http._tcp.dns-sd.org 1419 Answer: "Stuart's Printer" is the web configuration UI of a network 1420 printer. 1422 15.3 Question: How do I access "DNS Service Discovery"? 1424 nslookup -q=any "DNS\032Service\032Discovery._http._tcp.dns-sd.org." 1425 DNS\032Service\032Discovery._http._tcp.dns-sd.org 1426 priority = 0, weight = 0, port = 80, host = dns-sd.org 1427 DNS\032Service\032Discovery._http._tcp.dns-sd.org 1428 text = "path=/" 1429 dns-sd.org nameserver = ns1.bolo.net 1430 dns-sd.org internet address = 64.142.82.154 1431 ns1.bolo.net internet address = 64.142.82.152 1433 Answer: You need to connect to dns-sd.org port 80, path "/". 1434 The address for dns-sd.org is also given (64.142.82.154). 1436 16. User Interface Considerations 1438 DNS-Based Service Discovery was designed by first giving careful 1439 consideration to what constitutes a good user experience for service 1440 discovery, and then designing a protocol with the features necessary 1441 to enable that good user experience. This section covers two issues 1442 in particular: Choice of factory-default names (and automatic 1443 renaming behavior) for devices advertising services, and the 1444 "continuous live update" user-experience model for clients 1445 browsing to discover services. 1447 16.1 Service Advertising User-Interface Considerations 1449 When a DNS-SD service is advertised using Multicast DNS [mDNS], 1450 automatic name conflict and resolution will occur if there is already 1451 another service of the same type advertising with the same name. 1452 As described in the Multicast DNS specification [mDNS], upon a 1453 conflict, the service should: 1455 1. Automatically select a new name (typically by appending 1456 or incrementing a digit at the end of the name), 1457 2. try advertising with the new name, and 1458 3. upon success, record the new name in persistent storage. 1460 This renaming behavior is very important, because it is the key 1461 to providing user-friendly service names in the out-of-the-box 1462 factory-default configuration. Some product developers may not 1463 have realized this, because there are some products today where 1464 the factory-default name is distinctly unfriendly, containing 1465 random-looking strings of characters, like the device's Ethernet 1466 address in hexadecimal. This is unnecessary, and undesirable, because 1467 the point of the user-visible name is that it should be friendly and 1468 useful to human users. If the name is not unique on the local network 1469 the protocol will remedy this as necessary. It is ironic that many 1470 of the devices with this mistake are network printers, given that 1471 these same printers also simultaneously support AppleTalk-over- 1472 Ethernet, with nice user-friendly default names (and automatic 1473 conflict detection and renaming). Examples of good factory-default 1474 names are as follows: 1476 Brother 5070N 1477 Canon W2200 [ Apologies to makers of ] 1478 HP LaserJet 4600 [ DNS-SD/mDNS printers ] 1479 Lexmark W840 [ not listed. Email ] 1480 Okidata C5300 [ the authors and we'll ] 1481 Ricoh Aficio CL7100 [ add you to the list. ] 1482 Xerox Phaser 6200DX 1484 To make the case for why adding long ugly serial numbers to 1485 the end of names is neither necessary nor desirable, consider 1486 the cases where the user has (a) only one network printer, 1487 (b) two network printers, and (c) many network printers. 1489 (a) In the case where the user has only one network printer, a simple 1490 name like (to use a vendor-neutral example) "Printer" is more 1491 user-friendly than an ugly name like "Printer 0001E68C74FB". 1492 Appending ugly hexadecimal goop to the end of the name to make 1493 sure the name is unique is irrelevant to a user who only has one 1494 printer anyway. 1496 (b) In the case where the user gets a second network printer, 1497 having it detect that the name "Printer" is already in use 1498 and automatically instead name itself "Printer (2)" provides a 1499 good user experience. For the users, remembering that the old 1500 printer is "Printer" and the new one is "Printer (2)" is easy 1501 and intuitive. Seeing two printers called "Printer 0001E68C74FB" 1502 and "Printer 00306EC3FD1C" is a lot less helpful. 1504 (c) In the case of a network with ten network printers, seeing a 1505 list of ten names all of the form "Printer xxxxxxxxxxxx" has 1506 effectively taken what was supposed to be a list of user-friendly 1507 rich-text names (supporting mixed case, spaces, punctuation, 1508 non-Roman characters and other symbols) and turned it into 1509 just about the worst user-interface imaginable: a list of 1510 incomprehensible random-looking strings of letters and digits. 1511 In a network with a lot of printers, it would be desirable for 1512 the people setting up the printers to take a moment to give each 1513 one a descriptive name, but in the event they don't, presenting 1514 the users with a list of sequentially-numbered printers is a much 1515 more desirable default user experience than showing a list of raw 1516 Ethernet addresses. 1518 16.2 Client Browsing User-Interface Considerations 1520 Of particular concern in the design of DNS-SD, particularly when 1521 used in conjunction with ad hoc Multicast DNS, was the dynamic nature 1522 of service discovery in a changing network environment. Other service 1523 discovery protocols seem to have been designed with an implicit 1524 unstated assumption that the usage model is: 1526 (a) client calls the service discovery code 1527 (b) service discovery code instantly gets list of discovered 1528 instances at a particular moment in time, and then 1529 (c) client displays list for user to select from 1531 Superficially this usage model seems reasonable, but the problem is 1532 that it's too optimistic. It only considers the success case, where 1533 the user immediately finds the service instance they're looking for. 1535 In the case where the user is looking for (say) a particular printer, 1536 and that printer's not turned on or not connected, the user first has 1537 to attempt to remedy the problem, and then has to click a "refresh" 1538 button to retry the service discovery to find out whether they were 1539 successful. Because nothing happens instantaneously in networking, 1540 and packets can be lost, necessitating some number of 1541 retransmissions, a service discovery search is not instantaneous and 1542 typically takes a few seconds. A fairly typical user experience is: 1544 (a) display an empty window, 1545 (b) display some animation like a searchlight 1546 sweeping back and forth for ten seconds, and then 1547 (c) at the end of the ten-second search, display 1548 a static list showing what was discovered. 1550 Every time the user clicks the "refresh" button they have to endure 1551 another ten-second wait, and every time the discovered list is 1552 finally shown at the end of the ten-second wait, the moment it's 1553 displayed on the screen it's already beginning to get stale and 1554 out-of-date. 1556 The service discovery user experience that the DNS-SD designers had 1557 in mind has some rather different properties: 1559 1. Displaying a list of discovered services should be effectively 1560 instantaneous -- i.e. typically 0.1 seconds, not 10 seconds. 1562 2. The list of discovered services should not be getting stale 1563 and out-of-date from the moment it's displayed. The list 1564 should be 'live' and should continue to update as new services 1565 are discovered. Because of the delays, packet losses, and 1566 retransmissions inherent in networking, it is to be expected 1567 that sometimes, after the initial list is displayed showing 1568 the majority of discovered services, a few remaining stragglers 1569 may continue to trickle in during the subsequent few seconds. 1570 Even after this initial stable list has been built and displayed, 1571 the list should remain 'live' and should continue to update. 1572 At any future time, be it minutes, hours, or even days later, 1573 if a new service of the desired type is discovered, it should be 1574 displayed in the list automatically, without the user having to 1575 click a "refresh" button or take any other explicit action to 1576 update the display. 1578 3. With users getting to be in the habit of leaving service discovery 1579 windows open, and coming to expect to be able to rely on them 1580 to show a continuous 'live' view of current network reality, 1581 this creates a new requirement for us: deletion of stale services. 1582 When a service discovery list shows just a static snapshot at a 1583 moment in time, then the situation is simple: either a service was 1584 discovered and appears in the list, or it was not, and does not. 1585 However, when our list is live and updates continuously with the 1586 discovery of new services, then this implies the corollary: when 1587 a service goes away, it needs to *disappear* from the service 1588 discovery list. Otherwise, the result would be unacceptable: the 1589 service discovery list would simply grow monotonically over time, 1590 and would require a periodic "refresh" (or complete dismissal and 1591 recreation) to clear out old stale data. 1593 4. With users getting to be in the habit of leaving service discovery 1594 windows open, these windows need to update not only in response 1595 to services coming and going, but also in response to changes 1596 in configuration and connectivity of the client machine itself. 1597 For example, if a user opens a service discovery window when no 1598 Ethernet cable is connected to the client machine, and the window 1599 appears empty with no discovered services, then when the user 1600 connects the cable the window should automatically populate with 1601 discovered services without requiring any explicit user action. 1602 If the user disconnects the Ethernet cable, all the services 1603 discovered via that network interface should automatically 1604 disappear. If the user switches from one 802.11 [IEEE W] wireless 1605 base station to another, the service discovery window should 1606 automatically update to remove all the services discovered via the 1607 old wireless base station, and add all the services discovered via 1608 the new one. 1610 If these requirements seem to be setting an arbitrary and 1611 unreasonably high standard for service discovery, bear in mind that 1612 while it may have seemed that way to some, back in the 1990s when 1613 these ideas were first proposed, in the years since then Apple and 1614 other companies have shipped multiple implementations of DNS-SD/mDNS 1615 that meet and exceed these requirements. In the years since Apple 1616 shipped Mac OS X 10.2 Jaguar with the Open Source mDNSResponder 1617 daemon, this service discovery "live browsing" paradigm has been 1618 adopted and implemented in a wide range of Apple and third-party 1619 applications, including printer discovery, Safari discovery of 1620 devices with embedded web servers (for status and configuration), 1621 iTunes music sharing, iPhoto photo sharing, the iChat Bonjour buddy 1622 list, iPhone remote control of Apple TV, SubEthaEdit multi-user 1623 document editing, etc. 1625 With so many different applications demonstrating that the "live 1626 browsing" paradigm is clearly achievable, these four requirements 1627 should not be regarded as idealistic unattainable goals, but 1628 instead as the bare minimum baseline functionality that any 1629 credible service discovery protocol needs to achieve. 1631 17. IPv6 Considerations 1633 IPv6 has no significant differences, except that the address of the 1634 SRV record's target host is given by the appropriate IPv6 "AAAA" 1635 address records instead of the IPv4 "A" record. 1637 18. Security Considerations 1639 DNSSEC [RFC 2535] should be used where the authenticity of 1640 information is important. Since DNS-SD is just a naming and usage 1641 convention for records in the existing DNS system, it has no specific 1642 additional security requirements over and above those that already 1643 apply to DNS queries and DNS updates. 1645 19. IANA Considerations 1647 This protocol builds on DNS SRV records [RFC 2782], and similarly 1648 requires IANA to assign unique application protocol names. 1649 Unfortunately, the "IANA Considerations" section of RFC 2782 says 1650 simply, "The IANA has assigned RR type value 33 to the SRV RR. 1651 No other IANA services are required by this document." 1652 Due to this oversight, IANA is currently prevented from carrying 1653 out the necessary function of assigning these unique identifiers. 1655 This document specifies the following IANA allocation policy for 1656 unique application protocol names: 1658 Allowable names: 1659 * Must be no more than fourteen characters long 1660 * Must consist only of: 1661 - lower-case letters 'a' - 'z' 1662 - digits '0' - '9' 1663 - the hyphen character '-' 1664 * Must begin and end with a lower-case letter or digit. 1665 * Must not already be assigned to some other protocol in the 1666 existing IANA "list of assigned application protocol names 1667 and port numbers" [ports]. 1669 These identifiers are allocated on a First Come First Served basis. 1670 In the event of abuse (e.g. automated mass registrations, etc.), 1671 the policy may be changed without notice to Expert Review [RFC 2434]. 1673 The textual nature of service/protocol names means that there are 1674 almost infinitely many more of them available than the finite set of 1675 65535 possible port numbers. This means that developers can produce 1676 experimental implementations using unregistered service names with 1677 little chance of accidental collision, providing service names are 1678 chosen with appropriate care. However, this document strongly 1679 advocates that on or before the date a product ships, developers 1680 should properly register their service names. 1682 Some developers have expressed concern that publicly registering 1683 their service names (and port numbers today) with IANA before a 1684 product ships may give away clues about that product to competitors. 1685 For this reason, IANA should consider allowing service name 1686 applications to remain secret for some period of time, much as US 1687 patent applications remain secret for two years after the date of 1688 filing. 1690 This proposed IANA allocation policy is not in effect until this 1691 document is published as an RFC. In the meantime, unique application 1692 protocol names may be registered according to the instructions at 1693 . As of August 2008, there 1694 are over 400 application protocols in currently shipping products 1695 that have been so registered as using DNS-SD for service discovery. 1697 20. Acknowledgments 1699 The concepts described in this document have been explored, developed 1700 and implemented with help from Richard Brown, Erik Guttman, Paul 1701 Vixie, and Bill Woodcock. 1703 Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, 1704 Rory McGuire, Roger Pantos and Kiren Sekar for their significant 1705 contributions. 1707 21. Deployment History 1709 The first implementations of DNS-Based Service Discovery and 1710 Multicast DNS were initially developed during the late 1990s, 1711 but the event that put them into the media spotlight was Steve Jobs 1712 demonstrating it live on stage in his keynote presentation opening 1713 Apple's annual Worldwide Developers Conference in May 2002, and 1714 announcing Apple's adoption of the technology throughout its hardware 1715 and software product line. Three months later, in August 2002, Apple 1716 shipped Mac OS X 10.2 Jaguar, and millions of end-users got their 1717 first exposure to Zero Configuration Networking with DNS-SD/mDNS in 1718 applications like Safari, iChat, and printer setup. A month later, 1719 in September 2002, Apple released the entire source code for the mDNS 1720 Responder daemon as Open Source, with code not just for Mac OS X, 1721 but for a range of other platforms too, including Windows, VxWorks, 1722 Linux, Solaris, FreeBSD, etc. Early the following year, 2003, Apple 1723 shipped iTunes 4.0, with DNS-SD/mDNS music sharing. 1725 Many hardware makers were quick to see the benefits of Zero 1726 Configuration Networking. Printer makers especially were enthusiastic 1727 early adopters, and within a year every major printer manufacturer 1728 was shipping DNS-SD/mDNS-enabled network printers. If you've bought 1729 any network printer at all in the last few years, it probably 1730 supports DNS-SD/mDNS, even if you didn't know that at the time. 1732 For Mac OS X users, telling if you have DNS-SD/mDNS printers on your 1733 network is easy because they automatically appear in the "Bonjour" 1734 submenu in the "Print" dialog of every Mac application. Microsoft 1735 Windows users can get a similar experience by installing Bonjour for 1736 Windows (takes about 90 seconds, no restart required) and running the 1737 Bonjour for Windows Printer Setup Wizard [B4W]. 1739 The Open Source community has produced several independent 1740 implementations of DNS-Based Service Discovery and Multicast DNS, 1741 some in C like Apple's mDNSResponder daemon, and others in a variety 1742 of different languages including Java, Python, Perl, and C#/Mono. 1744 22. Copyright Notice 1746 Copyright (C) The IETF Trust (2008). 1748 This document is subject to the rights, licenses and restrictions 1749 contained in BCP 78, and except as set forth therein, the authors 1750 retain all their rights. 1752 This document and the information contained herein are provided on an 1753 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1754 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1755 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1756 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1757 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1758 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1760 23. Intellectual Property Notice 1762 The IETF takes no position regarding the validity or scope of any 1763 Intellectual Property Rights or other rights that might be claimed to 1764 pertain to the implementation or use of the technology described in 1765 this document or the extent to which any license under such rights 1766 might or might not be available; nor does it represent that it has 1767 made any independent effort to identify any such rights. Information 1768 on the procedures with respect to rights in RFC documents can be 1769 found in BCP 78 and BCP 79. 1771 Copies of IPR disclosures made to the IETF Secretariat and any 1772 assurances of licenses to be made available, or the result of an 1773 attempt made to obtain a general license or permission for the use of 1774 such proprietary rights by implementers or users of this 1775 specification can be obtained from the IETF on-line IPR repository at 1776 http://www.ietf.org/ipr. 1778 The IETF invites any interested party to bring to its attention any 1779 copyrights, patents or patent applications, or other proprietary 1780 rights that may cover technology that may be required to implement 1781 this standard. Please address the information to the IETF at 1782 ietf-ipr@ietf.org. 1784 24. Normative References 1786 [ports] IANA list of assigned application protocol names and port 1787 numbers 1789 [RFC 1033] Lottor, M., "Domain Administrators Operations Guide", 1790 RFC 1033, November 1987. 1792 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 1793 Facilities", STD 13, RFC 1034, November 1987. 1795 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 1796 Specifications", STD 13, RFC 1035, November 1987. 1798 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1799 Requirement Levels", RFC 2119, March 1997. 1801 [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the 1802 location of services (DNS SRV)", RFC 2782, February 2000. 1804 [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO 1805 10646", RFC 3629, November 2003. 1807 [UAX15] "Unicode Normalization Forms" 1808 http://www.unicode.org/reports/tr15/ 1810 25. Informative References 1812 [AFP] Apple Filing Protocol 1815 [B4W] Bonjour for Windows 1817 [IEEE W] 1819 [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS", 1820 Internet-Draft (work in progress), 1821 draft-cheshire-dnsext-multicastdns-07.txt, September 2008. 1823 [ATalk] Cheshire, S., and M. Krochmal, 1824 "Requirements for Replacing AppleTalk", 1825 Internet-Draft (work in progress), 1826 draft-cheshire-dnsext-nbp-06.txt, September 2008. 1828 [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP 1829 Vendor Extensions", RFC 2132, March 1997. 1831 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 1832 System (DNS UPDATE)", RFC 2136, April 1997. 1834 [RFC 2181] Elz, R., and Bush, R., "Clarifications to the DNS 1835 Specification", RFC 2181, July 1997. 1837 [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing 1838 an IANA Considerations Section in RFCs", RFC 2434, 1839 October 1998. 1841 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", 1842 RFC 2535, March 1999. 1844 [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS) 1845 Dynamic Update", RFC 3007, November 2000. 1847 [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration 1848 Protocol (DHCP) Domain Search Option", RFC 3397, November 1849 2002. 1851 [SOAP] Nilo Mitra, "SOAP Version 1.2 Part 0: Primer", 1852 W3C Proposed Recommendation, 24 June 2003 1853 http://www.w3.org/TR/2003/REC-soap12-part0-20030624 1855 26. Authors' Addresses 1857 Stuart Cheshire 1858 Apple Inc. 1859 1 Infinite Loop 1860 Cupertino 1861 California 95014 1862 USA 1864 Phone: +1 408 974 3207 1865 EMail: cheshire@apple.com 1867 Marc Krochmal 1868 Apple Inc. 1869 1 Infinite Loop 1870 Cupertino 1871 California 95014 1872 USA 1874 Phone: +1 408 974 4368 1875 EMail: marc@apple.com