1 Document: draft-cheshire-dnsext-dns-sd-02.txt Stuart Cheshire
2 Category: Standards Track Apple Computer, Inc.
3 Expires 14th August 2004 Marc Krochmal
7 DNS-Based Service Discovery
9 <draft-cheshire-dnsext-dns-sd-02.txt>
14 This document is an Internet-Draft and is in full conformance with
15 all provisions of Section 10 of RFC2026. Internet-Drafts are
16 working documents of the Internet Engineering Task Force (IETF),
17 its areas, and its working groups. Note that other groups may
18 also distribute working documents as Internet-Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six
21 months and may be updated, replaced, or obsoleted by other documents
22 at any time. It is inappropriate to use Internet-Drafts as
23 reference material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html
31 Distribution of this memo is unlimited.
36 This document describes a convention for naming and structuring DNS
37 resource records. Given a type of service that a client is looking
38 for, and a domain in which the client is looking for that service,
39 this convention allows clients to discover a list of named instances
40 of that desired service, using only standard DNS queries. In short,
41 this is referred to as DNS-based Service Discovery, or DNS-SD.
58 Expires 14th August 2004 Cheshire & Krochmal [Page 1]
60 Internet Draft DNS-Based Service Discovery 14th February 2004
65 1. Introduction....................................................3
66 2. Conventions and Terminology Used in this Document...............3
67 3. Design Goals....................................................4
68 4. Service Instance Enumeration....................................5
69 4.1 Structured Instance Names.......................................5
70 4.2 User Interface Presentation.....................................7
71 4.3 Internal Handling of Names......................................7
72 4.4 What You See Is What You Get....................................7
73 4.5 Ordering of Service Instance Name Components....................9
74 5. Service Name Resolution........................................11
75 6. Data Syntax for DNS-SD TXT Records.............................12
76 6.1 General Format Rules for DNS TXT Records.......................12
77 6.2 DNS TXT Record Format Rules for use in DNS-SD..................12
78 6.3 DNS-SD TXT Record Size.........................................14
79 6.4 Rules for Names in DNS-SD Name/Value Pairs.....................14
80 6.5 Rules for Values in DNS-SD Name/Value Pairs....................16
81 6.6 Example TXT Record.............................................16
82 6.7 Version Tag....................................................17
83 7. Application Protocol Names.....................................18
84 8. Selective Instance Enumeration.................................19
85 9. Flagship Naming................................................10
86 10. Service Type Enumeration.......................................21
87 11. Populating the DNS with Information............................22
88 12. Relationship to Multicast DNS..................................22
89 13. Discovery of Browsing and Registration Domains.................23
90 14. DNS Additional Record Generation...............................24
91 15. Comparison with Alternative Service Discovery Protocols........25
92 16. Real Example...................................................27
93 17. IPv6 Considerations............................................28
94 18. Security Considerations........................................28
95 19. IANA Considerations............................................28
96 20. Acknowledgements...............................................29
97 21. Copyright......................................................29
98 22. Normative References...........................................30
99 23. Informative References.........................................30
100 24. Author's Addresses.............................................31
116 Expires 14th August 2004 Cheshire & Krochmal [Page 2]
118 Internet Draft DNS-Based Service Discovery 14th February 2004
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, all
143 the workload related to DNS-SD can be offloaded to a different
144 machine. This flexibility, to handle DNS-SD on the main DNS server,
145 or not, at the network administrator's discretion, is one of the
146 things that makes DNS-SD so compelling.
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].
164 2. Conventions and Terminology Used in this Document
166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
168 document are to be interpreted as described in "Key words for use in
169 RFCs to Indicate Requirement Levels" [RFC 2119].
174 Expires 14th August 2004 Cheshire & Krochmal [Page 3]
176 Internet Draft DNS-Based Service Discovery 14th February 2004
181 A good service discovery protocol needs to have many properties,
182 three of which are mentioned below:
184 (i) The ability to query for services of a certain type in a certain
185 logical domain and receive in response a list of named instances
186 (network browsing, or "Service Instance Enumeration").
188 (ii) Given a particular named instance, the ability to efficiently
189 resolve that instance name to the required information a client needs
190 to actually use the service, i.e. IP address and port number, at the
191 very least (Service Name Resolution).
193 (iii) Instance names should be relatively persistent. If a user
194 selects their default printer from a list of available choices today,
195 then tomorrow they should still be able to print on that printer --
196 even if the IP address and/or port number where the service resides
197 have changed -- without the user (or their software) having to repeat
198 the network browsing step a second time.
200 In addition, if it is to become successful, a service discovery
201 protocol should be so simple to implement that virtually any
202 device capable of implementing IP should not have any trouble
203 implementing the service discovery software as well.
205 These goals are discussed in more detail in the remainder of this
206 document. A more thorough treatment of service discovery requirements
207 may be found in "Requirements for a Protocol to Replace AppleTalk
208 NBP" [NBP]. That document draws upon examples from two decades of
209 operational experience with AppleTalk Name Binding Protocol to
210 develop a list of universal requirements which are broadly applicable
211 to any potential service discovery protocol.
232 Expires 14th August 2004 Cheshire & Krochmal [Page 4]
234 Internet Draft DNS-Based Service Discovery 14th February 2004
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 laid
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 the
279 next level directory, and so on. A fully-qualified domain name is
280 read from right to left, beginning with the dot on the right -- the
281 root label -- and then the top level domain to the left of that, and
282 the second level domain to the left of that, and so on. If the fully-
283 qualified domain name "_ipp._tcp.example.com." were expressed as a
284 file system path name, it would be "/com/example/_tcp/_ipp".)
290 Expires 14th August 2004 Cheshire & Krochmal [Page 5]
292 Internet Draft DNS-Based Service Discovery 14th February 2004
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 UTF-8-encoded text [RFC 2279]. It is a
303 user-friendly name, meaning that it is allowed to contain any
304 characters, without restriction, including spaces, upper case, lower
305 case, punctuation -- including dots -- accented characters, non-roman
306 text, and anything else that may be represented using UTF-8.
307 DNS recommends guidelines for allowable characters for host names
308 [RFC 1033][RFC 1034][RFC 1035], but Service Instance Names are not
309 host names. Service Instance Names are not intended to ever be typed
310 in by a normal user; the user selects a Service Instance Name by
311 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 can
328 be encoded with no more than three octets of UTF-8 encoding. This
329 means that an Instance name can contain up to 21 Kanji characters,
330 which is a sufficiently expressive name for most purposes.
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 service pair is the
335 application protocol name, as recorded in the IANA list of assigned
336 application protocol names and port numbers [ports]. The second label
337 of the service pair is either "_tcp" or "_udp", depending on the
338 transport protocol used by the application.
340 The <Domain> portion of the Service Instance Name is a conventional
341 DNS domain name, consisting of as many labels as appropriate. For
342 example, "apple.com.", "cs.stanford.edu.", and "eng.us.ibm.com." are
343 all valid domain names for the <Domain> portion of the Service
348 Expires 14th August 2004 Cheshire & Krochmal [Page 6]
350 Internet Draft DNS-Based Service Discovery 14th February 2004
353 4.2 User Interface Presentation
355 The names resulting from the PTR lookup are presented to the user in
356 a list for the user to select one (or more). Typically only the first
357 label is shown (the user-friendly <Instance> portion of the name). In
358 the common case, the <Service> and <Domain> are already known to the
359 user, these having been provided by the user in the first place, by
360 the act of indicating the service being sought, and the domain in
361 which to look for it. Note: The software handling the response
362 should be careful not to make invalid assumptions though, since it
363 *is* possible, though rare, for a service enumeration in one domain
364 to return the names of services in a different domain. Similarly,
365 when using subtypes (see "Selective Instance Enumeration") the
366 <Service> of the discovered instance my not be exactly the same as
367 the <Service> that was requested.
369 Having chosen the desired named instance, the Service Instance Name
370 may then be used immediately, or saved away in some persistent
371 user-preference data structure for future use, depending on what is
372 appropriate for the application in question.
375 4.3 Internal Handling of Names
377 If the <Instance>, <Service> and <Domain> portions are internally
378 concatenated together into a single string, then care must be taken
379 with the <Instance> portion, since it is allowed to contain any
380 characters, including dots.
382 Any dots in the <Instance> portion should be escaped by preceeding
383 them with a backslash ("." becomes "\."). Likewise, any backslashes
384 in the <Instance> portion should also be escaped by preceeding them
385 with a backslash ("\" becomes "\\"). Having done this, the three
386 components of the name may be safely concatenated. The
387 backslash-escaping allows literal dots in the name (escaped) to be
388 distinguished from label-separator dots (not escaped).
390 The resulting concatenated string may be safely passed to standard
391 DNS APIs like res_query(), which will interpret the string correctly
392 provided it has been escaped correctly, as described here.
395 4.4 What You See Is What You Get
397 Some service discovery protocols decouple the true service identifier
398 from the name presented to the user. The true service identifier used
399 by the protocol is an opaque unique id, often represented using a
400 long string of hexadecimal digits, and should never be seen by the
401 typical user. The name presented to the user is merely one of the
402 ephemeral attributes attached to this opaque identifier.
406 Expires 14th August 2004 Cheshire & Krochmal [Page 7]
408 Internet Draft DNS-Based Service Discovery 14th February 2004
411 The problem with this approach is that it decouples user perception
414 * What happens if there are two service instances, with different
415 unique ids, but they have inadvertently been given the same
416 user-visible name? If two instances appear in an on-screen list
417 with the same name, how does the user know which is which?
419 * Suppose a printer breaks down, and the user replaces it with
420 another printer of the same make and model, and configures the new
421 printer with the exact same name as the one being replaced:
422 "Stuart's Printer". Now, when the user tries to print, the
423 on-screen print dialog tells them that their selected default
424 printer is "Stuart's Printer". When they browse the network to see
425 what is there, they see a printer called "Stuart's Printer", yet
426 when the user tries to print, they are told that the printer
427 "Stuart's Printer" can't be found. The hidden internal unique id
428 that the software is trying to find on the network doesn't match
429 the hidden internal unique id of the new printer, even though its
430 apparent "name" and its logical purpose for being there are the
431 same. To remedy this, the user typically has to delete the print
432 queue they have created, and then create a new (apparently
433 identical) queue for the new printer, so that the new queue will
434 contain the right hidden internal unique id. Having all this hidden
435 information that the user can't see makes for a confusing and
436 frustrating user experience, and exposing long ugly hexadecimal
437 strings to the user and forcing them to understand what they mean
440 * Suppose an existing printer is moved to a new department, and given
441 a new name and a new function. Changing the user-visible name of
442 that piece of hardware doesn't change its hidden internal unique
443 id. Users who had previously created print queues for that printer
444 will still be accessing the same hardware by its unique id, even
445 though the logical service that used to be offered by that hardware
448 To solve these problems requires the user or administrator to be
449 aware of the supposedly hidden unique id, and to set its value
450 correctly as hardware is moved around, repurposed, or replaced,
451 thereby contradicting the notion that it is a hidden identifier that
452 human users never need to deal with. Requiring the user to unserstand
453 this expert behind-the-scenes knowledge of what is *really* going on
454 is just one more burden placed on the user when they are trying to
455 diagnose why their computers and network devices are not working as
458 These anomalies and counter-intuitive behaviours can be eliminated by
459 maintaining a tight bidirectional one-to-one mapping between what the
460 user sees on the screen and what is really happening "behind the
464 Expires 14th August 2004 Cheshire & Krochmal [Page 8]
466 Internet Draft DNS-Based Service Discovery 14th February 2004
469 curtain". If something is configured incorrectly, then that is
470 apparent in the familiar day-to-day user interface that everyone
471 understands, not in some little-known rarely-used "expert" interface.
473 In summary: The user-visible name is the primary identifier for a
474 service. If the user-visible name is changed, then conceptually the
475 service being offered is a different logical service -- even though
476 the hardware offering the service stayed the same. If the
477 user-visible name doesn't change, then conceptually the service being
478 offered is the same logical service -- even if the hardware offering
479 the service is new hardware brought in to replace some old equipment.
481 There are certainly arguments on both sides of this debate.
482 Nonetheless, the designers of any service discovery protocol have
483 to make a choice between between having the primary identifiers be
484 hidden, or having them be visible, and these are the reasons that we
485 chose to make them visible. We're not claiming that there are no
486 disadvantages of having primary identifiers be visible. We considered
487 both alternatives, and we believe that the few disadvantages
488 of visible identifiers are far outweighed by the many problems
489 caused by use of hidden identifiers.
492 4.5 Ordering of Service Instance Name Components
494 There have been questions about why services are named using DNS
495 Service Instance Names of the form:
497 Service Instance Name = <Instance> . <Service> . <Domain>
501 Service Instance Name = <Service> . <Instance> . <Domain>
503 There are three reasons why it is beneficial to name service
504 instances with the parent domain as the most-significant (rightmost)
505 part of the name, then the abstract service type as the nextmost
506 significant, and then the specific instance name as the
507 least-significant (leftmost) part of the name:
510 4.5.1. Semantic Structure
512 The facility being provided by browsing ("Service Instance
513 Enumeration") is effectively enumerating the leaves of a tree
514 structure. A given domain offers zero or more services. For each of
515 those service types, there may be zero or more instances of that
522 Expires 14th August 2004 Cheshire & Krochmal [Page 9]
524 Internet Draft DNS-Based Service Discovery 14th February 2004
527 The user knows what type of service they are seeking. (If they are
528 running an FTP client, they are looking for FTP servers. If they have
529 a document to print, they are looking for entities that speak some
530 known printing protocol.) The user knows in which organizational or
531 geographical domain they wish to search. (The user does not want a
532 single flat list of every single printer on the planet, even if such
533 a thing were possible.) What the user does not know in advance is
534 whether the service they seek is offered in the given domain, or if
535 so, how many instances are offered, and the names of those instances.
536 Hence having the instance names be the leaves of the tree is
537 consistent with this semantic model.
539 Having the service types be the terminal leaves of the tree would
540 imply that the user knows the domain name, and already knows the
541 name of the service instance, but doesn't have any idea what the
542 service does. We would argue that this is a less useful model.
545 4.5.2. Network Efficiency
547 When a DNS response contains multiple answers, name compression works
548 more effectively if all the names contain a common suffix. If many
549 answers in the packet have the same <Service> and <Domain>, then each
550 occurrence of a Service Instance Name can be expressed using only the
551 <Instance> part followed by a two-byte compression pointer
552 referencing a previous appearance of "<Service>.<Domain>". This
553 efficiency would not be possible if the <Service> component appeared
557 4.5.3. Operational Flexibility
559 This name structure allows subdomains to be delegated along logical
560 service boundaries. For example, the network administrator at Example
561 Co. could choose to delegate the "_tcp.example.com." subdomain to a
562 different machine, so that the machine handling service discovery
563 doesn't have to be the same as the machine handling other day-to-day
564 DNS operations. (It *can* be the same machine if the administrator so
565 chooses, but the point is that the administrator is free to make that
566 choice.) Furthermore, if the network administrator wishes to delegate
567 all information related to IPP printers to a machine dedicated to
568 that specific task, this is easily done by delegating the
569 "_ipp._tcp.example.com." subdomain to the desired machine. It is also
570 convenient to set security policies on a per-zone/per-subdomain
571 basis. For example, the administrator may choose to enable DNS
572 Dynamic Update [RFC 2136] [RFC 3007] for printers registering in the
573 "_ipp._tcp.example.com." subdomain, but not for other
574 zones/subdomains. This easy flexibility would not exist if the
575 <Service> component appeared first in each name.
580 Expires 14th August 2004 Cheshire & Krochmal [Page 10]
582 Internet Draft DNS-Based Service Discovery 14th February 2004
585 5. Service Name Resolution
587 Given a particular Service Instance Name, when a client needs to
588 contact that service, it sends a DNS query for the SRV record of
591 The result of the DNS query is a SRV record giving the port number
592 and target host where the service may be found.
594 The use of SRV records is very important. There are only 65535 TCP
595 port numbers available. These port numbers are being allocated
596 one-per-application-protocol at an alarming rate. Some protocols like
597 the X Window System have a block of 64 TCP ports allocated
598 (6000-6063). If we start allocating blocks of 64 TCP ports at a time,
599 we will run out even faster. Using a different TCP port for each
600 different instance of a given service on a given machine is entirely
601 sensible, but allocating large static ranges, as was done for X, is a
602 very inefficient way to manage a limited resource. On any given host,
603 most TCP ports are reserved for services that will never run on that
604 particular host. This is very poor utilization of the limited port
605 space. Using SRV records allows each host to allocate its available
606 port numbers dynamically to those services running on that host that
607 need them, and then advertise the allocated port numbers via SRV
608 records. Allocating the available listening port numbers locally
609 on a per-host basis as needed allows much better utilization of the
610 available port space than today's centralized global allocation.
612 In some environments there may be no compelling reason to assign
613 managed names to every host, since every available service is
614 accessible by name anyway, as a first-class entity in its own right.
615 However, the DNS packet format and record format still require a host
616 name to link the target host referenced in the SRV record to the
617 address records giving the IPv4 and/or IPv6 addresses for that
618 hardware. In the case where no natural host name is available, the
619 SRV record may give its own name as the name of the target host, and
620 then the requisite address records may be attached to that same name.
621 It is perfectly permissible for a single name in the DNS hierarchy to
622 have multiple records of different type attached. (The only
623 restriction being that a given name may not have both a CNAME record
624 and other records at the same time.)
626 In the event that more than one SRV is returned, clients MUST
627 correctly interpret the priority and weight fields -- i.e. Lower
628 numbered priority servers should be used in preference to higher
629 numbered priority servers, and servers with equal priority should be
630 selected randomly in proportion to their relative weights.
638 Expires 14th August 2004 Cheshire & Krochmal [Page 11]
640 Internet Draft DNS-Based Service Discovery 14th February 2004
643 6. Data Syntax for DNS-SD TXT Records
645 Some services discovered via Service Instance Enumeration may need
646 more than just an IP address and port number to properly identify the
647 service. For example, printing via the LPR protocol often specifies a
648 queue name. This queue name is typically short and cryptic, and need
649 not be shown to the user. It should be regarded the same way as the
650 IP address and port number -- it is one component of the addressing
651 information required to identify a specific instance of a service
652 being offered by some piece of hardware. Similarly, a file server may
653 have multiple volumes, each identified by its own volume name. A Web
654 server typically has multiple pages, each identified by its own URL.
655 In these cases, the necessary additional data is stored in a TXT
656 record with the same name as the SRV record. The specific nature of
657 that additional data, and how it is to be used, is service-dependent,
658 but the overall syntax of the data in the TXT record is standardized,
662 6.1 General Format Rules for DNS TXT Records
664 A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total
665 length is indicated by the length given in the resource record header
666 in the DNS message. There is no way to tell directly from the data
667 alone how long it is (e.g. there is no length count at the start, or
668 terminating NULL byte at the end). (Note that when using Multicast
669 DNS [mDNS] the maximum packet size is 9000 bytes, which imposes an
670 upper limit on the size of TXT records of about 8800 bytes.)
672 The format of the data within a DNS TXT record is zero or more
673 strings, packed together in memory without any intervening gaps or
674 padding bytes for word alignment.
676 The format of each constituent string within the DNS TXT record is a
677 single length byte, followed by 0-255 bytes of text data.
679 These format rules are defined in Section 3.3.14 of RFC 1035, and are
680 not specific to DNS-SD. DNS-SD simply specifies a usage convention
681 for what data should be stored in those constituent strings.
684 6.2 DNS TXT Record Format Rules for use in DNS-SD
686 DNS-SD uses DNS TXT records to store arbitrary name/value pairs
687 conveying additional information about the named service. Each
688 name/value pair is encoded as its own constituent string within the
689 DNS TXT record, in the form "name=value". Everything up to the first
690 '=' character is the name. Everything after the first '=' character
691 to the end of the string (including subsequent '=' characters, if
692 any) is the value. Specific rules governing names and values are
693 given below. Each author defining a DNS-SD profile for discovering
696 Expires 14th August 2004 Cheshire & Krochmal [Page 12]
698 Internet Draft DNS-Based Service Discovery 14th February 2004
701 instances of a particular type of service should define the base set
702 of name/value attributes that are valid for that type of service.
704 Using this standardized name/value syntax within the TXT record makes
705 it easier for these base definitions to be expanded later by defining
706 additional named attributes. If an implementation sees unknown
707 attribute names in a service TXT record, it MUST silently ignore them.
709 The TCP (or UDP) port number of the service, and target host name,
710 are given in the SRV record. This information -- target host name and
711 port number -- MUST NOT be duplicated using name/value attributes in
714 The intention of DNS-SD TXT records is to convey a small amount of
715 useful additional information about a service. Ideally it SHOULD NOT
716 be necessary for a client to retrieve this additional information
717 before it can usefully establish a connection to the service. For a
718 well-designed TCP-based application protocol, it should be possible,
719 knowing only the host name and port number, to open a connection to
720 that listening process, and then perform version- or feature-
721 negotiation to determine the capabilities of the service instance.
722 For example, when connecting to an AppleShare server over TCP, the
723 client enters into a protocol exchange with the server to determine
724 which version of the AppleShare protocol the server implements, and
725 which optional features or capabilities (if any) are available. For a
726 well-designed application protocol, clients should be able to connect
727 and use the service even if there is no information at all in the TXT
728 record. In this case, the information in the TXT record should be
729 viewed as a performance optimization -- when a client discovers many
730 instances of a service, the TXT record allows the client to know some
731 rudimentary information about each instance without having to open a
732 TCP connection to each one and interrogate every service instance
733 separately. Extreme care should be taken when doing this to ensure
734 that the information in the TXT record is in agreement with the
735 information retrieved by a client connecting over TCP.
737 There are legacy protocols which provide no feature negotiation
738 capability, and in these cases it may be useful to convey necessary
739 information in the TXT record. For example, when printing using the
740 old Unix LPR (port 515) protocol, the LPR service provides no way for
741 the client to determine whether a particular printer accepts
742 PostScript, or what version of PostScript, etc. In this case it is
743 appropriate to embed this information in the TXT record, because the
744 alternative is worse -- passing around written instructions to the
745 users, arcane manual configuration of "/etc/printcap" files, etc.
754 Expires 14th August 2004 Cheshire & Krochmal [Page 13]
756 Internet Draft DNS-Based Service Discovery 14th February 2004
759 6.3 DNS-SD TXT Record Size
761 The total size of a typical DNS-SD TXT record is intended to be small
762 -- 200 bytes or less.
764 In cases where more data is justified (e.g. LPR printing), keeping
765 the total size under 400 bytes should allow it to fit in a single
766 standard 512-byte DNS message. (This standard DNS message size is
767 defined in RFC 1035.)
769 In extreme cases where even this is not enough, keeping the size of
770 the TXT record under 1300 bytes should allow it to fit in a single
771 1500-byte Ethernet packet.
773 Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this
777 6.4 Rules for Names in DNS-SD Name/Value Pairs
779 The "Name" MUST be at least one character. Strings beginning with an
780 '=' character (i.e. the name is missing) SHOULD be silently ignored.
782 The characters of "Name" MUST be printable US-ASCII values
783 (0x20-0x7E), excluding '=' (0x3D).
785 Spaces in the name are significant, whether leading, trailing, or in
786 the middle -- so don't include any spaces unless you really intend
789 Case is ignored when interpreting a name, so "papersize=A4",
790 "PAPERSIZE=A4" and "Papersize=A4" are all identical.
792 If there is no '=', then it is a boolean attribute, and is simply
793 identified as being present, with no value.
795 Unless specified otherwise by a particular DNS-SD profile, a given
796 attribute name may appear at most once in a TXT record. If a client
797 receives a TXT record containing the same attribute name more than
798 once, then the client SHOULD silently ignore all but the first
799 occurrence of that attribute. For client implementations that process
800 a DNS-SD TXT record from start to end, placing name/value pairs into
801 a hash table, using the name as the hash table key, this means that
802 if the implementation attempts to add a new name/value pair into the
803 table and finds an entry with the same name already present, then the
804 new entry being added should be silently discarded instead. For
805 client implementations that retrieve name/value pairs by searching
806 the TXT record for the requested name, they should search the TXT
807 record from the start, and simply return the first matching name they
812 Expires 14th August 2004 Cheshire & Krochmal [Page 14]
814 Internet Draft DNS-Based Service Discovery 14th February 2004
817 When examining a TXT record for a given named attribute, there are
818 therefore four broad categories of results which may be returned:
820 * Attribute not present (Absent)
822 * Attribute present, with no value
823 (e.g. "Anon Allowed" -- server allows anonymous connections)
825 * Attribute present, with empty value (e.g. "Installed PlugIns=" --
826 server supports plugins, but none are presently installed)
828 * Attribute present, with non-empty value
829 (e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4")
831 Each author defining a DNS-SD profile for discovering instances of a
832 particular type of service should define the interpretation of these
833 different kinds of result. For example, for some keys, there may be
834 a natural true/false boolean interpretation:
836 * Present implies 'true'
837 * Absent implies 'false'
839 For other keys it may be sensible to define other semantics, such as
840 value/no-value/unknown:
842 * Present with value implies that value.
843 E.g. "Color=4" for a four-color ink-jet printer,
844 or "Color=6" for a six-color ink-jet printer.
846 * Present with empty value implies 'false'. E.g. Not a color printer.
848 * Absent implies 'Unknown'. E.g. A print server connected to some
849 unknown printer where the print server doesn't actually know if the
850 printer does color or not -- which gives a very bad user experience
851 and should be avoided wherever possible.
853 (Note that this is a hypothetical example, not an example of actual
854 name/value keys used by DNS-SD network printers.)
856 As a general rule, attribute names that contain no dots are defined
857 as part of the open-standard definition written by the person or
858 group defining the DNS-SD profile for discovering that particular
859 service type. Vendor-specific extensions should be given names of the
860 form "keyname.company.com=value", using a domain name legitimately
861 registered to the person or organization creating the vendor-specific
862 key. This reduces the risk of accidental conflict if different
863 organizations each define their own vendor-specific keys.
870 Expires 14th August 2004 Cheshire & Krochmal [Page 15]
872 Internet Draft DNS-Based Service Discovery 14th February 2004
875 6.5 Rules for Values in DNS-SD Name/Value Pairs
877 If there is an '=', then everything after the first '=' to the end of
878 the string is the value. The value can contain any eight-bit values
879 including '='. Leading or trailing spaces are part of the value, so
880 don't put them there unless you intend them to be there. Any
881 quotation marks around the value are part of the value, so don't put
882 them there unless you intend them to be part of the value.
884 The value is opaque binary data. Often the value for a particular
885 attribute will be US-ASCII (or UTF-8) text, but it is legal for a
886 value to be any binary data. For example, if the value of a key is an
887 IPv4 address, that address should simply be stored as four bytes of
888 binary data, not as a variable-length 7-15 byte ASCII string giving
889 the address represented in textual dotted decimal notation.
891 Generic debugging tools should generally display all attribute values
892 as a hex dump, with accompanying text alongside displaying the UTF-8
893 interpretation of those bytes, except for attributes where the
894 debugging tool has embedded knowledge that the value is some other
897 Authors defining DNS-SD profiles SHOULD NOT convert binary attribute
898 data types into printable text (e.g. using hexadecimal, Base64 or UU
899 encoding) merely for the sake of making the data be printable text
900 when seen in a generic debugging tool. Doing this simply bloats the
901 size of the TXT record, without atually making the data any more
902 understandable to someone looking at it in a generic debugging tool.
905 6.6 Example TXT Record
907 The TXT record below contains three syntactically valid name/value
908 pairs. (The meaning of these name/value pairs, if any, would depend
909 on the definitions pertaining to the service in question that is
912 ---------------------------------------------------------------
913 | 0x0A | name=value | 0x08 | paper=A4 | 0x0E | DNS-SD Is Cool |
914 ---------------------------------------------------------------
928 Expires 14th August 2004 Cheshire & Krochmal [Page 16]
930 Internet Draft DNS-Based Service Discovery 14th February 2004
935 It is recommended that authors defining DNS-SD profiles include an
936 attribute of the form "txtvers=xxx" in their definition, and require
937 it to be the first name/value pair in the TXT record. This
938 information in the TXT record can be useful to help clients maintain
939 backwards compatibility with older implementations if it becomes
940 necessary to change or update the specification over time. Even if
941 the profile author doesn't anticipate the need for any future
942 incompatible changes, having a version number in the specification
943 provides useful insurance should incompatible changes become
944 unavoidable. Clients SHOULD ignore TXT records with a txtvers number
945 higher (or lower) than the version(s) they know how to interpret.
947 Note that the version number in the txtvers tag describes the version
948 of the TXT record specification being used to create this TXT record,
949 not the version of the application protocol that will be used if the
950 client subsequently decides to contact that service. Ideally, every
951 DNS-SD TXT record specification starts at txtvers=1 and stays that
952 way forever. Improvements can be made by defining new keys that older
953 clients silently ignore. The only reason to increment the version
954 number is if the old specification is subsequently found to be so
955 horribly broken that there's no way to do a compatible forward
956 revision, so the txtvers number has to be incremented to tell all the
957 old clients they should just not even try to understand this new TXT
960 If there is a need to indicate which version number(s) of the
961 application protocol the service implements, the recommended key
962 name for this is "protovers".
986 Expires 14th August 2004 Cheshire & Krochmal [Page 17]
988 Internet Draft DNS-Based Service Discovery 14th February 2004
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 the Application
996 Protocol Name, and the second label is either "_tcp" or "_udp".
998 Wise selection of the Application Protocol Name is very important,
999 and the choice is not always as obvious as it may appear.
1001 In some cases, the Application Protocol Name merely names and refers
1002 to the on-the-wire message format and semantics being used. FTP is
1003 "ftp", IPP printing is "ipp", and so on.
1005 However, it is common to "borrow" an existing protocol and repurpose
1006 it for a new task. This is entirely sensible and sound engineering
1007 practice, but that doesn't mean that the new protocol is providing
1008 the same semantic service as the old one, even if it borrows the same
1009 message formats. For example, the local network music playing
1010 protocol implemented by iTunes on Macintosh and Windows is little
1011 more than "HTTP GET" commands. However, that does *not* mean that it
1012 is sensible or useful to try to access one of these music servers by
1013 connecting to it with a standard web browser. Consequently, the
1014 DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp"
1015 (Digital Audio Access Procol), not "_http._tcp". Advertising
1016 "_http._tcp" service would cause iTunes servers to show up in
1017 conventional Web browsers (Safari, Camino, OmniWeb, Opera, Netscape,
1018 Internet Explorer, etc.) which is little use since it offers no pages
1019 containing human-readable content. Similarly, browsing for
1020 "_http._tcp" service would cause iTunes to find generic web servers,
1021 such as the embedded web servers in devices like printers, which is
1022 little use since printers generally don't have much music to offer.
1024 Similarly, NFS is built on top of SUN RPC, but that doesn't mean it
1025 makes sense for an NFS server to advertise that it provides "SUN RPC"
1026 service. Likewise, Microsoft SMB file service is built on top of
1027 Netbios running over IP, but that doesn't mean it makes sense for an
1028 SMB file server to advertise that it provides "Netbios-over-IP"
1029 service. The DNS-SD name of a service needs to encapsulate both the
1030 "what" (semantics) and the "how" (protocol implementation) of the
1031 service, since knowledge of both is necessary for a client to
1032 usefully use the service. Merely advertising that a service was built
1033 on top of SUN RPC is no use if the client has no idea what the
1034 service actually does.
1036 Another common mistake is to assume that the service type advertised
1037 by iTunes should be "_daap._http._tcp." This is also incorrect. Part
1038 of the confusion here is that the presence of "_tcp" or "_udp" in the
1039 <Service> portion of a Service Instance Name has led people to assume
1040 that the structure of a service name has to reflect the internal
1041 structure of how the protocol was implemented. This is not correct.
1044 Expires 14th August 2004 Cheshire & Krochmal [Page 18]
1046 Internet Draft DNS-Based Service Discovery 14th February 2004
1049 The "_tcp" or "_udp" should be regarded as little more than
1050 boilerplate text, and care should be taken not to attach too much
1051 importance to it. Some might argue that the "_tcp" or "_udp" should
1052 not be there at all, but this format is defined by RFC 2782, and
1053 that's not going to change. In addition, the presence of "_tcp" has
1054 the useful side-effect that it provides a convenient delegation point
1055 to hand off control to a different DNS server, if so desired.
1058 8. Selective Instance Enumeration
1060 This document does not attempt to define an arbitrary query language
1061 for service discovery, nor do we believe one is necessary.
1063 However, there are some circumstances where narrowing the list of
1064 results may be useful. A Web browser client that is able to retrieve
1065 HTML documents via HTTP and display them may also be able to retrieve
1066 HTML documents via FTP and display them, but only in the case of FTP
1067 servers that allow anonymous login. For that Web browser, discovering
1068 all FTP servers on the network is not useful. The Web browser only
1069 wants to discover FTP servers that it is able to talk to. In this
1070 case, a subtype of "_ftp._tcp" could be defined. Instead of issuing a
1071 query for "_ftp._tcp.<Domain>", the Web browser issues a query for
1072 "_anon._ftp._tcp.<Domain>", where "_anon" is a defined subtype of
1073 "_ftp._tcp". The response to this query only includes the names of
1074 SRV records for FTP servers that are willing to allow anonymous
1077 Note that the FTP server's Service Instance Name is unchanged -- it
1078 is still something of the form "The Server._ftp._tcp.example.com."
1079 The subdomain in which FTP server SRV records are registered defines
1080 the namespace within which FTP server names are unique. Additional
1081 subtypes (e.g. "_anon") of the basic service type (e.g. "_ftp._tcp")
1082 serve to narrow the list of results, not to create more namespace.
1084 As with the TXT record name/value pairs, the list of possible
1085 subtypes, if any, are defined and specified separately for each basic
1102 Expires 14th August 2004 Cheshire & Krochmal [Page 19]
1104 Internet Draft DNS-Based Service Discovery 14th February 2004
1109 In some cases, there may be several network protocols available which
1110 all perform roughly the same logical function. For example, the
1111 printing world has the LPR protocol, and the Internet Printing
1112 Protocol (IPP), both of which cause printed sheets to be emitted from
1113 printers in much the same way. In addition, many printer vendors send
1114 their own proprietary page description language (PDL) data over a TCP
1115 connection to TCP port 9100, herein referred to as the
1116 "pdl-datastream" protocol. In an ideal world we would have only one
1117 network printing protocol, and it would be sufficiently good that no
1118 one felt a compelling need to invent a different one. However, in
1119 practice, multiple legacy protocols do exist, and a service discovery
1120 protocol has to accommodate that.
1122 Many printers implement all three printing protocols: LPR, IPP, and
1123 pdl-datastream. For the benefit of clients that may speak only one of
1124 those protocols, all three are advertised.
1126 However, some clients may implement two, or all three of those
1127 printing protocols. When a client looks for all three service types
1128 on the network, it will find three distinct services -- an LPR
1129 service, an IPP service, and a pdl-datastream service -- all of which
1130 cause printed sheets to be emitted from the same physical printer.
1132 In the case of multiple protocols like this that all perform
1133 effectively the same function, the client should suppress duplicate
1134 names and display each name only once. When the user prints to a
1135 given named printer, the printing client is responsible for choosing
1136 the protocol which will best achieve the desired effect, without, for
1137 example, requiring the user to make a manual choice between LPR and
1140 As described so far, this all works very well. However, consider some
1141 future printer that only supports IPP printing, and some other future
1142 printer that only supports pdl-datastream printing. The name spaces
1143 for different service types are intentionally disjoint -- it is
1144 acceptable and desirable to be able to have both a file server called
1145 "Sales Department" and a printer called "Sales Department". However,
1146 it is not desirable, in the common case, to have two different
1147 printers both called "Sales Department", just because those printers
1148 are implementing different protocols.
1150 To help guard against this, when there are two or more network
1151 protocols which perform roughly the same logical function, one of the
1152 protocols is declared the "flagship" of the fleet of related
1153 protocols. Typically the flagship protocol is the oldest and/or
1154 best-known protocol of the set.
1156 If a device does not implement the flagship protocol, then it instead
1157 creates a placeholder SRV record (priority=0, weight=0, port=0,
1160 Expires 14th August 2004 Cheshire & Krochmal [Page 20]
1162 Internet Draft DNS-Based Service Discovery 14th February 2004
1165 target host = hostname of device) with that name. If, when it
1166 attempts to create this SRV record, it finds that a record with the
1167 same name already exists, then it knows that this name is already
1168 taken by some entity implementing at least one of the protocols from
1169 the class, and it must choose another. If no SRV record already
1170 exists, then the act of creating it stakes a claim to that name so
1171 that future devices in the same class will detect a conflict when
1172 they try to use it. The SRV record needs to contain the target host
1173 name in order for the conflict detection rules to operate. If two
1174 different devices were to create placeholder SRV records both using a
1175 null target host name (just the root label), then the two SRV records
1176 would be seen to be in agreement so no conflict would be registered.
1178 By defining a common well-known flagship protocol for the class,
1179 future devices that may not even know about each other's protocols
1180 establish a common ground where they can coordinate to verify
1181 uniqueness of names.
1183 No PTR record is created advertising the presence of empty flagship
1184 SRV records, since they do not represent a real service being
1188 10. Service Type Enumeration
1190 In general, clients are not interested in finding *every* service on
1191 the network, just the services that the client knows how to talk to.
1192 (Software designers may *think* there's some value to finding *every*
1193 service on the network, but that's just wooly thinking.)
1195 However, for problem diagnosis and network management tools, it may
1196 be useful for network administrators to find the list of advertised
1197 service types on the network, even if those service names are just
1198 opaque identifiers and not particularly informative in isolation.
1200 For this reason, a special meta-query is defined. A DNS query for
1201 PTR records with the name "_services._dns-sd._udp.<Domain>" yields
1202 a list of PTR records, where the rdata of each PTR record is the
1203 name of a service type. A subsequent query for PTR records with
1204 one of those names yields a list of instances of that service type.
1218 Expires 14th August 2004 Cheshire & Krochmal [Page 21]
1220 Internet Draft DNS-Based Service Discovery 14th February 2004
1223 11. Populating the DNS with Information
1225 How the SRV and PTR records that describe services and allow them to
1226 be enumerated make their way into the DNS is outside the scope of
1227 this document. However, it can happen easily in any of a number of
1230 On some networks, the administrator might manually enter the records
1231 into the name server's configuration file.
1233 A network monitoring tool could output a standard zone file to be
1234 read into a conventional DNS server. For example, a tool that can
1235 find Apple LaserWriters using AppleTalk NBP could find the list of
1236 printers, communicate with each one to find its IP address,
1237 PostScript version, installed options, etc., and then write out a DNS
1238 zone file describing those printers and their capabilities using DNS
1239 resource records. That information would then be available to DNS-SD
1240 clients that don't implement AppleTalk NBP, and don't want to.
1242 Future IP printers could use Dynamic DNS Update [RFC 2136] to
1243 automatically register their own SRV and PTR records with the DNS
1246 A printer manager device which has knowledge of printers on the
1247 network through some other management protocol could also use Dynamic
1248 DNS Update [RFC 2136].
1250 Alternatively, a printer manager device could implement enough of the
1251 DNS protocol that it is able to answer DNS queries directly, and
1252 Example Co.'s main DNS server could delegate the
1253 _ipp._tcp.example.com subdomain to the printer manager device.
1255 Zeroconf printers answer Multicast DNS queries on the local link
1256 for appropriate PTR and SRV names ending with ".local." [mDNS]
1259 12. Relationship to Multicast DNS
1261 DNS-Based Service Discovery is only peripherally related to Multicast
1262 DNS, in that the standard unicast DNS queries used by DNS-SD may also
1263 be performed using multicast when appropriate, which is particularly
1264 beneficial in Zeroconf environments [ZC].
1276 Expires 14th August 2004 Cheshire & Krochmal [Page 22]
1278 Internet Draft DNS-Based Service Discovery 14th February 2004
1281 13. Discovery of Browsing and Registration Domains (Domain Enumeration)
1283 One of the main reasons for DNS-Based Service Discovery is so that
1284 when a visiting client (e.g. a laptop computer) arrives at a new
1285 network, it can discover what services are available on that network
1286 without manual configuration. This logic that applies to discovering
1287 services without manual configuration also applies to discovering the
1288 domains in which services are registered without requiring manual
1291 This discovery is performed recursively, using Unicast or Multicast
1292 DNS. Four special RR names are reserved for this purpose:
1294 _browse._dns-sd._udp.<domain>
1295 _default._browse._dns-sd._udp.<domain>
1296 _register._dns-sd._udp.<domain>
1297 _default._register._dns-sd._udp.<domain>
1299 By performing PTR queries for these names, a client can learn,
1302 o A list of domains recommended for browsing
1304 o A single recommended default domain for browsing
1306 o A list of domains recommended for registering services using
1309 o A single recommended default domain for registering services.
1311 These domains are purely advisory. The client or user is free to
1312 browse and/or register services in any domains. The purpose of these
1313 special queries is to allow software to create a user-interface that
1314 displays a useful list of suggested choices to the user, from which
1315 they may make a suitable selection, or ignore the offered suggestions
1316 and manually enter their own choice.
1318 The <domain> part of the name may be ".local." (meaning "perform the
1319 query using link-local multicast) or it may be learned through some
1320 other mechanism, such as the DHCP "Domain" option (option code 15)
1321 [RFC 2132] or the DHCP "Domain Search" option (option code 119)
1322 [RFC 3397]. Sophisticated clients may perform these queries both in
1323 ".local." and in one or more unicast domains, and then present the
1324 user with an aggregate result, combining the information received
1334 Expires 14th August 2004 Cheshire & Krochmal [Page 23]
1336 Internet Draft DNS-Based Service Discovery 14th February 2004
1339 14. DNS Additional Record Generation
1341 DNS has an efficiency feature whereby a DNS server may place
1342 additional records in the Additional Section of the DNS Message.
1343 These additional records are typically records that the client did
1344 not explicitly request, but the server has reasonable grounds to
1345 expect that the client might request them shortly.
1347 This section recommends which additional records should be generated
1348 to improve network efficiency for both unicast and multicast DNS-SD
1354 When including a PTR record in a response packet, the
1355 server/responder SHOULD include the following additional records:
1357 o The SRV record(s) named in the PTR rdata.
1358 o The TXT record(s) named in the PTR rdata.
1359 o All address records (type "A" and "AAAA") named in the SRV rdata.
1364 When including an SVR record in a response packet, the
1365 server/responder SHOULD include the following additional records:
1367 o All address records (type "A" and "AAAA") named in the SRV rdata.
1372 When including a TXT record in a response packet, no additional
1373 records are required.
1376 14.4 Other Record Types
1378 In response to address queries, or other record types, no additional
1379 records are required by this document.
1392 Expires 14th August 2004 Cheshire & Krochmal [Page 24]
1394 Internet Draft DNS-Based Service Discovery 14th February 2004
1397 15. Comparison with Alternative Service Discovery Protocols
1399 Over the years there have been many proposed ways to do network
1400 service discovery with IP, but none achieved ubiquity in the
1401 marketplace. Certainly none has achieved anything close to the
1402 ubiquity of today's deployment of DNS servers, clients, and other
1405 The advantage of using DNS as the basis for service discovery is that
1406 it makes use of those existing servers, clients, protocols,
1407 infrastructure, and expertise. Existing network analyser tools
1408 already know how to decode and display DNS packets for network
1411 For ad-hoc networks such as Zeroconf environments, peer-to-peer
1412 multicast protocols are appropriate. The Zeroconf host profile [ZCHP]
1413 requires the use of a DNS-like protocol over IP Multicast for host
1414 name resolution in the absence of DNS servers. Given that Zeroconf
1415 hosts will have to implement this Multicast-based DNS-like protocol
1416 anyway, it makes sense for them to also perform service discovery
1417 using that same Multicast-based DNS-like software, instead of also
1418 having to implement an entirely different service discovery protocol.
1420 In larger networks, a high volume of enterprise-wide IP multicast
1421 traffic may not be desirable, so any credible service discovery
1422 protocol intended for larger networks has to provide some facility to
1423 aggregate registrations and lookups at a central server (or servers)
1424 instead of working exclusively using multicast. This requires some
1425 service discovery aggregation server software to be written,
1426 debugged, deployed, and maintained. This also requires some service
1427 discovery registration protocol to be implemented and deployed for
1428 clients to register with the central aggregation server. Virtually
1429 every company with an IP network already runs a DNS server, and DNS
1430 already has a dynamic registration protocol [RFC 2136]. Given that
1431 virtually every company already has to operate and maintain a DNS
1432 server anyway, it makes sense to take advantage of this instead of
1433 also having to learn, operate and maintain a different service
1434 registration server. It should be stressed again that using the same
1435 software and protocols doesn't necessarily mean using the same
1436 physical piece of hardware. The DNS-SD service discovery functions
1437 do not have to be provided by the same piece of hardware that
1438 is currently providing the company's DNS name service. The
1439 "_tcp.<Domain>" subdomain may be delegated to a different piece of
1440 hardware. However, even when the DNS-SD service is being provided by
1441 a different piece of hardware, it is still the same familiar DNS
1442 server software that is running, with the same configuration file
1443 syntax, the same log file format, and so forth.
1450 Expires 14th August 2004 Cheshire & Krochmal [Page 25]
1452 Internet Draft DNS-Based Service Discovery 14th February 2004
1455 Service discovery needs to be able to provide appropriate security.
1456 DNS already has existing mechanisms for security [RFC 2535].
1460 Service discovery requires a central aggregation server.
1461 DNS already has one: It's called a DNS server.
1463 Service discovery requires a service registration protocol.
1464 DNS already has one: It's called DNS Dynamic Update.
1466 Service discovery requires a query protocol
1467 DNS already has one: It's called DNS.
1469 Service discovery requires security mechanisms.
1470 DNS already has security mechanisms: DNSSEC.
1472 Service discovery requires a multicast mode for ad-hoc networks.
1473 Zeroconf environments already require a multicast-based DNS-like
1474 name lookup protocol for mapping host names to addresses, so it
1475 makes sense to let one multicast-based protocol do both jobs.
1477 It makes more sense to use the existing software that every network
1478 needs already, instead of deploying an entire parallel system just
1479 for service discovery.
1508 Expires 14th August 2004 Cheshire & Krochmal [Page 26]
1510 Internet Draft DNS-Based Service Discovery 14th February 2004
1515 The following examples were prepared using standard unmodified
1516 nslookup and standard unmodified BIND running on GNU/Linux.
1518 Note: In real products, this information is obtained and presented to
1519 the user using graphical network browser software, not command-line
1520 tools, but if you wish you can try these examples for yourself as you
1521 read along, using the command-line tools already available on your
1525 16.1 Question: What FTP servers are being advertised from dns-sd.org?
1527 nslookup -q=ptr _ftp._tcp.dns-sd.org.
1528 _ftp._tcp.dns-sd.org name=Apple\032QuickTime\032Files.dns-sd.org
1529 _ftp._tcp.dns-sd.org name=Microsoft\032Developer\032Files.dns-sd.org
1530 _ftp._tcp.dns-sd.org name=Registered\032Users'\032Only.dns-sd.org
1532 Answer: There are three, called "Apple QuickTime Files",
1533 "Microsoft Developer Files" and "Registered Users' Only".
1535 Note that nslookup escapes spaces as "\032" for display purposes,
1536 but a graphical DNS-SD browser does not.
1539 16.2 Question: What FTP servers allow anonymous access?
1541 nslookup -q=ptr _anon._ftp._tcp.dns-sd.org
1542 _anon._ftp._tcp.dns-sd.org
1543 name=Apple\032QuickTime\032Files.dns-sd.org
1544 _anon._ftp._tcp.dns-sd.org
1545 name=Microsoft\032Developer\032Files.dns-sd.org
1547 Answer: Only "Apple QuickTime Files" and "Microsoft Developer Files"
1548 allow anonymous access.
1551 16.3 Question: How do I access "Apple QuickTime Files"?
1553 nslookup -q=any "Apple\032QuickTime\032Files.dns-sd.org."
1554 Apple\032QuickTime\032Files.dns-sd.org text = "path=/quicktime"
1555 Apple\032QuickTime\032Files.dns-sd.org
1556 priority = 0, weight = 0, port= 21 host = ftp.apple.com
1557 ftp.apple.com internet address = 17.254.0.27
1558 ftp.apple.com internet address = 17.254.0.31
1559 ftp.apple.com internet address = 17.254.0.26
1561 Answer: You need to connect to ftp.apple.com, port 21, path
1562 "/quicktime". The addresses for ftp.apple.com are also given.
1566 Expires 14th August 2004 Cheshire & Krochmal [Page 27]
1568 Internet Draft DNS-Based Service Discovery 14th February 2004
1571 17. IPv6 Considerations
1573 IPv6 has no significant differences, except that the address of the
1574 SRV record's target host is given by the appropriate IPv6 address
1575 records instead of the IPv4 "A" record.
1578 18. Security Considerations
1580 DNSSEC [RFC 2535] should be used where the authenticity of
1581 information is important. Since DNS-SD is just a naming and usage
1582 convention for records in the existing DNS system, it has no specific
1583 additional security requirements over and above those that already
1584 apply to DNS queries and DNS updates.
1587 19. IANA Considerations
1589 This protocol builds on DNS SRV records [RFC 2782], and similarly
1590 requires IANA to assign unique application protocol names.
1591 Unfortunately, the "IANA Considerations" section of RFC 2782 says
1592 simply, "The IANA has assigned RR type value 33 to the SRV RR.
1593 No other IANA services are required by this document."
1594 Due to this oversight, IANA is currently prevented from carrying
1595 out the necessary function of assigning these unique identifiers.
1597 This document proposes the following IANA allocation policy for
1598 unique application protocol names:
1601 * Must be no more than fourteen characters long
1602 * Must consist only of:
1603 - lower-case letters 'a' - 'z'
1605 - the hyphen character '-'
1606 * Must begin and end with a lower-case letter or digit.
1607 * Must not already be assigned to some other protocol in the
1608 existing IANA "list of assigned application protocol names
1609 and port numbers" [ports].
1611 These identifiers are allocated on a First Come First Served basis.
1612 In the event of abuse (e.g. automatated mass registrations, etc.),
1613 the policy may be changed without notice to Expert Review [RFC 2434].
1615 The textual nature of service/protocol names means that there are
1616 almost infinitely many more of them available than the finite set of
1617 65535 possible port numbers. This means that developers can produce
1618 experimental implementations using unregistered service names with
1619 little chance of accidental collision, providing service names are
1620 chosen with appropriate care. However, this document strongly
1624 Expires 14th August 2004 Cheshire & Krochmal [Page 28]
1626 Internet Draft DNS-Based Service Discovery 14th February 2004
1629 advocates that on or before the date a product ships, developers
1630 should properly register their service names.
1632 Some developers have expressed concern that publicly registering
1633 their service names (and port numbers today) with IANA before a
1634 product ships may give away clues about that product to competitors.
1635 For this reason, IANA should consider allowing service name
1636 applications to remain secret for some period of time, much as US
1637 patent applications remain secret for two years after the date of
1640 This proposed IANA allocation policy is not in force until this
1641 document is published as an RFC. In the meantime, unique application
1642 protocol names may be registered according to the instructions at
1643 <http://www.dns-sd.org/ServiceNames.html>. As of January 2004, there
1644 are roughly 100 application protocols in currently shipping products
1645 that have been so registered as using DNS-SD for service discovery.
1648 20. Acknowledgements
1650 We would like to thank (in alphabetical order) Richard Brown, Josh
1651 Graessley, Erik Guttman, Paul Vixie, and Bill Woodcock, for their
1657 Copyright (C) The Internet Society 2004.
1658 All Rights Reserved.
1660 This document and translations of it may be copied and furnished to
1661 others, and derivative works that comment on or otherwise explain it
1662 or assist in its implementation may be prepared, copied, published
1663 and distributed, in whole or in part, without restriction of any
1664 kind, provided that the above copyright notice and this paragraph are
1665 included on all such copies and derivative works. However, this
1666 document itself may not be modified in any way, such as by removing
1667 the copyright notice or references to the Internet Society or other
1668 Internet organizations, except as needed for the purpose of
1669 developing Internet standards in which case the procedures for
1670 copyrights defined in the Internet Standards process must be
1671 followed, or as required to translate it into languages other than
1674 The limited permissions granted above are perpetual and will not be
1675 revoked by the Internet Society or its successors or assigns.
1677 This document and the information contained herein is provided on an
1678 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1679 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1682 Expires 14th August 2004 Cheshire & Krochmal [Page 29]
1684 Internet Draft DNS-Based Service Discovery 14th February 2004
1687 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1688 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1689 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1692 22. Normative References
1694 [ports] IANA list of assigned application protocol names and port
1695 numbers <http://www.iana.org/assignments/port-numbers>
1697 [RFC 1033] Lottor, M., "Domain Administrators Operations Guide",
1698 RFC 1033, November 1987.
1700 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
1701 Facilities", STD 13, RFC 1034, November 1987.
1703 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
1704 Specifications", STD 13, RFC 1035, November 1987.
1706 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
1707 Requirement Levels", RFC 2119, March 1997.
1709 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
1710 10646", RFC 2279, January 1998.
1712 [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the
1713 location of services (DNS SRV)", RFC 2782, February 2000.
1716 23. Informative References
1718 [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS",
1719 Internet-Draft (work in progress),
1720 draft-cheshire-dnsext-multicastdns-04.txt, February 2004.
1722 [NBP] Cheshire, S., and M. Krochmal,
1723 "Requirements for a Protocol to Replace AppleTalk NBP",
1724 Internet-Draft (work in progress),
1725 draft-cheshire-dnsext-nbp-03.txt, February 2004.
1727 [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP
1728 Vendor Extensions", RFC 2132, March 1997.
1730 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
1731 System (DNS UPDATE)", RFC 2136, April 1997.
1733 [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing
1734 an IANA Considerations Section in RFCs", RFC 2434,
1740 Expires 14th August 2004 Cheshire & Krochmal [Page 30]
1742 Internet Draft DNS-Based Service Discovery 14th February 2004
1745 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
1746 RFC 2535, March 1999.
1748 [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS)
1749 Dynamic Update", RFC 3007, November 2000.
1751 [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration
1752 Protocol (DHCP) Domain Search Option", RFC 3397, November
1755 [ZC] Williams, A., "Requirements for Automatic Configuration
1756 of IP Hosts", Internet-Draft (work in progress),
1757 draft-ietf-zeroconf-reqts-12.txt, September 2002.
1759 [ZCHP] Guttman, E., "Zeroconf Host Profile Applicability
1760 Statement", Internet-Draft (work in progress),
1761 draft-ietf-zeroconf-host-prof-01.txt, July 2001.
1764 24. Author's Addresses
1767 Apple Computer, Inc.
1773 Phone: +1 408 974 3207
1774 EMail: rfc@stuartcheshire.org
1778 Apple Computer, Inc.
1784 Phone: +1 408 974 4368
1785 EMail: marc@apple.com
1798 Expires 14th August 2004 Cheshire & Krochmal [Page 31]