1 Document: draft-cheshire-dnsext-dns-sd-04.txt Stuart Cheshire
2 Internet-Draft Marc Krochmal
3 Category: Standards Track Apple Computer, Inc.
4 Expires 10th February 2007 10th August 2006
6 DNS-Based Service Discovery
8 <draft-cheshire-dnsext-dns-sd-04.txt>
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
16 For the purposes of this document, the term "BCP 79" refers
17 exclusively to RFC 3979, "Intellectual Property Rights in IETF
18 Technology", published March 2005.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/1id-abstracts.html
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html
39 This document describes a convention for naming and structuring DNS
40 resource records. Given a type of service that a client is looking
41 for, and a domain in which the client is looking for that service,
42 this convention allows clients to discover a list of named instances
43 of that desired service, using only standard DNS queries. In short,
44 this is referred to as DNS-based Service Discovery, or DNS-SD.
58 Expires 10th February 2007 Cheshire & Krochmal [Page 1]
60 Internet Draft DNS-Based Service Discovery 10th August 2006
65 1. Introduction...................................................3
66 2. Conventions and Terminology Used in this Document..............4
67 3. Design Goals...................................................4
68 4. Service Instance Enumeration...................................5
69 4.1 Structured Instance Names......................................5
70 4.2 User Interface Presentation....................................7
71 4.3 Internal Handling of Names.....................................7
72 4.4 What You See Is What You Get...................................8
73 4.5 Ordering of Service Instance Name Components...................9
74 5. Service Name Resolution.......................................11
75 6. Data Syntax for DNS-SD TXT Records............................12
76 6.1 General Format Rules for DNS TXT Records......................12
77 6.2 DNS TXT Record Format Rules for use in DNS-SD.................13
78 6.3 DNS-SD TXT Record Size........................................14
79 6.4 Rules for Names in DNS-SD Name/Value Pairs....................14
80 6.5 Rules for Values in DNS-SD Name/Value Pairs...................16
81 6.6 Example TXT Record............................................17
82 6.7 Version Tag...................................................17
83 7. Application Protocol Names....................................18
84 7.1 Selective Instance Enumeration................................19
85 7.2 Service Name Length Limits....................................20
86 8. Flagship Naming...............................................22
87 9. Service Type Enumeration......................................23
88 10. Populating the DNS with Information...........................24
89 11. Relationship to Multicast DNS.................................24
90 12. Discovery of Browsing and Registration Domains................25
91 13. DNS Additional Record Generation..............................26
92 14. Comparison with Alternative Service Discovery Protocols.......27
93 15. Real Examples.................................................29
94 16. User Interface Considerations.................................30
95 16.1 Service Advertising User-Interface Considerations.............30
96 16.2 Client Browsing User-Interface Considerations.................31
97 17. IPv6 Considerations...........................................34
98 18. Security Considerations.......................................34
99 19. IANA Considerations...........................................34
100 20. Acknowledgments...............................................35
101 21. Deployment History............................................35
102 22. Copyright Notice..............................................36
103 23. Normative References..........................................37
104 24. Informative References........................................37
105 25. Authors' Addresses............................................38
116 Expires 10th February 2007 Cheshire & Krochmal [Page 2]
118 Internet Draft DNS-Based Service Discovery 10th August 2006
123 This document describes a convention for naming and structuring DNS
124 resource records. Given a type of service that a client is looking
125 for, and a domain in which the client is looking for that service,
126 this convention allows clients to discover a list of named instances
127 of a that desired service, using only standard DNS queries. In short,
128 this is referred to as DNS-based Service Discovery, or DNS-SD.
130 This document proposes no change to the structure of DNS messages,
131 and no new operation codes, response codes, resource record types,
132 or any other new DNS protocol values. This document simply proposes
133 a convention for how existing resource record types can be named and
134 structured to facilitate service discovery.
136 This proposal is entirely compatible with today's existing unicast
137 DNS server and client software.
139 Note that the DNS-SD service does NOT have to be provided by the same
140 DNS server hardware that is currently providing an organization's
141 conventional host name lookup service (the service we traditionally
142 think of when we say "DNS"). By delegating the "_tcp" subdomain,
143 all the workload related to DNS-SD can be offloaded to a different
144 machine. This flexibility, to handle DNS-SD on the main DNS server,
145 or not, at the network administrator's discretion, is one of the
146 things that makes DNS-SD so compelling.
148 Even when the DNS-SD functions are delegated to a different machine,
149 the benefits of using DNS remain: It is mature technology, well
150 understood, with multiple independent implementations from different
151 vendors, a wide selection of books published on the subject, and an
152 established workforce experienced in its operation. In contrast,
153 adopting some other service discovery technology would require every
154 site in the world to install, learn, configure, operate and maintain
155 some entirely new and unfamiliar server software. Faced with these
156 obstacles, it seems unlikely that any other service discovery
157 technology could hope to compete with the ubiquitous deployment
158 that DNS already enjoys.
160 This proposal is also compatible with (but not dependent on) the
161 proposal outlined in "Multicast DNS" [mDNS].
174 Expires 10th February 2007 Cheshire & Krochmal [Page 3]
176 Internet Draft DNS-Based Service Discovery 10th August 2006
179 2. Conventions and Terminology Used in this Document
181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
183 document are to be interpreted as described in "Key words for use in
184 RFCs to Indicate Requirement Levels" [RFC 2119].
189 A good service discovery protocol needs to have many properties,
190 three of which are mentioned below:
192 (i) The ability to query for services of a certain type in a certain
193 logical domain and receive in response a list of named instances
194 (network browsing, or "Service Instance Enumeration").
196 (ii) Given a particular named instance, the ability to efficiently
197 resolve that instance name to the required information a client needs
198 to actually use the service, i.e. IP address and port number, at the
199 very least (Service Name Resolution).
201 (iii) Instance names should be relatively persistent. If a user
202 selects their default printer from a list of available choices today,
203 then tomorrow they should still be able to print on that printer --
204 even if the IP address and/or port number where the service resides
205 have changed -- without the user (or their software) having to repeat
206 the network browsing step a second time.
208 In addition, if it is to become successful, a service discovery
209 protocol should be so simple to implement that virtually any
210 device capable of implementing IP should not have any trouble
211 implementing the service discovery software as well.
213 These goals are discussed in more detail in the remainder of this
214 document. A more thorough treatment of service discovery requirements
215 may be found in "Requirements for a Protocol to Replace AppleTalk
216 NBP" [NBP]. That document draws upon examples from two decades of
217 operational experience with AppleTalk Name Binding Protocol to
218 develop a list of universal requirements which are broadly
219 applicable to any potential service discovery protocol.
232 Expires 10th February 2007 Cheshire & Krochmal [Page 4]
234 Internet Draft DNS-Based Service Discovery 10th August 2006
237 4. Service Instance Enumeration
239 DNS SRV records [RFC 2782] are useful for locating instances of a
240 particular type of service when all the instances are effectively
241 indistinguishable and provide the same service to the client.
243 For example, SRV records with the (hypothetical) name
244 "_http._tcp.example.com." would allow a client to discover a list of
245 all servers implementing the "_http._tcp" service (i.e. Web servers)
246 for the "example.com." domain. The unstated assumption is that all
247 these servers offer an identical set of Web pages, and it doesn't
248 matter to the client which of the servers it uses, as long as it
249 selects one at random according to the weight and priority rules
250 laid out in RFC 2782.
252 Instances of other kinds of service are less easily interchangeable.
253 If a word processing application were to look up the (hypothetical)
254 SRV record "_ipp._tcp.example.com." to find the list of IPP printers
255 at Example Co., then picking one at random and printing on it would
256 probably not be what the user wanted.
258 The remainder of this section describes how SRV records may be used
259 in a slightly different way to allow a user to discover the names
260 of all available instances of a given type of service, in order to
261 select the particular instance the user desires.
264 4.1 Structured Instance Names
266 This document borrows the logical service naming syntax and semantics
267 from DNS SRV records, but adds one level of indirection. Instead of
268 requesting records of type "SRV" with name "_ipp._tcp.example.com.",
269 the client requests records of type "PTR" (pointer from one name to
270 another in the DNS namespace).
272 In effect, if one thinks of the domain name "_ipp._tcp.example.com."
273 as being analogous to an absolute path to a directory in a file
274 system then the PTR lookup is akin to performing a listing of that
275 directory to find all the files it contains. (Remember that domain
276 names are expressed in reverse order compared to path names: An
277 absolute path name is read from left to right, beginning with a
278 leading slash on the left, and then the top level directory, then
279 the next level directory, and so on. A fully-qualified domain name is
280 read from right to left, beginning with the dot on the right -- the
281 root label -- and then the top level domain to the left of that, and
282 the second level domain to the left of that, and so on. If the fully-
283 qualified domain name "_ipp._tcp.example.com." were expressed as a
284 file system path name, it would be "/com/example/_tcp/_ipp".)
290 Expires 10th February 2007 Cheshire & Krochmal [Page 5]
292 Internet Draft DNS-Based Service Discovery 10th August 2006
295 The result of this PTR lookup for the name "<Service>.<Domain>" is a
296 list of zero or more PTR records giving Service Instance Names of the
299 Service Instance Name = <Instance> . <Service> . <Domain>
301 The <Instance> portion of the Service Instance Name is a single DNS
302 label, containing arbitrary precomposed UTF-8-encoded text [RFC
303 3629]. It is a user-friendly name, meaning that it is allowed to
304 contain any characters, without restriction, including spaces, upper
305 case, lower case, punctuation -- including dots -- accented
306 characters, non-roman text, and anything else that may be represented
307 using UTF-8. DNS recommends guidelines for allowable characters for
308 host names [RFC 1033][RFC 1034][RFC 1035], but Service Instance Names
309 are not host names. Service Instance Names are not intended to ever
310 be typed in by a normal user; the user selects a Service Instance
311 Name by selecting it from a list of choices presented on the screen.
313 Note that just because this protocol supports arbitrary UTF-8-encoded
314 names doesn't mean that any particular user or administrator is
315 obliged to make use of that capability. Any user is free, if they
316 wish, to continue naming their services using only letters, digits
317 and hyphens, with no spaces, capital letters, or other punctuation.
319 DNS labels are currently limited to 63 octets in length. UTF-8
320 encoding can require up to four octets per Unicode character, which
321 means that in the worst case, the <Instance> portion of a name could
322 be limited to fifteen Unicode characters. However, the Unicode
323 characters with longer UTF-8 encodings tend to be the more obscure
324 ones, and tend to be the ones that convey greater meaning per
327 Note that any character in the commonly-used 16-bit Unicode space
328 can be encoded with no more than three octets of UTF-8 encoding. This
329 means that an Instance name can contain up to 21 Kanji characters,
330 which is a sufficiently expressive name for most purposes.
332 The <Service> portion of the Service Instance Name consists of a pair
333 of DNS labels, following the established convention for SRV records
334 [RFC 2782], namely: the first label of the pair is the Application
335 Protocol Name, and the second label is either "_tcp" or "_udp",
336 depending on the transport protocol used by the application.
337 More details are given in Section 7, "Application Protocol Names".
339 The <Domain> portion of the Service Instance Name specifies the DNS
340 subdomain within which the service names are registered. It may be
341 "local", meaning "link-local Multicast DNS" [mDNS], or it may be
342 a conventional unicast DNS domain name, such as "apple.com.",
343 "cs.stanford.edu.", or "eng.us.ibm.com." Because service names are
344 not host names, they are not constrained by the usual rules for host
348 Expires 10th February 2007 Cheshire & Krochmal [Page 6]
350 Internet Draft DNS-Based Service Discovery 10th August 2006
353 names [RFC 1033][RFC 1034][RFC 1035], and rich-text service
354 subdomains are allowed and encouraged, for example:
356 Building 2, 1st Floor.apple.com.
357 Building 2, 2nd Floor.apple.com.
358 Building 2, 3rd Floor.apple.com.
359 Building 2, 4th Floor.apple.com.
361 In addition, because Service Instance Names are not constrained by
362 the limitations of host names, this document recommends that they
363 be stored in the DNS, and communicated over the wire, encoded as
364 straightforward canonical precomposed UTF-8, Unicode Normalization
365 Form C [UAX15]. In cases where the DNS server returns an NXDOMAIN
366 error for the name in question, client software MAY choose to retry
367 the query using "Punycode" [RFC 3492] encoding, if possible.
370 4.2 User Interface Presentation
372 The names resulting from the PTR lookup are presented to the user in
373 a list for the user to select one (or more). Typically only the first
374 label is shown (the user-friendly <Instance> portion of the name). In
375 the common case, the <Service> and <Domain> are already known to the
376 user, these having been provided by the user in the first place, by
377 the act of indicating the service being sought, and the domain in
378 which to look for it. Note: The software handling the response
379 should be careful not to make invalid assumptions though, since it
380 *is* possible, though rare, for a service enumeration in one domain
381 to return the names of services in a different domain. Similarly,
382 when using subtypes (see "Selective Instance Enumeration") the
383 <Service> of the discovered instance my not be exactly the same as
384 the <Service> that was requested.
386 Having chosen the desired named instance, the Service Instance
387 Name may then be used immediately, or saved away in some persistent
388 user-preference data structure for future use, depending on what is
389 appropriate for the application in question.
392 4.3 Internal Handling of Names
394 If the <Instance>, <Service> and <Domain> portions are internally
395 concatenated together into a single string, then care must be taken
396 with the <Instance> portion, since it is allowed to contain any
397 characters, including dots.
399 Any dots in the <Instance> portion should be escaped by preceding
400 them with a backslash ("." becomes "\."). Likewise, any backslashes
401 in the <Instance> portion should also be escaped by preceding them
402 with a backslash ("\" becomes "\\"). Having done this, the three
403 components of the name may be safely concatenated. The backslash-
406 Expires 10th February 2007 Cheshire & Krochmal [Page 7]
408 Internet Draft DNS-Based Service Discovery 10th August 2006
411 escaping allows literal dots in the name (escaped) to be
412 distinguished from label-separator dots (not escaped).
414 The resulting concatenated string may be safely passed to standard
415 DNS APIs like res_query(), which will interpret the string correctly
416 provided it has been escaped correctly, as described here.
419 4.4 What You See Is What You Get
421 Some service discovery protocols decouple the true service identifier
422 from the name presented to the user. The true service identifier used
423 by the protocol is an opaque unique id, often represented using a
424 long string of hexadecimal digits, and should never be seen by the
425 typical user. The name presented to the user is merely one of the
426 ephemeral attributes attached to this opaque identifier.
428 The problem with this approach is that it decouples user perception
431 * What happens if there are two service instances, with different
432 unique ids, but they have inadvertently been given the same
433 user-visible name? If two instances appear in an on-screen list
434 with the same name, how does the user know which is which?
436 * Suppose a printer breaks down, and the user replaces it with
437 another printer of the same make and model, and configures the
438 new printer with the exact same name as the one being replaced:
439 "Stuart's Printer". Now, when the user tries to print, the
440 on-screen print dialog tells them that their selected default
441 printer is "Stuart's Printer". When they browse the network to see
442 what is there, they see a printer called "Stuart's Printer", yet
443 when the user tries to print, they are told that the printer
444 "Stuart's Printer" can't be found. The hidden internal unique id
445 that the software is trying to find on the network doesn't match
446 the hidden internal unique id of the new printer, even though its
447 apparent "name" and its logical purpose for being there are the
448 same. To remedy this, the user typically has to delete the print
449 queue they have created, and then create a new (apparently
450 identical) queue for the new printer, so that the new queue will
451 contain the right hidden internal unique id. Having all this hidden
452 information that the user can't see makes for a confusing and
453 frustrating user experience, and exposing long ugly hexadecimal
454 strings to the user and forcing them to understand what they mean
457 * Suppose an existing printer is moved to a new department, and given
458 a new name and a new function. Changing the user-visible name of
459 that piece of hardware doesn't change its hidden internal unique
460 id. Users who had previously created print queues for that printer
461 will still be accessing the same hardware by its unique id, even
464 Expires 10th February 2007 Cheshire & Krochmal [Page 8]
466 Internet Draft DNS-Based Service Discovery 10th August 2006
469 though the logical service that used to be offered by that hardware
472 To solve these problems requires the user or administrator to be
473 aware of the supposedly hidden unique id, and to set its value
474 correctly as hardware is moved around, repurposed, or replaced,
475 thereby contradicting the notion that it is a hidden identifier that
476 human users never need to deal with. Requiring the user to understand
477 this expert behind-the-scenes knowledge of what is *really* going on
478 is just one more burden placed on the user when they are trying to
479 diagnose why their computers and network devices are not working as
482 These anomalies and counter-intuitive behaviors can be eliminated by
483 maintaining a tight bidirectional one-to-one mapping between what
484 the user sees on the screen and what is really happening "behind
485 the curtain". If something is configured incorrectly, then that is
486 apparent in the familiar day-to-day user interface that everyone
487 understands, not in some little-known rarely-used "expert" interface.
489 In summary: The user-visible name is the primary identifier for a
490 service. If the user-visible name is changed, then conceptually
491 the service being offered is a different logical service -- even
492 though the hardware offering the service stayed the same. If the
493 user-visible name doesn't change, then conceptually the service being
494 offered is the same logical service -- even if the hardware offering
495 the service is new hardware brought in to replace some old equipment.
497 There are certainly arguments on both sides of this debate.
498 Nonetheless, the designers of any service discovery protocol have
499 to make a choice between between having the primary identifiers be
500 hidden, or having them be visible, and these are the reasons that
501 we chose to make them visible. We're not claiming that there are no
502 disadvantages of having primary identifiers be visible. We considered
503 both alternatives, and we believe that the few disadvantages
504 of visible identifiers are far outweighed by the many problems
505 caused by use of hidden identifiers.
508 4.5 Ordering of Service Instance Name Components
510 There have been questions about why services are named using DNS
511 Service Instance Names of the form:
513 Service Instance Name = <Instance> . <Service> . <Domain>
517 Service Instance Name = <Service> . <Instance> . <Domain>
522 Expires 10th February 2007 Cheshire & Krochmal [Page 9]
524 Internet Draft DNS-Based Service Discovery 10th August 2006
527 There are three reasons why it is beneficial to name service
528 instances with the parent domain as the most-significant (rightmost)
529 part of the name, then the abstract service type as the next-most
530 significant, and then the specific instance name as the
531 least-significant (leftmost) part of the name:
534 4.5.1. Semantic Structure
536 The facility being provided by browsing ("Service Instance
537 Enumeration") is effectively enumerating the leaves of a tree
538 structure. A given domain offers zero or more services. For each
539 of those service types, there may be zero or more instances of
542 The user knows what type of service they are seeking. (If they are
543 running an FTP client, they are looking for FTP servers. If they have
544 a document to print, they are looking for entities that speak some
545 known printing protocol.) The user knows in which organizational or
546 geographical domain they wish to search. (The user does not want a
547 single flat list of every single printer on the planet, even if such
548 a thing were possible.) What the user does not know in advance is
549 whether the service they seek is offered in the given domain, or if
550 so, how many instances are offered, and the names of those instances.
551 Hence having the instance names be the leaves of the tree is
552 consistent with this semantic model.
554 Having the service types be the terminal leaves of the tree would
555 imply that the user knows the domain name, and already knows the
556 name of the service instance, but doesn't have any idea what the
557 service does. We would argue that this is a less useful model.
560 4.5.2. Network Efficiency
562 When a DNS response contains multiple answers, name compression works
563 more effectively if all the names contain a common suffix. If many
564 answers in the packet have the same <Service> and <Domain>, then each
565 occurrence of a Service Instance Name can be expressed using only
566 the <Instance> part followed by a two-byte compression pointer
567 referencing a previous appearance of "<Service>.<Domain>". This
568 efficiency would not be possible if the <Service> component appeared
572 4.5.3. Operational Flexibility
574 This name structure allows subdomains to be delegated along logical
575 service boundaries. For example, the network administrator at Example
576 Co. could choose to delegate the "_tcp.example.com." subdomain to a
577 different machine, so that the machine handling service discovery
580 Expires 10th February 2007 Cheshire & Krochmal [Page 10]
582 Internet Draft DNS-Based Service Discovery 10th August 2006
585 doesn't have to be the same as the machine handling other day-to-day
586 DNS operations. (It *can* be the same machine if the administrator so
587 chooses, but the point is that the administrator is free to make that
588 choice.) Furthermore, if the network administrator wishes to delegate
589 all information related to IPP printers to a machine dedicated to
590 that specific task, this is easily done by delegating the
591 "_ipp._tcp.example.com." subdomain to the desired machine. It is
592 also convenient to set security policies on a per-zone/per-subdomain
593 basis. For example, the administrator may choose to enable DNS
594 Dynamic Update [RFC 2136] [RFC 3007] for printers registering
595 in the "_ipp._tcp.example.com." subdomain, but not for other
596 zones/subdomains. This easy flexibility would not exist if the
597 <Service> component appeared first in each name.
600 5. Service Name Resolution
602 Given a particular Service Instance Name, when a client needs to
603 contact that service, it sends a DNS query for the SRV record of
606 The result of the DNS query is a SRV record giving the port number
607 and target host where the service may be found.
609 The use of SRV records is very important. There are only 65535 TCP
610 port numbers available. These port numbers are being allocated
611 one-per-application-protocol at an alarming rate. Some protocols
612 like the X Window System have a block of 64 TCP ports allocated
613 (6000-6063). If we start allocating blocks of 64 TCP ports at a time,
614 we will run out even faster. Using a different TCP port for each
615 different instance of a given service on a given machine is entirely
616 sensible, but allocating large static ranges, as was done for X, is a
617 very inefficient way to manage a limited resource. On any given host,
618 most TCP ports are reserved for services that will never run on that
619 particular host. This is very poor utilization of the limited port
620 space. Using SRV records allows each host to allocate its available
621 port numbers dynamically to those services running on that host that
622 need them, and then advertise the allocated port numbers via SRV
623 records. Allocating the available listening port numbers locally
624 on a per-host basis as needed allows much better utilization of the
625 available port space than today's centralized global allocation.
627 In some environments there may be no compelling reason to assign
628 managed names to every host, since every available service is
629 accessible by name anyway, as a first-class entity in its own right.
630 However, the DNS packet format and record format still require a host
631 name to link the target host referenced in the SRV record to the
632 address records giving the IPv4 and/or IPv6 addresses for that
633 hardware. In the case where no natural host name is available, the
634 SRV record may give its own name as the name of the target host, and
635 then the requisite address records may be attached to that same name.
638 Expires 10th February 2007 Cheshire & Krochmal [Page 11]
640 Internet Draft DNS-Based Service Discovery 10th August 2006
643 It is perfectly permissible for a single name in the DNS hierarchy
644 to have multiple records of different type attached. (The only
645 restriction being that a given name may not have both a CNAME record
646 and other records at the same time.)
648 In the event that more than one SRV is returned, clients MUST
649 correctly interpret the priority and weight fields -- i.e. Lower
650 numbered priority servers should be used in preference to higher
651 numbered priority servers, and servers with equal priority should be
652 selected randomly in proportion to their relative weights. However,
653 in the overwhelmingly common case, a single advertised DNS-SD service
654 instance is described by exactly one SRV record, and in this common
655 case the priority and weight fields of the SRV record SHOULD both be
659 6. Data Syntax for DNS-SD TXT Records
661 Some services discovered via Service Instance Enumeration may need
662 more than just an IP address and port number to properly identify the
663 service. For example, printing via the LPR protocol often specifies a
664 queue name. This queue name is typically short and cryptic, and need
665 not be shown to the user. It should be regarded the same way as the
666 IP address and port number -- it is one component of the addressing
667 information required to identify a specific instance of a service
668 being offered by some piece of hardware. Similarly, a file server may
669 have multiple volumes, each identified by its own volume name. A Web
670 server typically has multiple pages, each identified by its own URL.
671 In these cases, the necessary additional data is stored in a TXT
672 record with the same name as the SRV record. The specific nature of
673 that additional data, and how it is to be used, is service-dependent,
674 but the overall syntax of the data in the TXT record is standardized,
675 as described below. Every DNS-SD service MUST have a TXT record in
676 addition to its SRV record, with same name, even if the service has
677 no additional data to store and the TXT record contains no more than
681 6.1 General Format Rules for DNS TXT Records
683 A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total
684 length is indicated by the length given in the resource record header
685 in the DNS message. There is no way to tell directly from the data
686 alone how long it is (e.g. there is no length count at the start, or
687 terminating NULL byte at the end). (Note that when using Multicast
688 DNS [mDNS] the maximum packet size is 9000 bytes, which imposes an
689 upper limit on the size of TXT records of about 8800 bytes.)
691 The format of the data within a DNS TXT record is one or more
692 strings, packed together in memory without any intervening gaps
693 or padding bytes for word alignment.
696 Expires 10th February 2007 Cheshire & Krochmal [Page 12]
698 Internet Draft DNS-Based Service Discovery 10th August 2006
701 The format of each constituent string within the DNS TXT record is a
702 single length byte, followed by 0-255 bytes of text data.
704 These format rules are defined in Section 3.3.14 of RFC 1035, and are
705 not specific to DNS-SD. DNS-SD simply specifies a usage convention
706 for what data should be stored in those constituent strings.
708 An empty TXT record containing zero strings is disallowed by RFC
709 1035. DNS-SD implementations MUST NOT emit empty TXT records.
710 DNS-SD implementations receiving empty TXT records MUST treat them
711 as equivalent to a one-byte TXT record containing a single zero byte
712 (i.e. a single empty string).
715 6.2 DNS TXT Record Format Rules for use in DNS-SD
717 DNS-SD uses DNS TXT records to store arbitrary name/value pairs
718 conveying additional information about the named service. Each
719 name/value pair is encoded as its own constituent string within the
720 DNS TXT record, in the form "name=value". Everything up to the first
721 '=' character is the name. Everything after the first '=' character
722 to the end of the string (including subsequent '=' characters, if
723 any) is the value. Specific rules governing names and values are
724 given below. Each author defining a DNS-SD profile for discovering
725 instances of a particular type of service should define the base set
726 of name/value attributes that are valid for that type of service.
728 Using this standardized name/value syntax within the TXT record makes
729 it easier for these base definitions to be expanded later by defining
730 additional named attributes. If an implementation sees unknown
731 attribute names in a service TXT record, it MUST silently ignore
734 The TCP (or UDP) port number of the service, and target host name,
735 are given in the SRV record. This information -- target host name and
736 port number -- MUST NOT be duplicated using name/value attributes in
739 The intention of DNS-SD TXT records is to convey a small amount of
740 useful additional information about a service. Ideally it SHOULD NOT
741 be necessary for a client to retrieve this additional information
742 before it can usefully establish a connection to the service. For a
743 well-designed TCP-based application protocol, it should be possible,
744 knowing only the host name and port number, to open a connection
745 to that listening process, and then perform version- or feature-
746 negotiation to determine the capabilities of the service instance.
747 For example, when connecting to an AppleShare server over TCP, the
748 client enters into a protocol exchange with the server to determine
749 which version of the AppleShare protocol the server implements, and
750 which optional features or capabilities (if any) are available. For a
751 well-designed application protocol, clients should be able to connect
754 Expires 10th February 2007 Cheshire & Krochmal [Page 13]
756 Internet Draft DNS-Based Service Discovery 10th August 2006
759 and use the service even if there is no information at all in the TXT
760 record. In this case, the information in the TXT record should be
761 viewed as a performance optimization -- when a client discovers many
762 instances of a service, the TXT record allows the client to know some
763 rudimentary information about each instance without having to open a
764 TCP connection to each one and interrogate every service instance
765 separately. Extreme care should be taken when doing this to ensure
766 that the information in the TXT record is in agreement with the
767 information retrieved by a client connecting over TCP.
769 There are legacy protocols which provide no feature negotiation
770 capability, and in these cases it may be useful to convey necessary
771 information in the TXT record. For example, when printing using the
772 old Unix LPR (port 515) protocol, the LPR service provides no way
773 for the client to determine whether a particular printer accepts
774 PostScript, or what version of PostScript, etc. In this case it is
775 appropriate to embed this information in the TXT record, because the
776 alternative is worse -- passing around written instructions to the
777 users, arcane manual configuration of "/etc/printcap" files, etc.
780 6.3 DNS-SD TXT Record Size
782 The total size of a typical DNS-SD TXT record is intended to be small
783 -- 200 bytes or less.
785 In cases where more data is justified (e.g. LPR printing), keeping
786 the total size under 400 bytes should allow it to fit in a single
787 standard 512-byte DNS message. (This standard DNS message size is
788 defined in RFC 1035.)
790 In extreme cases where even this is not enough, keeping the size of
791 the TXT record under 1300 bytes should allow it to fit in a single
792 1500-byte Ethernet packet.
794 Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this
798 6.4 Rules for Names in DNS-SD Name/Value Pairs
800 The "Name" MUST be at least one character. Strings beginning with an
801 '=' character (i.e. the name is missing) SHOULD be silently ignored.
803 The characters of "Name" MUST be printable US-ASCII values
804 (0x20-0x7E), excluding '=' (0x3D).
806 Spaces in the name are significant, whether leading, trailing, or in
807 the middle -- so don't include any spaces unless you really intend
812 Expires 10th February 2007 Cheshire & Krochmal [Page 14]
814 Internet Draft DNS-Based Service Discovery 10th August 2006
817 Case is ignored when interpreting a name, so "papersize=A4",
818 "PAPERSIZE=A4" and "Papersize=A4" are all identical.
820 If there is no '=', then it is a boolean attribute, and is simply
821 identified as being present, with no value.
823 A given attribute name may appear at most once in a TXT record.
824 The reason for this simplifying rule is to facilitate the creation
825 of client libraries that parse the TXT record into an internal data
826 structure, such as a hash table or dictionary object that maps from
827 names to values, and then make that abstraction available to client
828 code. The rule that a given attribute name may not appear more than
829 once simplifies these abstractions because they aren't required to
830 support the case of returning more than one value for a given key.
832 If a client receives a TXT record containing the same attribute name
833 more than once, then the client MUST silently ignore all but the
834 first occurrence of that attribute. For client implementations that
835 process a DNS-SD TXT record from start to end, placing name/value
836 pairs into a hash table, using the name as the hash table key, this
837 means that if the implementation attempts to add a new name/value
838 pair into the table and finds an entry with the same name already
839 present, then the new entry being added should be silently discarded
840 instead. For client implementations that retrieve name/value pairs by
841 searching the TXT record for the requested name, they should search
842 the TXT record from the start, and simply return the first matching
845 When examining a TXT record for a given named attribute, there are
846 therefore four broad categories of results which may be returned:
848 * Attribute not present (Absent)
850 * Attribute present, with no value
851 (e.g. "Anon Allowed" -- server allows anonymous connections)
853 * Attribute present, with empty value (e.g. "Installed PlugIns=" --
854 server supports plugins, but none are presently installed)
856 * Attribute present, with non-empty value
857 (e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4")
859 Each author defining a DNS-SD profile for discovering instances of a
860 particular type of service should define the interpretation of these
861 different kinds of result. For example, for some keys, there may be
862 a natural true/false boolean interpretation:
864 * Present implies 'true'
865 * Absent implies 'false'
870 Expires 10th February 2007 Cheshire & Krochmal [Page 15]
872 Internet Draft DNS-Based Service Discovery 10th August 2006
875 For other keys it may be sensible to define other semantics, such as
876 value/no-value/unknown:
878 * Present with value implies that value.
879 E.g. "Color=4" for a four-color ink-jet printer,
880 or "Color=6" for a six-color ink-jet printer.
882 * Present with empty value implies 'false'. E.g. Not a color printer.
884 * Absent implies 'Unknown'. E.g. A print server connected to some
885 unknown printer where the print server doesn't actually know if the
886 printer does color or not -- which gives a very bad user experience
887 and should be avoided wherever possible.
889 (Note that this is a hypothetical example, not an example of actual
890 name/value keys used by DNS-SD network printers.)
892 As a general rule, attribute names that contain no dots are defined
893 as part of the open-standard definition written by the person or
894 group defining the DNS-SD profile for discovering that particular
895 service type. Vendor-specific extensions should be given names of the
896 form "keyname.company.com=value", using a domain name legitimately
897 registered to the person or organization creating the vendor-specific
898 key. This reduces the risk of accidental conflict if different
899 organizations each define their own vendor-specific keys.
902 6.5 Rules for Values in DNS-SD Name/Value Pairs
904 If there is an '=', then everything after the first '=' to the end
905 of the string is the value. The value can contain any eight-bit
906 values including '='. Leading or trailing spaces are part of the
907 value, so don't put them there unless you intend them to be there.
908 Any quotation marks around the value are part of the value, so don't
909 put them there unless you intend them to be part of the value.
911 The value is opaque binary data. Often the value for a particular
912 attribute will be US-ASCII (or UTF-8) text, but it is legal for a
913 value to be any binary data. For example, if the value of a key is an
914 IPv4 address, that address should simply be stored as four bytes of
915 binary data, not as a variable-length 7-15 byte ASCII string giving
916 the address represented in textual dotted decimal notation.
918 Generic debugging tools should generally display all attribute values
919 as a hex dump, with accompanying text alongside displaying the UTF-8
920 interpretation of those bytes, except for attributes where the
921 debugging tool has embedded knowledge that the value is some other
924 Authors defining DNS-SD profiles SHOULD NOT convert binary attribute
925 data types into printable text (e.g. using hexadecimal, Base-64 or UU
928 Expires 10th February 2007 Cheshire & Krochmal [Page 16]
930 Internet Draft DNS-Based Service Discovery 10th August 2006
933 encoding) merely for the sake of making the data be printable text
934 when seen in a generic debugging tool. Doing this simply bloats the
935 size of the TXT record, without actually making the data any more
936 understandable to someone looking at it in a generic debugging tool.
939 6.6 Example TXT Record
941 The TXT record below contains three syntactically valid name/value
942 pairs. (The meaning of these name/value pairs, if any, would depend
943 on the definitions pertaining to the service in question that is
946 ---------------------------------------------------------------
947 | 0x0A | name=value | 0x08 | paper=A4 | 0x0E | DNS-SD Is Cool |
948 ---------------------------------------------------------------
953 It is recommended that authors defining DNS-SD profiles include an
954 attribute of the form "txtvers=xxx" in their definition, and require
955 it to be the first name/value pair in the TXT record. This
956 information in the TXT record can be useful to help clients maintain
957 backwards compatibility with older implementations if it becomes
958 necessary to change or update the specification over time. Even if
959 the profile author doesn't anticipate the need for any future
960 incompatible changes, having a version number in the specification
961 provides useful insurance should incompatible changes become
962 unavoidable. Clients SHOULD ignore TXT records with a txtvers number
963 higher (or lower) than the version(s) they know how to interpret.
965 Note that the version number in the txtvers tag describes the version
966 of the TXT record specification being used to create this TXT record,
967 not the version of the application protocol that will be used if the
968 client subsequently decides to contact that service. Ideally, every
969 DNS-SD TXT record specification starts at txtvers=1 and stays that
970 way forever. Improvements can be made by defining new keys that older
971 clients silently ignore. The only reason to increment the version
972 number is if the old specification is subsequently found to be so
973 horribly broken that there's no way to do a compatible forward
974 revision, so the txtvers number has to be incremented to tell all the
975 old clients they should just not even try to understand this new TXT
978 If there is a need to indicate which version number(s) of the
979 application protocol the service implements, the recommended key
980 name for this is "protovers".
986 Expires 10th February 2007 Cheshire & Krochmal [Page 17]
988 Internet Draft DNS-Based Service Discovery 10th August 2006
991 7. Application Protocol Names
993 The <Service> portion of a Service Instance Name consists of a pair
994 of DNS labels, following the established convention for SRV records
995 [RFC 2782], namely: the first label of the pair is an underscore
996 character followed by the Application Protocol Name, and the second
997 label is either "_tcp" or "_udp".
999 Application Protocol Names may be no more than fourteen characters
1000 (not counting the mandatory underscore), conforming to normal DNS
1001 host name rules: Only lower-case letters, digits, and hyphens; must
1002 begin and end with lower-case letter or digit.
1004 Wise selection of an Application Protocol Name is very important,
1005 and the choice is not always as obvious as it may appear.
1007 In some cases, the Application Protocol Name merely names and refers
1008 to the on-the-wire message format and semantics being used. FTP is
1009 "ftp", IPP printing is "ipp", and so on.
1011 However, it is common to "borrow" an existing protocol and repurpose
1012 it for a new task. This is entirely sensible and sound engineering
1013 practice, but that doesn't mean that the new protocol is providing
1014 the same semantic service as the old one, even if it borrows the same
1015 message formats. For example, the local network music playing
1016 protocol implemented by iTunes on Macintosh and Windows is little
1017 more than "HTTP GET" commands. However, that does *not* mean that it
1018 is sensible or useful to try to access one of these music servers by
1019 connecting to it with a standard web browser. Consequently, the
1020 DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp"
1021 (Digital Audio Access Protocol), not "_http._tcp". Advertising
1022 "_http._tcp" service would cause iTunes servers to show up in
1023 conventional Web browsers (Safari, Camino, OmniWeb, Opera, Netscape,
1024 Internet Explorer, etc.) which is little use since it offers no pages
1025 containing human-readable content. Similarly, browsing for
1026 "_http._tcp" service would cause iTunes to find generic web servers,
1027 such as the embedded web servers in devices like printers, which is
1028 little use since printers generally don't have much music to offer.
1030 Similarly, NFS is built on top of SUN RPC, but that doesn't mean it
1031 makes sense for an NFS server to advertise that it provides "SUN RPC"
1032 service. Likewise, Microsoft SMB file service is built on top of
1033 Netbios running over IP, but that doesn't mean it makes sense for
1034 an SMB file server to advertise that it provides "Netbios-over-IP"
1035 service. The DNS-SD name of a service needs to encapsulate both the
1036 "what" (semantics) and the "how" (protocol implementation) of the
1037 service, since knowledge of both is necessary for a client to
1038 usefully use the service. Merely advertising that a service was
1039 built on top of SUN RPC is no use if the client has no idea what
1040 the service actually does.
1044 Expires 10th February 2007 Cheshire & Krochmal [Page 18]
1046 Internet Draft DNS-Based Service Discovery 10th August 2006
1049 Another common mistake is to assume that the service type advertised
1050 by iTunes should be "_daap._http._tcp." This is also incorrect.
1051 Similarly, a protocol designer implementing a network service that
1052 happens to use Simple Object Access Protocol [SOAP] should not feel
1053 compelled to have "_soap" appear somewhere in the Application
1054 Protocol Name. Part of the confusion here is that the presence of
1055 "_tcp" or "_udp" in the <Service> portion of a Service Instance Name
1056 has led people to assume that the structure of a service name has to
1057 reflect the internal structure of how the protocol was implemented.
1058 This is not correct. All that is required is that the service be
1059 identified by a unique Application Protocol Name. Making the
1060 Application Protocol Name at least marginally descriptive of
1061 what the service does is desirable, though not essential.
1063 The "_tcp" or "_udp" should be regarded as little more than
1064 boilerplate text, and care should be taken not to attach too much
1065 importance to it. Some might argue that the "_tcp" or "_udp" should
1066 not be there at all, but this format is defined by RFC 2782, and
1067 that's not going to change. In addition, the presence of "_tcp" has
1068 the useful side-effect that it provides a convenient delegation point
1069 to hand off responsibility for service discovery to a different DNS
1070 server, if so desired.
1073 7.1. Selective Instance Enumeration
1075 This document does not attempt to define an arbitrary query language
1076 for service discovery, nor do we believe one is necessary.
1078 However, there are some circumstances where narrowing the list of
1079 results may be useful. A hypothetical Web browser client that is able
1080 to retrieve HTML documents via HTTP and display them may also be able
1081 to retrieve HTML documents via FTP and display them, but only in the
1082 case of FTP servers that allow anonymous login. For that Web browser,
1083 discovering all FTP servers on the network is not useful. The Web
1084 browser only wants to discover FTP servers that it is able to talk
1085 to. In this case, a subtype of "_ftp._tcp" could be defined. Instead
1086 of issuing a query for "_ftp._tcp.<Domain>", the Web browser issues a
1087 query for "_anon._sub._ftp._tcp.<Domain>", where "_anon" is a defined
1088 subtype of "_ftp._tcp". The response to this query only includes the
1089 names of SRV records for FTP servers that are willing to allow
1092 Note that the FTP server's Service Instance Name is unchanged -- it
1093 is still something of the form "The Server._ftp._tcp.example.com."
1094 The subdomain in which FTP server SRV records are registered defines
1095 the namespace within which FTP server names are unique. Additional
1096 subtypes (e.g. "_anon") of the basic service type (e.g. "_ftp._tcp")
1097 serve to narrow the list of results, not to create more namespace.
1102 Expires 10th February 2007 Cheshire & Krochmal [Page 19]
1104 Internet Draft DNS-Based Service Discovery 10th August 2006
1107 Subtypes are appropriate when it is desirable for different kinds
1108 of clients to be able to browse for services at two levels of
1109 granularity. In the example above, we hypothesize two classes of
1110 ftp client: clients that can provide username and password when
1111 connecting, and clients that can only do anonymous login. The set of
1112 ftp servers on the network is the same in both cases; the difference
1113 is that the more capable client wants to discover all of them,
1114 whereas the more limited client only wants to find the subset of
1115 those ftp servers that it can talk to. Subtypes are only appropriate
1116 in two-level scenarios such as this one, where some clients want to
1117 find the full set of services of a given type, and at the same time
1118 other clients only want to find some subset. Generally speaking, if
1119 there is no client that wants to find the entire set, then it's
1120 neither necessary nor desirable to use the subtype mechanism. If all
1121 clients are browsing for some particular subtype, and no client
1122 exists that browses for the parent type, then an Application Protocol
1123 Name representing the logical service should be defined, and software
1124 should simply advertise and browse for that particular service type
1125 directly. In particular, just because a particular network service
1126 happens to be implemented in terms of some other underlying protocol,
1127 like HTTP, Sun RPC, or SOAP, doesn't mean that it's sensible for that
1128 service to be defined as a subtype of "_http", "_sunrpc", or "_soap".
1129 That would only be useful if there were some class of client for
1130 which it is sensible to say, "I want to discover a service on the
1131 network, and I don't care what it does, as long as it does it using
1132 the SOAP XML RPC mechanism."
1134 As with the TXT record name/value pairs, the list of possible
1135 subtypes, if any, are defined and specified separately for each basic
1136 service type. Note that the example given here using "_ftp" is a
1137 hypothetical one. The "_ftp" service type does not (currently) have
1138 any subtypes defined. Subtypes are currently a little-used feature
1139 of DNS-SD, and experience will show whether or not they ultimately
1140 prove to have broad applicability.
1143 7.2 Service Name Length Limits
1145 As described above, application protocol names are allowed to be up
1146 to fourteen characters long. The reason for this limit is to leave
1147 as many bytes of the domain name as possible available for use
1148 by both the network administrator (choosing service domain names)
1149 and the end user (choosing instance names).
1151 A domain name may be up to 255 bytes long, including the final
1152 terminating root label at the end. Domain names used by DNS-SD
1153 take the following forms:
1155 <Instance>.<app>._tcp.<servicedomain>.<parentdomain>.
1156 <sub>._sub.<app>._tcp.<servicedomain>.<parentdomain>.
1160 Expires 10th February 2007 Cheshire & Krochmal [Page 20]
1162 Internet Draft DNS-Based Service Discovery 10th August 2006
1165 The first example shows a service instance name, i.e. the name of the
1166 service's SRV and TXT records. The second shows a subtype browsing
1167 name, i.e. the name of a PTR record pointing to service instance
1168 names (see "Selective Instance Enumeration").
1170 The instance name <Instance> may be up to 63 bytes. Including the
1171 length byte used by the DNS format when the name is stored in a
1172 packet, that makes 64 bytes.
1174 When using subtypes, the subtype identifier is allowed to be up to
1175 63 bytes, plus the length byte, making 64. Including the "_sub"
1176 and its length byte, this makes 69 bytes.
1178 The application protocol name <app> may be up to 14 bytes, plus the
1179 underscore and length byte, making 16. Including the "_udp" or "_tcp"
1180 and its length byte, this makes 21 bytes.
1182 Typically, DNS-SD service records are placed into subdomains of their
1183 own beneath a company's existing domain name. Since these subdomains
1184 are intended to be accessed through graphical user interfaces, not
1185 typed on a command-line they are frequently long and descriptive.
1186 Including the length byte, the user-visible service domain may be up
1189 The terminating root label at the end counts as one byte.
1191 Of our available 255 bytes, we have now accounted for 69+21+64+1 =
1192 155 bytes. This leaves 100 bytes to accommodate the organization's
1193 existing domain name <parentdomain>. When used with Multicast DNS,
1194 <parentdomain> is "local", which easily fits. When used with parent
1195 domains of 100 bytes or less, the full functionality of DNS-SD is
1196 available without restriction. When used with parent domains longer
1197 than 100 bytes, the protocol risks exceeding the maximum possible
1198 length of domain names, causing failures. In this case, careful
1199 choice of short <servicedomain> names can help avoid overflows.
1200 If the <servicedomain> and <parentdomain> are too long, then service
1201 instances with long instance names will not be discoverable or
1202 resolvable, and applications making use of long subtype names
1205 Because of this constraint, we choose to limit Application Protocol
1206 Names to 14 characters or less. Allowing more characters would not
1207 add to the expressive power of the protocol, and would needlessly
1208 lower the limit on the maximum <parentdomain> length that may be
1218 Expires 10th February 2007 Cheshire & Krochmal [Page 21]
1220 Internet Draft DNS-Based Service Discovery 10th August 2006
1225 In some cases, there may be several network protocols available
1226 which all perform roughly the same logical function. For example,
1227 the printing world has the LPR protocol, and the Internet Printing
1228 Protocol (IPP), both of which cause printed sheets to be emitted
1229 from printers in much the same way. In addition, many printer vendors
1230 send their own proprietary page description language (PDL) data
1231 over a TCP connection to TCP port 9100, herein referred to as the
1232 "pdl-datastream" protocol. In an ideal world we would have only one
1233 network printing protocol, and it would be sufficiently good that no
1234 one felt a compelling need to invent a different one. However, in
1235 practice, multiple legacy protocols do exist, and a service discovery
1236 protocol has to accommodate that.
1238 Many printers implement all three printing protocols: LPR, IPP, and
1239 pdl-datastream. For the benefit of clients that may speak only one of
1240 those protocols, all three are advertised.
1242 However, some clients may implement two, or all three of those
1243 printing protocols. When a client looks for all three service types
1244 on the network, it will find three distinct services -- an LPR
1245 service, an IPP service, and a pdl-datastream service -- all of which
1246 cause printed sheets to be emitted from the same physical printer.
1248 In the case of multiple protocols like this that all perform
1249 effectively the same function, the client should suppress duplicate
1250 names and display each name only once. When the user prints to a
1251 given named printer, the printing client is responsible for choosing
1252 the protocol which will best achieve the desired effect, without, for
1253 example, requiring the user to make a manual choice between LPR and
1256 As described so far, this all works very well. However, consider some
1257 future printer that only supports IPP printing, and some other future
1258 printer that only supports pdl-datastream printing. The name spaces
1259 for different service types are intentionally disjoint -- it is
1260 acceptable and desirable to be able to have both a file server called
1261 "Sales Department" and a printer called "Sales Department". However,
1262 it is not desirable, in the common case, to have two different
1263 printers both called "Sales Department", just because those printers
1264 are implementing different protocols.
1266 To help guard against this, when there are two or more network
1267 protocols which perform roughly the same logical function, one of
1268 the protocols is declared the "flagship" of the fleet of related
1269 protocols. Typically the flagship protocol is the oldest and/or
1270 best-known protocol of the set.
1272 If a device does not implement the flagship protocol, then it instead
1273 creates a placeholder SRV record (priority=0, weight=0, port=0,
1276 Expires 10th February 2007 Cheshire & Krochmal [Page 22]
1278 Internet Draft DNS-Based Service Discovery 10th August 2006
1281 target host = hostname of device) with that name. If, when it
1282 attempts to create this SRV record, it finds that a record with the
1283 same name already exists, then it knows that this name is already
1284 taken by some entity implementing at least one of the protocols from
1285 the class, and it must choose another. If no SRV record already
1286 exists, then the act of creating it stakes a claim to that name so
1287 that future devices in the same class will detect a conflict when
1288 they try to use it. The SRV record needs to contain the target host
1289 name in order for the conflict detection rules to operate. If two
1290 different devices were to create placeholder SRV records both using a
1291 null target host name (just the root label), then the two SRV records
1292 would be seen to be in agreement so no conflict would be registered.
1294 By defining a common well-known flagship protocol for the class,
1295 future devices that may not even know about each other's protocols
1296 establish a common ground where they can coordinate to verify
1297 uniqueness of names.
1299 No PTR record is created advertising the presence of empty flagship
1300 SRV records, since they do not represent a real service being
1304 9. Service Type Enumeration
1306 In general, clients are not interested in finding *every* service on
1307 the network, just the services that the client knows how to talk to.
1308 (Software designers may *think* there's some value to finding *every*
1309 service on the network, but that's just wooly thinking.)
1311 However, for problem diagnosis and network management tools, it may
1312 be useful for network administrators to find the list of advertised
1313 service types on the network, even if those service names are just
1314 opaque identifiers and not particularly informative in isolation.
1316 For this reason, a special meta-query is defined. A DNS query for
1317 PTR records with the name "_services._dns-sd._udp.<Domain>" yields
1318 a list of PTR records, where the rdata of each PTR record is the
1319 name of a service type. A subsequent query for PTR records with
1320 one of those names yields a list of instances of that service type.
1334 Expires 10th February 2007 Cheshire & Krochmal [Page 23]
1336 Internet Draft DNS-Based Service Discovery 10th August 2006
1339 10. Populating the DNS with Information
1341 How the SRV and PTR records that describe services and allow them to
1342 be enumerated make their way into the DNS is outside the scope of
1343 this document. However, it can happen easily in any of a number of
1346 On some networks, the administrator might manually enter the records
1347 into the name server's configuration file.
1349 A network monitoring tool could output a standard zone file to be
1350 read into a conventional DNS server. For example, a tool that can
1351 find Apple LaserWriters using AppleTalk NBP could find the list
1352 of printers, communicate with each one to find its IP address,
1353 PostScript version, installed options, etc., and then write out a
1354 DNS zone file describing those printers and their capabilities using
1355 DNS resource records. That information would then be available to
1356 DNS-SD clients that don't implement AppleTalk NBP, and don't want to.
1358 Future IP printers could use Dynamic DNS Update [RFC 2136] to
1359 automatically register their own SRV and PTR records with the DNS
1362 A printer manager device which has knowledge of printers on the
1363 network through some other management protocol could also use Dynamic
1364 DNS Update [RFC 2136].
1366 Alternatively, a printer manager device could implement enough of
1367 the DNS protocol that it is able to answer DNS queries directly,
1368 and Example Co.'s main DNS server could delegate the
1369 _ipp._tcp.example.com subdomain to the printer manager device.
1371 Zeroconf printers answer Multicast DNS queries on the local link
1372 for appropriate PTR and SRV names ending with ".local." [mDNS]
1375 11. Relationship to Multicast DNS
1377 DNS-Based Service Discovery is only peripherally related to Multicast
1378 DNS, in that the standard unicast DNS queries used by DNS-SD may also
1379 be performed using multicast when appropriate, which is particularly
1380 beneficial in Zeroconf environments [ZC].
1392 Expires 10th February 2007 Cheshire & Krochmal [Page 24]
1394 Internet Draft DNS-Based Service Discovery 10th August 2006
1397 12. Discovery of Browsing and Registration Domains (Domain Enumeration)
1399 One of the main reasons for DNS-Based Service Discovery is so that
1400 when a visiting client (e.g. a laptop computer) arrives at a new
1401 network, it can discover what services are available on that network
1402 without manual configuration. This logic that applies to discovering
1403 services without manual configuration also applies to discovering the
1404 domains in which services are registered without requiring manual
1407 This discovery is performed recursively, using Unicast or Multicast
1408 DNS. Five special RR names are reserved for this purpose:
1410 b._dns-sd._udp.<domain>.
1411 db._dns-sd._udp.<domain>.
1412 r._dns-sd._udp.<domain>.
1413 dr._dns-sd._udp.<domain>.
1414 lb._dns-sd._udp.<domain>.
1416 By performing PTR queries for these names, a client can learn,
1419 o A list of domains recommended for browsing
1421 o A single recommended default domain for browsing
1423 o A list of domains recommended for registering services using
1426 o A single recommended default domain for registering services.
1428 o The final query shown yields the "legacy browsing" domain.
1429 Sophisticated client applications that care to present choices
1430 of domain to the user, use the answers learned from the previous
1431 four queries to discover those domains to present. In contrast,
1432 many current applications browse without specifying an explicit
1433 domain, allowing the operating system to automatically select an
1434 appropriate domain on their behalf. It is for this class of
1435 application that the "legacy browsing" query is provided, to allow
1436 the network administrator to communicate to the client operating
1437 systems which domain should be used for these applications.
1439 These domains are purely advisory. The client or user is free to
1440 browse and/or register services in any domains. The purpose of these
1441 special queries is to allow software to create a user-interface that
1442 displays a useful list of suggested choices to the user, from which
1443 they may make a suitable selection, or ignore the offered suggestions
1444 and manually enter their own choice.
1450 Expires 10th February 2007 Cheshire & Krochmal [Page 25]
1452 Internet Draft DNS-Based Service Discovery 10th August 2006
1455 The <domain> part of the name may be "local" (meaning "perform the
1456 query using link-local multicast) or it may be learned through some
1457 other mechanism, such as the DHCP "Domain" option (option code 15)
1458 [RFC 2132] or the DHCP "Domain Search" option (option code 119)
1461 The <domain> part of the name may also be derived from the host's IP
1462 address. The host takes its IP address, and calculates the logical
1463 AND of that address and its subnet mask, to derive the 'base' address
1464 of the subnet. It then constructs the conventional DNS "reverse
1465 mapping" name corresponding to that base address, and uses that
1466 as the <domain> part of the name for the queries described above.
1467 For example, if a host has address 192.168.12.34, with subnet mask
1468 255.255.0.0, then the 'base' address of the subnet is 192.168.0.0,
1469 and to discover the recommended legacy browsing domain for devices
1470 on this subnet, the host issues a DNS PTR query for the name
1471 "lb._dns-sd._udp.0.0.168.192.in-addr.arpa."
1473 Sophisticated clients may perform domain enumeration queries both in
1474 "local" and in one or more unicast domains, and then present the user
1475 with an aggregate result, combining the information received from all
1479 13. DNS Additional Record Generation
1481 DNS has an efficiency feature whereby a DNS server may place
1482 additional records in the Additional Section of the DNS Message.
1483 These additional records are typically records that the client did
1484 not explicitly request, but the server has reasonable grounds to
1485 expect that the client might request them shortly.
1487 This section recommends which additional records should be generated
1488 to improve network efficiency for both unicast and multicast DNS-SD
1494 When including a PTR record in a response packet, the
1495 server/responder SHOULD include the following additional records:
1497 o The SRV record(s) named in the PTR rdata.
1498 o The TXT record(s) named in the PTR rdata.
1499 o All address records (type "A" and "AAAA") named in the SRV rdata.
1508 Expires 10th February 2007 Cheshire & Krochmal [Page 26]
1510 Internet Draft DNS-Based Service Discovery 10th August 2006
1515 When including an SVR record in a response packet, the
1516 server/responder SHOULD include the following additional records:
1518 o All address records (type "A" and "AAAA") named in the SRV rdata.
1523 When including a TXT record in a response packet, no additional
1524 records are required.
1527 13.4 Other Record Types
1529 In response to address queries, or other record types, no additional
1530 records are required by this document.
1533 14. Comparison with Alternative Service Discovery Protocols
1535 Over the years there have been many proposed ways to do network
1536 service discovery with IP, but none achieved ubiquity in the
1537 marketplace. Certainly none has achieved anything close to the
1538 ubiquity of today's deployment of DNS servers, clients, and other
1541 The advantage of using DNS as the basis for service discovery is
1542 that it makes use of those existing servers, clients, protocols,
1543 infrastructure, and expertise. Existing network analyzer tools
1544 already know how to decode and display DNS packets for network
1547 For ad-hoc networks such as Zeroconf environments, peer-to-peer
1548 multicast protocols are appropriate. The Zeroconf host profile [ZCHP]
1549 requires the use of a DNS-like protocol over IP Multicast for host
1550 name resolution in the absence of DNS servers. Given that Zeroconf
1551 hosts will have to implement this Multicast-based DNS-like protocol
1552 anyway, it makes sense for them to also perform service discovery
1553 using that same Multicast-based DNS-like software, instead of also
1554 having to implement an entirely different service discovery protocol.
1556 In larger networks, a high volume of enterprise-wide IP multicast
1557 traffic may not be desirable, so any credible service discovery
1558 protocol intended for larger networks has to provide some facility to
1559 aggregate registrations and lookups at a central server (or servers)
1560 instead of working exclusively using multicast. This requires some
1561 service discovery aggregation server software to be written,
1562 debugged, deployed, and maintained. This also requires some service
1563 discovery registration protocol to be implemented and deployed for
1566 Expires 10th February 2007 Cheshire & Krochmal [Page 27]
1568 Internet Draft DNS-Based Service Discovery 10th August 2006
1571 clients to register with the central aggregation server. Virtually
1572 every company with an IP network already runs a DNS server, and DNS
1573 already has a dynamic registration protocol [RFC 2136]. Given that
1574 virtually every company already has to operate and maintain a DNS
1575 server anyway, it makes sense to take advantage of this instead of
1576 also having to learn, operate and maintain a different service
1577 registration server. It should be stressed again that using the
1578 same software and protocols doesn't necessarily mean using the same
1579 physical piece of hardware. The DNS-SD service discovery functions
1580 do not have to be provided by the same piece of hardware that
1581 is currently providing the company's DNS name service. The
1582 "_tcp.<Domain>" subdomain may be delegated to a different piece of
1583 hardware. However, even when the DNS-SD service is being provided
1584 by a different piece of hardware, it is still the same familiar DNS
1585 server software that is running, with the same configuration file
1586 syntax, the same log file format, and so forth.
1588 Service discovery needs to be able to provide appropriate security.
1589 DNS already has existing mechanisms for security [RFC 2535].
1593 Service discovery requires a central aggregation server.
1594 DNS already has one: It's called a DNS server.
1596 Service discovery requires a service registration protocol.
1597 DNS already has one: It's called DNS Dynamic Update.
1599 Service discovery requires a query protocol
1600 DNS already has one: It's called DNS.
1602 Service discovery requires security mechanisms.
1603 DNS already has security mechanisms: DNSSEC.
1605 Service discovery requires a multicast mode for ad-hoc networks.
1606 Zeroconf environments already require a multicast-based DNS-like
1607 name lookup protocol for mapping host names to addresses, so it
1608 makes sense to let one multicast-based protocol do both jobs.
1610 It makes more sense to use the existing software that every network
1611 needs already, instead of deploying an entire parallel system just
1612 for service discovery.
1624 Expires 10th February 2007 Cheshire & Krochmal [Page 28]
1626 Internet Draft DNS-Based Service Discovery 10th August 2006
1631 The following examples were prepared using standard unmodified
1632 nslookup and standard unmodified BIND running on GNU/Linux.
1634 Note: In real products, this information is obtained and presented to
1635 the user using graphical network browser software, not command-line
1636 tools, but if you wish you can try these examples for yourself as you
1637 read along, using the command-line tools already available on your
1640 15.1 Question: What FTP servers are being advertised from dns-sd.org?
1642 nslookup -q=ptr _ftp._tcp.dns-sd.org.
1643 _ftp._tcp.dns-sd.org
1644 name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
1645 _ftp._tcp.dns-sd.org
1646 name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org
1647 _ftp._tcp.dns-sd.org
1648 name = Registered\032Users'\032Only._ftp._tcp.dns-sd.org
1650 Answer: There are three, called "Apple QuickTime Files",
1651 "Microsoft Developer Files" and "Registered Users' Only".
1653 Note that nslookup escapes spaces as "\032" for display purposes,
1654 but a graphical DNS-SD browser does not.
1656 15.2 Question: What FTP servers allow anonymous access?
1658 nslookup -q=ptr _anon._sub._ftp._tcp.dns-sd.org
1659 _anon._sub._ftp._tcp.dns-sd.org
1660 name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
1661 _anon._sub._ftp._tcp.dns-sd.org
1662 name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org
1664 Answer: Only "Apple QuickTime Files" and "Microsoft Developer Files"
1665 allow anonymous access.
1667 15.3 Question: How do I access "Apple QuickTime Files"?
1669 nslookup -q=any "Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org."
1670 Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
1671 text = "path=/quicktime"
1672 Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
1673 priority = 0, weight = 0, port= 21 host = ftp.apple.com
1674 ftp.apple.com internet address = 17.254.0.27
1675 ftp.apple.com internet address = 17.254.0.31
1676 ftp.apple.com internet address = 17.254.0.26
1678 Answer: You need to connect to ftp.apple.com, port 21, path
1679 "/quicktime". The addresses for ftp.apple.com are also given.
1682 Expires 10th February 2007 Cheshire & Krochmal [Page 29]
1684 Internet Draft DNS-Based Service Discovery 10th August 2006
1687 16. User Interface Considerations
1689 DNS-Based Service Discovery was designed by first giving careful
1690 consideration to what constitutes a good user experience for service
1691 discovery, and then designing a protocol with the features necessary
1692 to enable that good user experience. This section covers two issues
1693 in particular: Choice of factory-default names (and automatic
1694 renaming behavior) for devices advertising services, and the
1695 "continuous live update" user-experience model for clients
1696 browsing to discover services.
1699 16.1 Service Advertising User-Interface Considerations
1701 When a DNS-SD service is advertised using Multicast DNS [mDNS],
1702 automatic name conflict and resolution will occur if there is already
1703 another service of the same type advertising with the same name.
1704 As described in the Multicast DNS specification [mDNS], upon a
1705 conflict, the service should:
1707 1. Automatically select a new name (typically by appending
1708 or incrementing a digit at the end of the name),
1709 2. try advertising with the new name, and
1710 3. upon success, record the new name in persistent storage.
1712 This renaming behavior is very important, because it is the key
1713 to providing user-friendly service names in the out-of-the-box
1714 factory-default configuration. Some product developers may not
1715 have realized this, because there are some products today where
1716 the factory-default name is distinctly unfriendly, containing
1717 random-looking strings of characters, like the device's Ethernet
1718 address in hexadecimal. This is unnecessary, and undesirable, because
1719 the point of the user-visible name is that it should be friendly and
1720 useful to human users. If the name is not unique on the local network
1721 the protocol will rememdy this as necessary. It is ironic that many
1722 of the devices with this mistake are network printers, given that
1723 these same printers also simultaneously support AppleTalk-over-
1724 Ethernet, with nice user-friendly default names (and automatic
1725 conflict detection and renaming). Examples of good factory-default
1726 names are as follows:
1729 Canon W2200 [ Apologies to makers of ]
1730 HP LaserJet 4600 [ DNS-SD/mDNS printers ]
1731 Lexmark W840 [ not listed. Email ]
1732 Okidata C5300 [ the authors and we'll ]
1733 Ricoh Aficio CL7100 [ add you to the list. ]
1742 Expires 10th February 2007 Cheshire & Krochmal [Page 30]
1744 Internet Draft DNS-Based Service Discovery 10th August 2006
1747 To complete the case for why adding long ugly serial numbers to
1748 the end of names is neither necessary nor desirable, consider
1749 the cases where the user has (a) only one network printer,
1750 (b) two network printers, and (c) many network printers.
1752 (a) In the case where the user has only one network printer, a simple
1753 name like (to use a vendor-neutral example) "Printer" is more
1754 user-friendly than an ugly name like "Printer 0001E68C74FB".
1755 Appending ugly hexadecimal goop to the end of the name to make
1756 sure the name is unique is irrelevant to a user who only has one
1759 (b) In the case where the user gets a second network printer,
1760 having it detect that the name "Printer" is already in use
1761 and automatically instead name itself "Printer (2)" provides a
1762 good user experience. For the users, remembering that the old
1763 printer is "Printer" and the new one is "Printer (2)" is easy
1764 and intuitive. Seeing two printers called "Printer 0001E68C74FB"
1765 and "Printer 00306EC3FD1C" is a lot less helpful.
1767 (c) In the case of a network with ten network printers, seeing a
1768 list of ten names all of the form "Printer xxxxxxxxxxxx" has
1769 effectively taken what was supposed to be a list of user-friendly
1770 rich-text names (supporting mixed case, spaces, punctuation,
1771 non-Roman characters and other symbols) and turned it into
1772 just about the worst user-interface imaginable: a list of
1773 incomprehensible random-looking strings of letters and digits.
1774 In a network with a lot of printers, it would be desirable for
1775 the people setting up the printers to take a moment to give each
1776 one a descriptive name, but in the event they don't, presenting
1777 the users with a list of sequentially-numbered printers is a much
1778 more desirable default user experience than showing a list of raw
1782 16.2 Client Browsing User-Interface Considerations
1784 Of particular concern in the design of DNS-SD was the dynamic nature
1785 of service discovery in a changing network environment. Other service
1786 discovery protocols have been designed with an implicit unstated
1787 assumption that the usage model is:
1789 (a) client calls the service discovery code
1790 (b) client gets list of discovered services
1791 as of a particular instant in time, and then
1792 (c) client displays list for user to select from
1794 Superficially this usage model seems reasonable, but the problem is
1795 that it's too optimistic. It only considers the success case, where
1796 the user successfully finds the service they're looking for. In the
1799 Expires 10th February 2007 Cheshire & Krochmal [Page 31]
1801 Internet Draft DNS-Based Service Discovery 10th August 2006
1804 case where the user is looking for (say) a particular printer, and
1805 that printer's not turned on or not connected, the user first has
1806 to attempt to remedy the problem, and then has to click a "refresh"
1807 button to retry the service discovery (or, worse, dismiss the
1808 browsing window entirely, and open a new one to initiate a new
1809 network search attempt) to find out whether they were successful.
1810 Because nothing happens instantaneously in networking, and packets
1811 can be lost, necessitating some number of retransmissions, a service
1812 discovery search typically takes a few seconds. A fairly typical user
1813 experience model is:
1815 (a) display an empty window,
1816 (b) display some animation like a searchlight
1817 sweeping back and forth for ten seconds, and then
1818 (c) at the end of the ten-second search, display
1819 a static list showing what was discovered.
1821 Every time the user clicks the "refresh" button they have to endure
1822 another ten-second wait, and every time the discovered list is
1823 finally shown at the end of the ten-second wait, the moment it's
1824 displayed on the screen it's already beginning to get stale and
1827 The service discovery user experience that the DNS-SD designers had
1828 in mind has some rather different properties:
1830 1. Displaying a list of discovered services should be effectively
1831 instantaneous -- i.e. typically 1/10 second, not 10 seconds.
1833 2. The list of discovered services should not be getting stale
1834 and out-of-date from the moment it's displayed. The list
1835 should be 'live' and should continue to update as new services
1836 are discovered. Because of the delays, packet losses, and
1837 retransmissions inherent in networking, it is to be expected
1838 that sometimes, after the initial list is displayed showing
1839 the majority of discovered services, a few remaining stragglers
1840 may continue to trickle in during the subsequent few seconds.
1841 Even after this initial stable list has been built and displayed,
1842 the list should remain 'live' and should continue to update.
1843 At any future time, be it minutes, hours, or even days later,
1844 if a new service of the desired type is discovered, it should be
1845 displayed in the list automatically, without the user having to
1846 click a "refresh" button or take any other explicit action to
1849 3. With users getting to be in the habit of leaving service discovery
1850 windows open, and coming to expect to be able to rely on them
1851 to show a continuous 'live' view of current network reality,
1852 this creates a new requirement for us: deletion of stale services.
1853 When a service discovery list shows just a static snapshot at a
1854 moment in time, then the situation is simple: either a service was
1857 Expires 10th February 2007 Cheshire & Krochmal [Page 32]
1859 Internet Draft DNS-Based Service Discovery 10th August 2006
1862 discovered and appears in the list, or it was not, and does not.
1863 However, when our list is live and updates continuously with the
1864 discovery of new services, then this implies the corollary: when
1865 a service goes away, it needs to *disappear* from the service
1866 discovery list. Otherwise, the result would be unacceptable: the
1867 service discovery list would simply grow monotonically over time,
1868 and would require a periodic "refresh" (or complete dismissal and
1869 recreation) to clear out old stale data.
1871 4. With users getting to be in the habit of leaving service discovery
1872 windows open, these windows need to update not only in response
1873 to services coming and going, but also in response to changes
1874 in configuration and connectivity of the client machine itself.
1875 For example, if a user opens a service discovery window when no
1876 Ethernet cable is connected to the client machine, and the window
1877 appears empty with no discovered services, then when the user
1878 connects the cable the window should automatically populate with
1879 discovered services without requiring any explicit user action.
1880 If the user disconnects the Ethernet cable, all the services
1881 discovered via that network interface should automatically
1882 disappear. If the user switches from one 802.11 wireless base
1883 station to another, the service discovery window should
1884 automatically update to remove all the services discovered
1885 via the old wireless base station, and add all the services
1886 discovered via the new one.
1888 If these requirements seem to be setting an arbitrary and
1889 unreasonably high standard for service discovery, bear in mind that
1890 while it may have seemed that way to some, back in the 1990s when
1891 these ideas were first proposed, in the years since then Apple and
1892 other companies have shipped multiple implementations of DNS-SD/mDNS
1893 that meet and exceed these requirements. In the years since Apple
1894 shipped Mac OS X 10.2 Jaguar with the Open Source mDNSResponder
1895 daemon, this service discovery "live browsing" paradigm has been
1896 adopted and implemented in a wide range of Apple and third-party
1897 applications, including printer discovery, Safari discovery of
1898 devices with embedded web servers (for status and configuration),
1899 iTunes music sharing, iPhoto photo sharing, the iChat Bonjour buddy
1900 list, SubEthaEdit multi-user document editing, etc.
1902 With so many different applications demonstrating that the "live
1903 browsing" paradigm is clearly achievable, these four requirements
1904 should not be regarded as idealistic unattainable goals, but
1905 instead as the bare minimum baseline functionality that any
1906 credible service discovery protocol needs to achieve.
1915 Expires 10th February 2007 Cheshire & Krochmal [Page 33]
1917 Internet Draft DNS-Based Service Discovery 10th August 2006
1920 17. IPv6 Considerations
1922 IPv6 has no significant differences, except that the address of the
1923 SRV record's target host is given by the appropriate IPv6 address
1924 records instead of the IPv4 "A" record.
1927 18. Security Considerations
1929 DNSSEC [RFC 2535] should be used where the authenticity of
1930 information is important. Since DNS-SD is just a naming and usage
1931 convention for records in the existing DNS system, it has no specific
1932 additional security requirements over and above those that already
1933 apply to DNS queries and DNS updates.
1936 19. IANA Considerations
1938 This protocol builds on DNS SRV records [RFC 2782], and similarly
1939 requires IANA to assign unique application protocol names.
1940 Unfortunately, the "IANA Considerations" section of RFC 2782 says
1941 simply, "The IANA has assigned RR type value 33 to the SRV RR.
1942 No other IANA services are required by this document."
1943 Due to this oversight, IANA is currently prevented from carrying
1944 out the necessary function of assigning these unique identifiers.
1946 This document proposes the following IANA allocation policy for
1947 unique application protocol names:
1950 * Must be no more than fourteen characters long
1951 * Must consist only of:
1952 - lower-case letters 'a' - 'z'
1954 - the hyphen character '-'
1955 * Must begin and end with a lower-case letter or digit.
1956 * Must not already be assigned to some other protocol in the
1957 existing IANA "list of assigned application protocol names
1958 and port numbers" [ports].
1960 These identifiers are allocated on a First Come First Served basis.
1961 In the event of abuse (e.g. automated mass registrations, etc.),
1962 the policy may be changed without notice to Expert Review [RFC 2434].
1964 The textual nature of service/protocol names means that there are
1965 almost infinitely many more of them available than the finite set of
1966 65535 possible port numbers. This means that developers can produce
1967 experimental implementations using unregistered service names with
1968 little chance of accidental collision, providing service names are
1969 chosen with appropriate care. However, this document strongly
1973 Expires 10th February 2007 Cheshire & Krochmal [Page 34]
1975 Internet Draft DNS-Based Service Discovery 10th August 2006
1978 advocates that on or before the date a product ships, developers
1979 should properly register their service names.
1981 Some developers have expressed concern that publicly registering
1982 their service names (and port numbers today) with IANA before a
1983 product ships may give away clues about that product to competitors.
1984 For this reason, IANA should consider allowing service name
1985 applications to remain secret for some period of time, much as US
1986 patent applications remain secret for two years after the date of
1989 This proposed IANA allocation policy is not in force until this
1990 document is published as an RFC. In the meantime, unique application
1991 protocol names may be registered according to the instructions at
1992 <http://www.dns-sd.org/ServiceTypes.html>. As of August 2006, there
1993 are roughly 300 application protocols in currently shipping products
1994 that have been so registered as using DNS-SD for service discovery.
1999 The concepts described in this document have been explored, developed
2000 and implemented with help from Richard Brown, Erik Guttman, Paul
2001 Vixie, and Bill Woodcock.
2003 Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher,
2004 Roger Pantos and Kiren Sekar for their significant contributions.
2007 21. Deployment History
2009 The first implementations of DNS-Based Service Discovery and
2010 Multicast DNS were initially developed during the late 1990s,
2011 but the event that put them into the media spotlight was Steve Jobs
2012 demonstrating it live on stage in his keynote presentation opening
2013 Apple's annual Worldwide Developers Conference in May 2002, and
2014 announcing Apple's adoption of the technology throughout its hardware
2015 and software product line. Three months later, in August 2002, Apple
2016 shipped Mac OS X 10.2 Jaguar, and millions of end-users got their
2017 first exposure to Zero Configuration Networking with DNS-SD/mDNS
2018 in applications like Safari, iChat, and printer setup. A month later,
2019 in September 2002, Apple released the entire source code for the
2020 mDNS Responder daemon under its Darwin Open Source project, with
2021 code not just for Mac OS X, but also for a range of other platforms
2022 including Windows, VxWorks, Linux, Solaris, FreeBSD, etc.
2024 Many hardware makers were quick to see the benefits of Zero
2025 Configuration Networking. Printer makers especially were enthusiastic
2026 early adopters, and within a year every major printer manufacturer
2027 was shipping DNS-SD/mDNS-enabled network printers. If you've bought
2028 any network printer at all in the last few years, it was probably one
2031 Expires 10th February 2007 Cheshire & Krochmal [Page 35]
2033 Internet Draft DNS-Based Service Discovery 10th August 2006
2036 that supports DNS-SD/mDNS, even if you didn't know that at the time.
2037 For Mac OS X users, telling if you have DNS-SD/mDNS printers on your
2038 network is easy because they automatically appear in the "Bonjour"
2039 submenu in the "Print" dialog of every Mac application. Microsoft
2040 Windows users can get a similar experience by installing Bonjour for
2041 Windows (takes about 90 seconds, no restart required) and running the
2042 Bonjour for Windows Printer Setup Wizard [B4W].
2044 The Open Source community has produced several independent
2045 implementations of DNS-Based Service Discovery and Multicast DNS,
2046 some in C like Apple's mDNSResponder daemon, and others in a variety
2047 of different languages including Java, Python, Perl, and C#/Mono.
2050 22. Copyright Notice
2052 Copyright (C) The Internet Society (2006).
2054 This document is subject to the rights, licenses and restrictions
2055 contained in BCP 78, and except as set forth therein, the authors
2056 retain all their rights. For the purposes of this document,
2057 the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights
2058 in Contributions", published March 2005.
2060 This document and the information contained herein are provided on an
2061 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2062 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2063 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2064 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2065 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2066 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2089 Expires 10th February 2007 Cheshire & Krochmal [Page 36]
2091 Internet Draft DNS-Based Service Discovery 10th August 2006
2094 23. Normative References
2096 [ports] IANA list of assigned application protocol names and port
2097 numbers <http://www.iana.org/assignments/port-numbers>
2099 [RFC 1033] Lottor, M., "Domain Administrators Operations Guide",
2100 RFC 1033, November 1987.
2102 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
2103 Facilities", STD 13, RFC 1034, November 1987.
2105 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
2106 Specifications", STD 13, RFC 1035, November 1987.
2108 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
2109 Requirement Levels", RFC 2119, March 1997.
2111 [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the
2112 location of services (DNS SRV)", RFC 2782, February 2000.
2114 [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO
2115 10646", RFC 3629, November 2003.
2117 [UAX15] "Unicode Normalization Forms"
2118 http://www.unicode.org/reports/tr15/
2121 24. Informative References
2123 [B4W] Bonjour for Windows <http://www.apple.com/bonjour/>
2125 [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS",
2126 Internet-Draft (work in progress),
2127 draft-cheshire-dnsext-multicastdns-06.txt, August 2006.
2129 [NBP] Cheshire, S., and M. Krochmal,
2130 "Requirements for a Protocol to Replace AppleTalk NBP",
2131 Internet-Draft (work in progress),
2132 draft-cheshire-dnsext-nbp-05.txt, August 2006.
2134 [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP
2135 Vendor Extensions", RFC 2132, March 1997.
2137 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
2138 System (DNS UPDATE)", RFC 2136, April 1997.
2140 [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing
2141 an IANA Considerations Section in RFCs", RFC 2434,
2147 Expires 10th February 2007 Cheshire & Krochmal [Page 37]
2149 Internet Draft DNS-Based Service Discovery 10th August 2006
2152 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
2153 RFC 2535, March 1999.
2155 [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS)
2156 Dynamic Update", RFC 3007, November 2000.
2158 [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration
2159 Protocol (DHCP) Domain Search Option", RFC 3397, November
2162 [SOAP] Nilo Mitra, "SOAP Version 1.2 Part 0: Primer",
2163 W3C Proposed Recommendation, 24 June 2003
2164 http://www.w3.org/TR/2003/REC-soap12-part0-20030624
2166 [ZC] Williams, A., "Requirements for Automatic Configuration
2167 of IP Hosts", Internet-Draft (work in progress),
2168 draft-ietf-zeroconf-reqts-12.txt, September 2002.
2170 [ZCHP] Guttman, E., "Zeroconf Host Profile Applicability
2171 Statement", Internet-Draft (work in progress),
2172 draft-ietf-zeroconf-host-prof-01.txt, July 2001.
2175 25. Authors' Addresses
2178 Apple Computer, Inc.
2184 Phone: +1 408 974 3207
2185 EMail: rfc [at] stuartcheshire [dot] org
2189 Apple Computer, Inc.
2195 Phone: +1 408 974 4368
2196 EMail: marc [at] apple [dot] com
2205 Expires 10th February 2007 Cheshire & Krochmal [Page 38]