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