• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Document: draft-cheshire-dnsext-dns-sd-03.txt            Stuart Cheshire
2Category: Standards Track                           Apple Computer, Inc.
3Expires 7th December 2005                                  Marc Krochmal
4                                                    Apple Computer, Inc.
5                                                           7th June 2005
6
7                      DNS-Based Service Discovery
8
9                 <draft-cheshire-dnsext-dns-sd-03.txt>
10
11
12Status of this Memo
13
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.
19
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."
24
25   The list of current Internet-Drafts can be accessed at
26   http://www.ietf.org/ietf/1id-abstracts.txt
27
28   The list of Internet-Draft Shadow Directories can be accessed at
29   http://www.ietf.org/shadow.html
30
31   Distribution of this memo is unlimited.
32
33
34Abstract
35
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.
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58Expires 7th December 2005          Cheshire & Krochmal          [Page 1]
59
60Internet Draft       DNS-Based Service Discovery           7th June 2005
61
62
63Table of Contents
64
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..................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.............................................16
82   6.7 Version Tag....................................................17
83   7.  Application Protocol Names.....................................17
84   7.1 Service Name Length Limits.....................................19
85   8.  Selective Instance Enumeration.................................20
86   9.  Flagship Naming................................................20
87   10. Service Type Enumeration.......................................22
88   11. Populating the DNS with Information............................23
89   12. Relationship to Multicast DNS..................................23
90   13. Discovery of Browsing and Registration Domains.................24
91   14. DNS Additional Record Generation...............................25
92   15. Comparison with Alternative Service Discovery Protocols........26
93   16. Real Example...................................................28
94   17. IPv6 Considerations............................................29
95   18. Security Considerations........................................29
96   19. IANA Considerations............................................29
97   20. Acknowledgments................................................30
98   21. Copyright......................................................30
99   22. Normative References...........................................31
100   23. Informative References.........................................31
101   24. Authors' Addresses.............................................32
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116Expires 7th December 2005          Cheshire & Krochmal          [Page 2]
117
118Internet Draft       DNS-Based Service Discovery           7th June 2005
119
120
1211. Introduction
122
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.
129
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.
135
136   This proposal is entirely compatible with today's existing unicast
137   DNS server and client software.
138
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.
147
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.
159
160   This proposal is also compatible with (but not dependent on) the
161   proposal outlined in "Multicast DNS" [mDNS].
162
163
1642. Conventions and Terminology Used in this Document
165
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].
170
171
172
173
174Expires 7th December 2005          Cheshire & Krochmal          [Page 3]
175
176Internet Draft       DNS-Based Service Discovery           7th June 2005
177
178
1793. Design Goals
180
181   A good service discovery protocol needs to have many properties,
182   three of which are mentioned below:
183
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").
187
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).
192
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.
199
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.
204
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.
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232Expires 7th December 2005          Cheshire & Krochmal          [Page 4]
233
234Internet Draft       DNS-Based Service Discovery           7th June 2005
235
236
2374. Service Instance Enumeration
238
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.
242
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
250   out in RFC 2782.
251
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.
257
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.
262
263
2644.1 Structured Instance Names
265
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).
271
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".)
285
286
287
288
289
290Expires 7th December 2005          Cheshire & Krochmal          [Page 5]
291
292Internet Draft       DNS-Based Service Discovery           7th June 2005
293
294
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
297   form:
298
299      Service Instance Name = <Instance> . <Service> . <Domain>
300
301   The <Instance> portion of the Service Instance Name is a single DNS
302   label, containing arbitrary precomposed UTF-8-encoded text [RFC
303   2279]. 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.
312
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.
318
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
325   character.
326
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.
331
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".
338
339   The <Domain> portion of the Service Instance Name is a conventional
340   DNS domain name, consisting of as many labels as appropriate. For
341   example, "apple.com.", "cs.stanford.edu.", and "eng.us.ibm.com." are
342   all valid domain names for the <Domain> portion of the Service
343   Instance Name.
344
345
346
347
348Expires 7th December 2005          Cheshire & Krochmal          [Page 6]
349
350Internet Draft       DNS-Based Service Discovery           7th June 2005
351
352
3534.2 User Interface Presentation
354
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.
368
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.
373
374
3754.3 Internal Handling of Names
376
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.
381
382   Any dots in the <Instance> portion should be escaped by preceding
383   them with a backslash ("." becomes "\."). Likewise, any backslashes
384   in the <Instance> portion should also be escaped by preceding 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).
389
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.
393
394
3954.4 What You See Is What You Get
396
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.
403
404
405
406Expires 7th December 2005          Cheshire & Krochmal          [Page 7]
407
408Internet Draft       DNS-Based Service Discovery           7th June 2005
409
410
411   The problem with this approach is that it decouples user perception
412   from reality:
413
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?
418
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
438     is even worse.
439
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
446     has ceased to exist.
447
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 understand
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
456   expected.
457
458   These anomalies and counter-intuitive behaviors 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
461
462
463
464Expires 7th December 2005          Cheshire & Krochmal          [Page 8]
465
466Internet Draft       DNS-Based Service Discovery           7th June 2005
467
468
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.
472
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.
480
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.
490
491
4924.5 Ordering of Service Instance Name Components
493
494   There have been questions about why services are named using DNS
495   Service Instance Names of the form:
496
497      Service Instance Name = <Instance> . <Service> . <Domain>
498
499   instead of:
500
501      Service Instance Name = <Service> . <Instance> . <Domain>
502
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 next-most
506   significant, and then the specific instance name as the
507   least-significant (leftmost) part of the name:
508
509
5104.5.1. Semantic Structure
511
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
516   service.
517
518
519
520
521
522Expires 7th December 2005          Cheshire & Krochmal          [Page 9]
523
524Internet Draft       DNS-Based Service Discovery           7th June 2005
525
526
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.
538
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.
543
544
5454.5.2. Network Efficiency
546
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
554   first in each name.
555
556
5574.5.3. Operational Flexibility
558
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.
576
577
578
579
580Expires 7th December 2005          Cheshire & Krochmal         [Page 10]
581
582Internet Draft       DNS-Based Service Discovery           7th June 2005
583
584
5855. Service Name Resolution
586
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
589   that name.
590
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.
593
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.
611
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.)
625
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. However,
631   in the overwhelmingly common case, a single advertised DNS-SD service
632   instance is described by exactly one SRV record, and in this common
633   case the priority and weight fields of the SRV record SHOULD both be
634   set to zero.
635
636
637
638Expires 7th December 2005          Cheshire & Krochmal         [Page 11]
639
640Internet Draft       DNS-Based Service Discovery           7th June 2005
641
642
6436. Data Syntax for DNS-SD TXT Records
644
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,
659   as described below. Every DNS-SD service MUST have a TXT record in
660   addition to its SRV record, with same name, even if the service has
661   no additional data to store and the TXT record contains no more than
662   a single zero byte.
663
664
6656.1 General Format Rules for DNS TXT Records
666
667   A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total
668   length is indicated by the length given in the resource record header
669   in the DNS message. There is no way to tell directly from the data
670   alone how long it is (e.g. there is no length count at the start, or
671   terminating NULL byte at the end). (Note that when using Multicast
672   DNS [mDNS] the maximum packet size is 9000 bytes, which imposes an
673   upper limit on the size of TXT records of about 8800 bytes.)
674
675   The format of the data within a DNS TXT record is one or more
676   strings, packed together in memory without any intervening gaps or
677   padding bytes for word alignment.
678
679   The format of each constituent string within the DNS TXT record is a
680   single length byte, followed by 0-255 bytes of text data.
681
682   These format rules are defined in Section 3.3.14 of RFC 1035, and are
683   not specific to DNS-SD. DNS-SD simply specifies a usage convention
684   for what data should be stored in those constituent strings.
685
686   An empty TXT record containing zero strings is disallowed by RFC
687   1035. DNS-SD implementations MUST NOT emit empty TXT records. DNS-SD
688   implementations receiving empty TXT records MUST treat them as
689   equivalent to a one-byte TXT record containing a single zero byte
690   (i.e. a single empty string).
691
692
693
694
695
696Expires 7th December 2005          Cheshire & Krochmal         [Page 12]
697
698Internet Draft       DNS-Based Service Discovery           7th June 2005
699
700
7016.2 DNS TXT Record Format Rules for use in DNS-SD
702
703   DNS-SD uses DNS TXT records to store arbitrary name/value pairs
704   conveying additional information about the named service. Each
705   name/value pair is encoded as its own constituent string within the
706   DNS TXT record, in the form "name=value". Everything up to the first
707   '=' character is the name. Everything after the first '=' character
708   to the end of the string (including subsequent '=' characters, if
709   any) is the value. Specific rules governing names and values are
710   given below. Each author defining a DNS-SD profile for discovering
711   instances of a particular type of service should define the base set
712   of name/value attributes that are valid for that type of service.
713
714   Using this standardized name/value syntax within the TXT record makes
715   it easier for these base definitions to be expanded later by defining
716   additional named attributes. If an implementation sees unknown
717   attribute names in a service TXT record, it MUST silently ignore
718   them.
719
720   The TCP (or UDP) port number of the service, and target host name,
721   are given in the SRV record. This information -- target host name and
722   port number -- MUST NOT be duplicated using name/value attributes in
723   the TXT record.
724
725   The intention of DNS-SD TXT records is to convey a small amount of
726   useful additional information about a service. Ideally it SHOULD NOT
727   be necessary for a client to retrieve this additional information
728   before it can usefully establish a connection to the service. For a
729   well-designed TCP-based application protocol, it should be possible,
730   knowing only the host name and port number, to open a connection to
731   that listening process, and then perform version- or feature-
732   negotiation to determine the capabilities of the service instance.
733   For example, when connecting to an AppleShare server over TCP, the
734   client enters into a protocol exchange with the server to determine
735   which version of the AppleShare protocol the server implements, and
736   which optional features or capabilities (if any) are available. For a
737   well-designed application protocol, clients should be able to connect
738   and use the service even if there is no information at all in the TXT
739   record. In this case, the information in the TXT record should be
740   viewed as a performance optimization -- when a client discovers many
741   instances of a service, the TXT record allows the client to know some
742   rudimentary information about each instance without having to open a
743   TCP connection to each one and interrogate every service instance
744   separately. Extreme care should be taken when doing this to ensure
745   that the information in the TXT record is in agreement with the
746   information retrieved by a client connecting over TCP.
747
748   There are legacy protocols which provide no feature negotiation
749   capability, and in these cases it may be useful to convey necessary
750   information in the TXT record. For example, when printing using the
751   old Unix LPR (port 515) protocol, the LPR service provides no way for
752
753
754Expires 7th December 2005          Cheshire & Krochmal         [Page 13]
755
756Internet Draft       DNS-Based Service Discovery           7th June 2005
757
758
759   the client to determine whether a particular printer accepts
760   PostScript, or what version of PostScript, etc. In this case it is
761   appropriate to embed this information in the TXT record, because the
762   alternative is worse -- passing around written instructions to the
763   users, arcane manual configuration of "/etc/printcap" files, etc.
764
765
7666.3 DNS-SD TXT Record Size
767
768   The total size of a typical DNS-SD TXT record is intended to be small
769   -- 200 bytes or less.
770
771   In cases where more data is justified (e.g. LPR printing), keeping
772   the total size under 400 bytes should allow it to fit in a single
773   standard 512-byte DNS message. (This standard DNS message size is
774   defined in RFC 1035.)
775
776   In extreme cases where even this is not enough, keeping the size of
777   the TXT record under 1300 bytes should allow it to fit in a single
778   1500-byte Ethernet packet.
779
780   Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this
781   time.
782
783
7846.4 Rules for Names in DNS-SD Name/Value Pairs
785
786   The "Name" MUST be at least one character. Strings beginning with an
787   '=' character (i.e. the name is missing) SHOULD be silently ignored.
788
789   The characters of "Name" MUST be printable US-ASCII values
790   (0x20-0x7E), excluding '=' (0x3D).
791
792   Spaces in the name are significant, whether leading, trailing, or in
793   the middle -- so don't include any spaces unless you really intend
794   that!
795
796   Case is ignored when interpreting a name, so "papersize=A4",
797   "PAPERSIZE=A4" and "Papersize=A4" are all identical.
798
799   If there is no '=', then it is a boolean attribute, and is simply
800   identified as being present, with no value.
801
802   A given attribute name may appear at most once in a TXT record. If a
803   client receives a TXT record containing the same attribute name more
804   than once, then the client MUST silently ignore all but the first
805   occurrence of that attribute. For client implementations that process
806   a DNS-SD TXT record from start to end, placing name/value pairs into
807   a hash table, using the name as the hash table key, this means that
808   if the implementation attempts to add a new name/value pair into the
809   table and finds an entry with the same name already present, then the
810
811
812Expires 7th December 2005          Cheshire & Krochmal         [Page 14]
813
814Internet Draft       DNS-Based Service Discovery           7th June 2005
815
816
817   new entry being added should be silently discarded instead. For
818   client implementations that retrieve name/value pairs by searching
819   the TXT record for the requested name, they should search the TXT
820   record from the start, and simply return the first matching name they
821   find. The reason for this simplifying rule is to facilitate the
822   creation of client libraries that parse the TXT record into an
823   internal data structure, such as a hash table or dictionary object
824   that maps from names to values, and then make that abstraction
825   available to client code.
826
827   When examining a TXT record for a given named attribute, there are
828   therefore four broad categories of results which may be returned:
829
830   * Attribute not present (Absent)
831
832   * Attribute present, with no value
833     (e.g. "Anon Allowed" -- server allows anonymous connections)
834
835   * Attribute present, with empty value (e.g. "Installed PlugIns=" --
836     server supports plugins, but none are presently installed)
837
838   * Attribute present, with non-empty value
839     (e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4")
840
841   Each author defining a DNS-SD profile for discovering instances of a
842   particular type of service should define the interpretation of these
843   different kinds of result. For example, for some keys, there may be
844   a natural true/false boolean interpretation:
845
846   * Present implies 'true'
847   * Absent implies 'false'
848
849   For other keys it may be sensible to define other semantics, such as
850   value/no-value/unknown:
851
852   * Present with value implies that value.
853     E.g. "Color=4" for a four-color ink-jet printer,
854     or "Color=6" for a six-color ink-jet printer.
855
856   * Present with empty value implies 'false'. E.g. Not a color printer.
857
858   * Absent implies 'Unknown'. E.g. A print server connected to some
859     unknown printer where the print server doesn't actually know if the
860     printer does color or not -- which gives a very bad user experience
861     and should be avoided wherever possible.
862
863   (Note that this is a hypothetical example, not an example of actual
864   name/value keys used by DNS-SD network printers.)
865
866   As a general rule, attribute names that contain no dots are defined
867   as part of the open-standard definition written by the person or
868
869
870Expires 7th December 2005          Cheshire & Krochmal         [Page 15]
871
872Internet Draft       DNS-Based Service Discovery           7th June 2005
873
874
875   group defining the DNS-SD profile for discovering that particular
876   service type. Vendor-specific extensions should be given names of the
877   form "keyname.company.com=value", using a domain name legitimately
878   registered to the person or organization creating the vendor-specific
879   key. This reduces the risk of accidental conflict if different
880   organizations each define their own vendor-specific keys.
881
882
8836.5 Rules for Values in DNS-SD Name/Value Pairs
884
885   If there is an '=', then everything after the first '=' to the end of
886   the string is the value. The value can contain any eight-bit values
887   including '='. Leading or trailing spaces are part of the value, so
888   don't put them there unless you intend them to be there. Any
889   quotation marks around the value are part of the value, so don't put
890   them there unless you intend them to be part of the value.
891
892   The value is opaque binary data. Often the value for a particular
893   attribute will be US-ASCII (or UTF-8) text, but it is legal for a
894   value to be any binary data. For example, if the value of a key is an
895   IPv4 address, that address should simply be stored as four bytes of
896   binary data, not as a variable-length 7-15 byte ASCII string giving
897   the address represented in textual dotted decimal notation.
898
899   Generic debugging tools should generally display all attribute values
900   as a hex dump, with accompanying text alongside displaying the UTF-8
901   interpretation of those bytes, except for attributes where the
902   debugging tool has embedded knowledge that the value is some other
903   kind of data.
904
905   Authors defining DNS-SD profiles SHOULD NOT convert binary attribute
906   data types into printable text (e.g. using hexadecimal, Base-64 or UU
907   encoding) merely for the sake of making the data be printable text
908   when seen in a generic debugging tool. Doing this simply bloats the
909   size of the TXT record, without actually making the data any more
910   understandable to someone looking at it in a generic debugging tool.
911
912
9136.6 Example TXT Record
914
915   The TXT record below contains three syntactically valid name/value
916   pairs. (The meaning of these name/value pairs, if any, would depend
917   on the definitions pertaining to the service in question that is
918   using them.)
919
920   ---------------------------------------------------------------
921   | 0x0A | name=value | 0x08 | paper=A4 | 0x0E | DNS-SD Is Cool |
922   ---------------------------------------------------------------
923
924
925
926
927
928Expires 7th December 2005          Cheshire & Krochmal         [Page 16]
929
930Internet Draft       DNS-Based Service Discovery           7th June 2005
931
932
9336.7 Version Tag
934
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.
946
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
958   record.
959
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".
963
964
9657. Application Protocol Names
966
967   The <Service> portion of a Service Instance Name consists of a pair
968   of DNS labels, following the established convention for SRV records
969   [RFC 2782], namely: the first label of the pair is the Application
970   Protocol Name, and the second label is either "_tcp" or "_udp".
971
972   Wise selection of the Application Protocol Name is very important,
973   and the choice is not always as obvious as it may appear.
974
975   Application Protocol Names may be no more than fourteen characters,
976   conforming to normal DNS host name rules: Only lower-case letters,
977   digits, and hyphens; must begin and end with lower-case letter or
978   digit.
979
980   In some cases, the Application Protocol Name merely names and refers
981   to the on-the-wire message format and semantics being used. FTP is
982   "ftp", IPP printing is "ipp", and so on.
983
984
985
986Expires 7th December 2005          Cheshire & Krochmal         [Page 17]
987
988Internet Draft       DNS-Based Service Discovery           7th June 2005
989
990
991   However, it is common to "borrow" an existing protocol and repurpose
992   it for a new task. This is entirely sensible and sound engineering
993   practice, but that doesn't mean that the new protocol is providing
994   the same semantic service as the old one, even if it borrows the same
995   message formats. For example, the local network music playing
996   protocol implemented by iTunes on Macintosh and Windows is little
997   more than "HTTP GET" commands. However, that does *not* mean that it
998   is sensible or useful to try to access one of these music servers by
999   connecting to it with a standard web browser. Consequently, the
1000   DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp"
1001   (Digital Audio Access Protocol), not "_http._tcp". Advertising
1002   "_http._tcp" service would cause iTunes servers to show up in
1003   conventional Web browsers (Safari, Camino, OmniWeb, Opera, Netscape,
1004   Internet Explorer, etc.) which is little use since it offers no pages
1005   containing human-readable content. Similarly, browsing for
1006   "_http._tcp" service would cause iTunes to find generic web servers,
1007   such as the embedded web servers in devices like printers, which is
1008   little use since printers generally don't have much music to offer.
1009
1010   Similarly, NFS is built on top of SUN RPC, but that doesn't mean it
1011   makes sense for an NFS server to advertise that it provides "SUN RPC"
1012   service. Likewise, Microsoft SMB file service is built on top of
1013   Netbios running over IP, but that doesn't mean it makes sense for an
1014   SMB file server to advertise that it provides "Netbios-over-IP"
1015   service. The DNS-SD name of a service needs to encapsulate both the
1016   "what" (semantics) and the "how" (protocol implementation) of the
1017   service, since knowledge of both is necessary for a client to
1018   usefully use the service. Merely advertising that a service was built
1019   on top of SUN RPC is no use if the client has no idea what the
1020   service actually does.
1021
1022   Another common mistake is to assume that the service type advertised
1023   by iTunes should be "_daap._http._tcp." This is also incorrect. Part
1024   of the confusion here is that the presence of "_tcp" or "_udp" in the
1025   <Service> portion of a Service Instance Name has led people to assume
1026   that the structure of a service name has to reflect the internal
1027   structure of how the protocol was implemented. This is not correct.
1028
1029   The "_tcp" or "_udp" should be regarded as little more than
1030   boilerplate text, and care should be taken not to attach too much
1031   importance to it. Some might argue that the "_tcp" or "_udp" should
1032   not be there at all, but this format is defined by RFC 2782, and
1033   that's not going to change. In addition, the presence of "_tcp" has
1034   the useful side-effect that it provides a convenient delegation point
1035   to hand off control to a different DNS server, if so desired.
1036
1037
1038
1039
1040
1041
1042
1043
1044Expires 7th December 2005          Cheshire & Krochmal         [Page 18]
1045
1046Internet Draft       DNS-Based Service Discovery           7th June 2005
1047
1048
10497.1 Service Name Length Limits
1050
1051   As described above, application protocol names are allowed to be up
1052   to fourteen characters long. The reason for this limit is to leave
1053   as many bytes of the domain name as possible available for use
1054   by both the network administrator (choosing service domain names)
1055   and the end user (choosing instance names).
1056
1057   A domain name may be up to 255 bytes long, including the final
1058   terminating root label at the end. Domain names used by DNS-SD
1059   take the following forms:
1060
1061      <Instance>.<app>._tcp.<servicedomain>.<parentdomain>.
1062      <sub>._sub.<app>._tcp.<servicedomain>.<parentdomain>.
1063
1064   The first example shows a service instance name, i.e. the name of the
1065   service's SRV and TXT records. The second shows a subtype browsing
1066   name, i.e. the name of a PTR record pointing to service instance
1067   names.
1068
1069   The instance name <Instance> may be up to 63 bytes. Including the
1070   length byte used by the DNS format when the name is stored in a
1071   packet, that makes 64 bytes.
1072
1073   When using subtypes, the subtype identifier is allowed to be up to
1074   63 bytes, plus the length byte, making 64. Including the "_sub"
1075   and its length byte, this makes 69 bytes.
1076
1077   The application protocol name <app> may be up to 14 bytes, plus the
1078   underscore and length byte, making 16. Including the "_udp" or "_tcp"
1079   and its length byte, this makes 21 bytes.
1080
1081   Typically, DNS-SD service records are placed into subdomains of their
1082   own beneath a company's existing domain name. Since these subdomains
1083   are intended to be accessed through graphical user interfaces, not
1084   typed on a command-line they are frequently long and descriptive.
1085   Including the length byte, the user-visible service domain may be up
1086   to 64 bytes.
1087
1088   The terminating root label at the end counts as one byte.
1089
1090   Of our available 255 bytes, we have now accounted for 69+21+64+1 =
1091   155 bytes. This leaves 100 bytes to accommodate the organization's
1092   existing domain name <parentdomain>. When used with Multicast DNS,
1093   <parentdomain> is "local", which easily fits. When used with parent
1094   domains of 100 bytes or less, the full functionality of DNS-SD is
1095   available without restriction. When used with parent domains longer
1096   than 100 bytes, the protocol risks exceeding the maximum possible
1097   length of domain names, causing failures. In this case, careful
1098   choice of short <servicedomain> names can help avoid overflows. If
1099   the <servicedomain> and <parentdomain> are too long, then service
1100
1101
1102Expires 7th December 2005          Cheshire & Krochmal         [Page 19]
1103
1104Internet Draft       DNS-Based Service Discovery           7th June 2005
1105
1106
1107   instances with long instance names will not be discoverable or
1108   resolvable, and applications making use of long subtype names may
1109   fail.
1110
1111   Because of this constraint, we choose to limit Application Protocol
1112   Names to 14 characters or less. Allowing more characters would not
1113   add to the expressive power of the protocol, and would needlessly
1114   lower the limit on the maximum <parentdomain> length that may be
1115   safely used.
1116
1117
11188. Selective Instance Enumeration
1119
1120   This document does not attempt to define an arbitrary query language
1121   for service discovery, nor do we believe one is necessary.
1122
1123   However, there are some circumstances where narrowing the list of
1124   results may be useful. A Web browser client that is able to retrieve
1125   HTML documents via HTTP and display them may also be able to retrieve
1126   HTML documents via FTP and display them, but only in the case of FTP
1127   servers that allow anonymous login. For that Web browser, discovering
1128   all FTP servers on the network is not useful. The Web browser only
1129   wants to discover FTP servers that it is able to talk to. In this
1130   case, a subtype of "_ftp._tcp" could be defined. Instead of issuing a
1131   query for "_ftp._tcp.<Domain>", the Web browser issues a query for
1132   "_anon._sub._ftp._tcp.<Domain>", where "_anon" is a defined subtype
1133   of "_ftp._tcp". The response to this query only includes the names of
1134   SRV records for FTP servers that are willing to allow anonymous
1135   login.
1136
1137   Note that the FTP server's Service Instance Name is unchanged -- it
1138   is still something of the form "The Server._ftp._tcp.example.com."
1139   The subdomain in which FTP server SRV records are registered defines
1140   the namespace within which FTP server names are unique. Additional
1141   subtypes (e.g. "_anon") of the basic service type (e.g. "_ftp._tcp")
1142   serve to narrow the list of results, not to create more namespace.
1143
1144   As with the TXT record name/value pairs, the list of possible
1145   subtypes, if any, are defined and specified separately for each basic
1146   service type.
1147
1148
11499. Flagship Naming
1150
1151   In some cases, there may be several network protocols available which
1152   all perform roughly the same logical function. For example, the
1153   printing world has the LPR protocol, and the Internet Printing
1154   Protocol (IPP), both of which cause printed sheets to be emitted from
1155   printers in much the same way. In addition, many printer vendors send
1156   their own proprietary page description language (PDL) data over a TCP
1157   connection to TCP port 9100, herein referred to as the
1158
1159
1160Expires 7th December 2005          Cheshire & Krochmal         [Page 20]
1161
1162Internet Draft       DNS-Based Service Discovery           7th June 2005
1163
1164
1165   "pdl-datastream" protocol. In an ideal world we would have only one
1166   network printing protocol, and it would be sufficiently good that no
1167   one felt a compelling need to invent a different one. However, in
1168   practice, multiple legacy protocols do exist, and a service discovery
1169   protocol has to accommodate that.
1170
1171   Many printers implement all three printing protocols: LPR, IPP, and
1172   pdl-datastream. For the benefit of clients that may speak only one of
1173   those protocols, all three are advertised.
1174
1175   However, some clients may implement two, or all three of those
1176   printing protocols. When a client looks for all three service types
1177   on the network, it will find three distinct services -- an LPR
1178   service, an IPP service, and a pdl-datastream service -- all of which
1179   cause printed sheets to be emitted from the same physical printer.
1180
1181   In the case of multiple protocols like this that all perform
1182   effectively the same function, the client should suppress duplicate
1183   names and display each name only once. When the user prints to a
1184   given named printer, the printing client is responsible for choosing
1185   the protocol which will best achieve the desired effect, without, for
1186   example, requiring the user to make a manual choice between LPR and
1187   IPP.
1188
1189   As described so far, this all works very well. However, consider some
1190   future printer that only supports IPP printing, and some other future
1191   printer that only supports pdl-datastream printing. The name spaces
1192   for different service types are intentionally disjoint -- it is
1193   acceptable and desirable to be able to have both a file server called
1194   "Sales Department" and a printer called "Sales Department". However,
1195   it is not desirable, in the common case, to have two different
1196   printers both called "Sales Department", just because those printers
1197   are implementing different protocols.
1198
1199   To help guard against this, when there are two or more network
1200   protocols which perform roughly the same logical function, one of the
1201   protocols is declared the "flagship" of the fleet of related
1202   protocols. Typically the flagship protocol is the oldest and/or
1203   best-known protocol of the set.
1204
1205   If a device does not implement the flagship protocol, then it instead
1206   creates a placeholder SRV record (priority=0, weight=0, port=0,
1207   target host = hostname of device) with that name. If, when it
1208   attempts to create this SRV record, it finds that a record with the
1209   same name already exists, then it knows that this name is already
1210   taken by some entity implementing at least one of the protocols from
1211   the class, and it must choose another. If no SRV record already
1212   exists, then the act of creating it stakes a claim to that name so
1213   that future devices in the same class will detect a conflict when
1214   they try to use it. The SRV record needs to contain the target host
1215   name in order for the conflict detection rules to operate. If two
1216
1217
1218Expires 7th December 2005          Cheshire & Krochmal         [Page 21]
1219
1220Internet Draft       DNS-Based Service Discovery           7th June 2005
1221
1222
1223   different devices were to create placeholder SRV records both using a
1224   null target host name (just the root label), then the two SRV records
1225   would be seen to be in agreement so no conflict would be registered.
1226
1227   By defining a common well-known flagship protocol for the class,
1228   future devices that may not even know about each other's protocols
1229   establish a common ground where they can coordinate to verify
1230   uniqueness of names.
1231
1232   No PTR record is created advertising the presence of empty flagship
1233   SRV records, since they do not represent a real service being
1234   advertised.
1235
1236
123710. Service Type Enumeration
1238
1239   In general, clients are not interested in finding *every* service on
1240   the network, just the services that the client knows how to talk to.
1241   (Software designers may *think* there's some value to finding *every*
1242   service on the network, but that's just wooly thinking.)
1243
1244   However, for problem diagnosis and network management tools, it may
1245   be useful for network administrators to find the list of advertised
1246   service types on the network, even if those service names are just
1247   opaque identifiers and not particularly informative in isolation.
1248
1249   For this reason, a special meta-query is defined. A DNS query for
1250   PTR records with the name "_services._dns-sd._udp.<Domain>" yields
1251   a list of PTR records, where the rdata of each PTR record is the
1252   name of a service type. A subsequent query for PTR records with
1253   one of those names yields a list of instances of that service type.
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276Expires 7th December 2005          Cheshire & Krochmal         [Page 22]
1277
1278Internet Draft       DNS-Based Service Discovery           7th June 2005
1279
1280
128111. Populating the DNS with Information
1282
1283   How the SRV and PTR records that describe services and allow them to
1284   be enumerated make their way into the DNS is outside the scope of
1285   this document. However, it can happen easily in any of a number of
1286   ways, for example:
1287
1288   On some networks, the administrator might manually enter the records
1289   into the name server's configuration file.
1290
1291   A network monitoring tool could output a standard zone file to be
1292   read into a conventional DNS server. For example, a tool that can
1293   find Apple LaserWriters using AppleTalk NBP could find the list of
1294   printers, communicate with each one to find its IP address,
1295   PostScript version, installed options, etc., and then write out a DNS
1296   zone file describing those printers and their capabilities using DNS
1297   resource records. That information would then be available to DNS-SD
1298   clients that don't implement AppleTalk NBP, and don't want to.
1299
1300   Future IP printers could use Dynamic DNS Update [RFC 2136] to
1301   automatically register their own SRV and PTR records with the DNS
1302   server.
1303
1304   A printer manager device which has knowledge of printers on the
1305   network through some other management protocol could also use Dynamic
1306   DNS Update [RFC 2136].
1307
1308   Alternatively, a printer manager device could implement enough of the
1309   DNS protocol that it is able to answer DNS queries directly, and
1310   Example Co.'s main DNS server could delegate the
1311   _ipp._tcp.example.com subdomain to the printer manager device.
1312
1313   Zeroconf printers answer Multicast DNS queries on the local link
1314   for appropriate PTR and SRV names ending with ".local." [mDNS]
1315
1316
131712. Relationship to Multicast DNS
1318
1319   DNS-Based Service Discovery is only peripherally related to Multicast
1320   DNS, in that the standard unicast DNS queries used by DNS-SD may also
1321   be performed using multicast when appropriate, which is particularly
1322   beneficial in Zeroconf environments [ZC].
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334Expires 7th December 2005          Cheshire & Krochmal         [Page 23]
1335
1336Internet Draft       DNS-Based Service Discovery           7th June 2005
1337
1338
133913. Discovery of Browsing and Registration Domains (Domain Enumeration)
1340
1341   One of the main reasons for DNS-Based Service Discovery is so that
1342   when a visiting client (e.g. a laptop computer) arrives at a new
1343   network, it can discover what services are available on that network
1344   without manual configuration. This logic that applies to discovering
1345   services without manual configuration also applies to discovering the
1346   domains in which services are registered without requiring manual
1347   configuration.
1348
1349   This discovery is performed recursively, using Unicast or Multicast
1350   DNS. Five special RR names are reserved for this purpose:
1351
1352                      b._dns-sd._udp.<domain>.
1353                     db._dns-sd._udp.<domain>.
1354                      r._dns-sd._udp.<domain>.
1355                     dr._dns-sd._udp.<domain>.
1356                     lb._dns-sd._udp.<domain>.
1357
1358   By performing PTR queries for these names, a client can learn,
1359   respectively:
1360
1361    o A list of domains recommended for browsing
1362
1363    o A single recommended default domain for browsing
1364
1365    o A list of domains recommended for registering services using
1366      Dynamic Update
1367
1368    o A single recommended default domain for registering services.
1369
1370    o The final query shown yields the "legacy browsing" domain.
1371      Sophisticated client applications that care to present choices of
1372      domain to the user, use the answers learned from the previous four
1373      queries to discover those domains to present. In contrast, many
1374      current applications browse without specifying an explicit domain,
1375      allowing the operating system to automatically select an
1376      appropriate domain on their behalf. It is for this class of
1377      application that the "legacy browsing" query is provided, to allow
1378      the network administrator to communicate to the client operating
1379      systems which domain should be used for these applications.
1380
1381   These domains are purely advisory. The client or user is free to
1382   browse and/or register services in any domains. The purpose of these
1383   special queries is to allow software to create a user-interface that
1384   displays a useful list of suggested choices to the user, from which
1385   they may make a suitable selection, or ignore the offered suggestions
1386   and manually enter their own choice.
1387
1388
1389
1390
1391
1392Expires 7th December 2005          Cheshire & Krochmal         [Page 24]
1393
1394Internet Draft       DNS-Based Service Discovery           7th June 2005
1395
1396
1397   The <domain> part of the name may be "local" (meaning "perform the
1398   query using link-local multicast) or it may be learned through some
1399   other mechanism, such as the DHCP "Domain" option (option code 15)
1400   [RFC 2132] or the DHCP "Domain Search" option (option code 119)
1401   [RFC 3397].
1402
1403   The <domain> part of the name may also be derived from the host's IP
1404   address. The host takes its IP address, and calculates the logical
1405   AND of that address and its subnet mask, to derive the 'base' address
1406   of the subnet. It then constructs the conventional DNS "reverse
1407   mapping" name corresponding to that base address, and uses that as
1408   the <domain> part of the name for the queries described above.
1409   For example, if a host has address 192.168.12.34, with subnet mask
1410   255.255.0.0, then the 'base' address of the subnet is 192.168.0.0,
1411   and to discover the recommended legacy browsing domain for devices
1412   on this subnet, the host issues a DNS PTR query for the name
1413   "lb._dns-sd._udp.0.0.168.192.in-addr.arpa."
1414
1415   Sophisticated clients may perform domain enumeration queries both in
1416   "local" and in one or more unicast domains, and then present the user
1417   with an aggregate result, combining the information received from all
1418   sources.
1419
1420
142114. DNS Additional Record Generation
1422
1423   DNS has an efficiency feature whereby a DNS server may place
1424   additional records in the Additional Section of the DNS Message.
1425   These additional records are typically records that the client did
1426   not explicitly request, but the server has reasonable grounds to
1427   expect that the client might request them shortly.
1428
1429   This section recommends which additional records should be generated
1430   to improve network efficiency for both unicast and multicast DNS-SD
1431   responses.
1432
1433
143414.1 PTR Records
1435
1436   When including a PTR record in a response packet, the
1437   server/responder SHOULD include the following additional records:
1438
1439   o The SRV record(s) named in the PTR rdata.
1440   o The TXT record(s) named in the PTR rdata.
1441   o All address records (type "A" and "AAAA") named in the SRV rdata.
1442
1443
1444
1445
1446
1447
1448
1449
1450Expires 7th December 2005          Cheshire & Krochmal         [Page 25]
1451
1452Internet Draft       DNS-Based Service Discovery           7th June 2005
1453
1454
145514.2 SRV Records
1456
1457   When including an SVR record in a response packet, the
1458   server/responder SHOULD include the following additional records:
1459
1460   o All address records (type "A" and "AAAA") named in the SRV rdata.
1461
1462
146314.3 TXT Records
1464
1465   When including a TXT record in a response packet, no additional
1466   records are required.
1467
1468
146914.4 Other Record Types
1470
1471   In response to address queries, or other record types, no additional
1472   records are required by this document.
1473
1474
147515. Comparison with Alternative Service Discovery Protocols
1476
1477   Over the years there have been many proposed ways to do network
1478   service discovery with IP, but none achieved ubiquity in the
1479   marketplace. Certainly none has achieved anything close to the
1480   ubiquity of today's deployment of DNS servers, clients, and other
1481   infrastructure.
1482
1483   The advantage of using DNS as the basis for service discovery is that
1484   it makes use of those existing servers, clients, protocols,
1485   infrastructure, and expertise. Existing network analyzer tools
1486   already know how to decode and display DNS packets for network
1487   debugging.
1488
1489   For ad-hoc networks such as Zeroconf environments, peer-to-peer
1490   multicast protocols are appropriate. The Zeroconf host profile [ZCHP]
1491   requires the use of a DNS-like protocol over IP Multicast for host
1492   name resolution in the absence of DNS servers. Given that Zeroconf
1493   hosts will have to implement this Multicast-based DNS-like protocol
1494   anyway, it makes sense for them to also perform service discovery
1495   using that same Multicast-based DNS-like software, instead of also
1496   having to implement an entirely different service discovery protocol.
1497
1498   In larger networks, a high volume of enterprise-wide IP multicast
1499   traffic may not be desirable, so any credible service discovery
1500   protocol intended for larger networks has to provide some facility to
1501   aggregate registrations and lookups at a central server (or servers)
1502   instead of working exclusively using multicast. This requires some
1503   service discovery aggregation server software to be written,
1504   debugged, deployed, and maintained. This also requires some service
1505   discovery registration protocol to be implemented and deployed for
1506
1507
1508Expires 7th December 2005          Cheshire & Krochmal         [Page 26]
1509
1510Internet Draft       DNS-Based Service Discovery           7th June 2005
1511
1512
1513   clients to register with the central aggregation server. Virtually
1514   every company with an IP network already runs a DNS server, and DNS
1515   already has a dynamic registration protocol [RFC 2136]. Given that
1516   virtually every company already has to operate and maintain a DNS
1517   server anyway, it makes sense to take advantage of this instead of
1518   also having to learn, operate and maintain a different service
1519   registration server. It should be stressed again that using the same
1520   software and protocols doesn't necessarily mean using the same
1521   physical piece of hardware. The DNS-SD service discovery functions
1522   do not have to be provided by the same piece of hardware that
1523   is currently providing the company's DNS name service. The
1524   "_tcp.<Domain>" subdomain may be delegated to a different piece of
1525   hardware. However, even when the DNS-SD service is being provided by
1526   a different piece of hardware, it is still the same familiar DNS
1527   server software that is running, with the same configuration file
1528   syntax, the same log file format, and so forth.
1529
1530   Service discovery needs to be able to provide appropriate security.
1531   DNS already has existing mechanisms for security [RFC 2535].
1532
1533   In summary:
1534
1535      Service discovery requires a central aggregation server.
1536      DNS already has one: It's called a DNS server.
1537
1538      Service discovery requires a service registration protocol.
1539      DNS already has one: It's called DNS Dynamic Update.
1540
1541      Service discovery requires a query protocol
1542      DNS already has one: It's called DNS.
1543
1544      Service discovery requires security mechanisms.
1545      DNS already has security mechanisms: DNSSEC.
1546
1547      Service discovery requires a multicast mode for ad-hoc networks.
1548      Zeroconf environments already require a multicast-based DNS-like
1549      name lookup protocol for mapping host names to addresses, so it
1550      makes sense to let one multicast-based protocol do both jobs.
1551
1552   It makes more sense to use the existing software that every network
1553   needs already, instead of deploying an entire parallel system just
1554   for service discovery.
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566Expires 7th December 2005          Cheshire & Krochmal         [Page 27]
1567
1568Internet Draft       DNS-Based Service Discovery           7th June 2005
1569
1570
157116. Real Example
1572
1573   The following examples were prepared using standard unmodified
1574   nslookup and standard unmodified BIND running on GNU/Linux.
1575
1576   Note: In real products, this information is obtained and presented to
1577   the user using graphical network browser software, not command-line
1578   tools, but if you wish you can try these examples for yourself as you
1579   read along, using the command-line tools already available on your
1580   own Unix machine.
1581
158216.1 Question: What FTP servers are being advertised from dns-sd.org?
1583
1584   nslookup -q=ptr _ftp._tcp.dns-sd.org.
1585   _ftp._tcp.dns-sd.org
1586            name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
1587   _ftp._tcp.dns-sd.org
1588            name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org
1589   _ftp._tcp.dns-sd.org
1590            name = Registered\032Users'\032Only._ftp._tcp.dns-sd.org
1591
1592   Answer: There are three, called "Apple QuickTime Files",
1593   "Microsoft Developer Files" and "Registered Users' Only".
1594
1595   Note that nslookup escapes spaces as "\032" for display purposes,
1596   but a graphical DNS-SD browser does not.
1597
159816.2 Question: What FTP servers allow anonymous access?
1599
1600   nslookup -q=ptr _anon._sub._ftp._tcp.dns-sd.org
1601   _anon._sub._ftp._tcp.dns-sd.org
1602            name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
1603   _anon._sub._ftp._tcp.dns-sd.org
1604            name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org
1605
1606   Answer: Only "Apple QuickTime Files" and "Microsoft Developer Files"
1607   allow anonymous access.
1608
160916.3 Question: How do I access "Apple QuickTime Files"?
1610
1611   nslookup -q=any "Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org."
1612   Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
1613             text = "path=/quicktime"
1614   Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
1615             priority = 0, weight = 0, port= 21 host = ftp.apple.com
1616   ftp.apple.com   internet address = 17.254.0.27
1617   ftp.apple.com   internet address = 17.254.0.31
1618   ftp.apple.com   internet address = 17.254.0.26
1619
1620   Answer: You need to connect to ftp.apple.com, port 21, path
1621   "/quicktime". The addresses for ftp.apple.com are also given.
1622
1623
1624Expires 7th December 2005          Cheshire & Krochmal         [Page 28]
1625
1626Internet Draft       DNS-Based Service Discovery           7th June 2005
1627
1628
162917. IPv6 Considerations
1630
1631   IPv6 has no significant differences, except that the address of the
1632   SRV record's target host is given by the appropriate IPv6 address
1633   records instead of the IPv4 "A" record.
1634
1635
163618. Security Considerations
1637
1638   DNSSEC [RFC 2535] should be used where the authenticity of
1639   information is important. Since DNS-SD is just a naming and usage
1640   convention for records in the existing DNS system, it has no specific
1641   additional security requirements over and above those that already
1642   apply to DNS queries and DNS updates.
1643
1644
164519. IANA Considerations
1646
1647   This protocol builds on DNS SRV records [RFC 2782], and similarly
1648   requires IANA to assign unique application protocol names.
1649   Unfortunately, the "IANA Considerations" section of RFC 2782 says
1650   simply, "The IANA has assigned RR type value 33 to the SRV RR.
1651   No other IANA services are required by this document."
1652   Due to this oversight, IANA is currently prevented from carrying
1653   out the necessary function of assigning these unique identifiers.
1654
1655   This document proposes the following IANA allocation policy for
1656   unique application protocol names:
1657
1658   Allowable names:
1659     * Must be no more than fourteen characters long
1660     * Must consist only of:
1661       - lower-case letters 'a' - 'z'
1662       - digits '0' - '9'
1663       - the hyphen character '-'
1664     * Must begin and end with a lower-case letter or digit.
1665     * Must not already be assigned to some other protocol in the
1666       existing IANA "list of assigned application protocol names
1667       and port numbers" [ports].
1668
1669   These identifiers are allocated on a First Come First Served basis.
1670   In the event of abuse (e.g. automated mass registrations, etc.),
1671   the policy may be changed without notice to Expert Review [RFC 2434].
1672
1673   The textual nature of service/protocol names means that there are
1674   almost infinitely many more of them available than the finite set of
1675   65535 possible port numbers. This means that developers can produce
1676   experimental implementations using unregistered service names with
1677   little chance of accidental collision, providing service names are
1678   chosen with appropriate care. However, this document strongly
1679   advocates that on or before the date a product ships, developers
1680   should properly register their service names.
1681
1682Expires 7th December 2005          Cheshire & Krochmal         [Page 29]
1683
1684Internet Draft       DNS-Based Service Discovery           7th June 2005
1685
1686
1687   Some developers have expressed concern that publicly registering
1688   their service names (and port numbers today) with IANA before a
1689   product ships may give away clues about that product to competitors.
1690   For this reason, IANA should consider allowing service name
1691   applications to remain secret for some period of time, much as US
1692   patent applications remain secret for two years after the date of
1693   filing.
1694
1695   This proposed IANA allocation policy is not in force until this
1696   document is published as an RFC. In the meantime, unique application
1697   protocol names may be registered according to the instructions at
1698   <http://www.dns-sd.org/ServiceTypes.html>. As of January 2004, there
1699   are roughly 100 application protocols in currently shipping products
1700   that have been so registered as using DNS-SD for service discovery.
1701
1702
170320. Acknowledgments
1704
1705   The concepts described in this document have been explored, developed
1706   and implemented with help from Richard Brown, Erik Guttman, Paul
1707   Vixie, and Bill Woodcock.
1708
1709   Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher,
1710   Roger Pantos and Kiren Sekar for their significant contributions.
1711
1712
171321. Copyright
1714
1715   Copyright (C) The Internet Society 2005.
1716   All Rights Reserved.
1717
1718   This document and translations of it may be copied and furnished to
1719   others, and derivative works that comment on or otherwise explain it
1720   or assist in its implementation may be prepared, copied, published
1721   and distributed, in whole or in part, without restriction of any
1722   kind, provided that the above copyright notice and this paragraph are
1723   included on all such copies and derivative works. However, this
1724   document itself may not be modified in any way, such as by removing
1725   the copyright notice or references to the Internet Society or other
1726   Internet organizations, except as needed for the purpose of
1727   developing Internet standards in which case the procedures for
1728   copyrights defined in the Internet Standards process must be
1729   followed, or as required to translate it into languages other than
1730   English.
1731
1732   The limited permissions granted above are perpetual and will not be
1733   revoked by the Internet Society or its successors or assigns.
1734
1735   This document and the information contained herein is provided on an
1736   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1737   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1738
1739
1740Expires 7th December 2005          Cheshire & Krochmal         [Page 30]
1741
1742Internet Draft       DNS-Based Service Discovery           7th June 2005
1743
1744
1745   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1746   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1747   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1748
1749
175022. Normative References
1751
1752   [ports]    IANA list of assigned application protocol names and port
1753              numbers <http://www.iana.org/assignments/port-numbers>
1754
1755   [RFC 1033] Lottor, M., "Domain Administrators Operations Guide",
1756              RFC 1033, November 1987.
1757
1758   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
1759              Facilities", STD 13, RFC 1034, November 1987.
1760
1761   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
1762              Specifications", STD 13, RFC 1035, November 1987.
1763
1764   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
1765              Requirement Levels", RFC 2119, March 1997.
1766
1767   [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
1768              10646", RFC 2279, January 1998.
1769
1770   [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the
1771              location of services (DNS SRV)", RFC 2782, February 2000.
1772
1773
177423. Informative References
1775
1776   [mDNS]     Cheshire, S., and M. Krochmal, "Multicast DNS",
1777              Internet-Draft (work in progress),
1778              draft-cheshire-dnsext-multicastdns-05.txt, June 2005.
1779
1780   [NBP]      Cheshire, S., and M. Krochmal,
1781              "Requirements for a Protocol to Replace AppleTalk NBP",
1782              Internet-Draft (work in progress),
1783              draft-cheshire-dnsext-nbp-04.txt, June 2005.
1784
1785   [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP
1786              Vendor Extensions", RFC 2132, March 1997.
1787
1788   [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
1789              System (DNS UPDATE)", RFC 2136, April 1997.
1790
1791   [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing
1792              an IANA Considerations Section in RFCs", RFC 2434,
1793              October 1998.
1794
1795
1796
1797
1798Expires 7th December 2005          Cheshire & Krochmal         [Page 31]
1799
1800Internet Draft       DNS-Based Service Discovery           7th June 2005
1801
1802
1803   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
1804              RFC 2535, March 1999.
1805
1806   [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS)
1807              Dynamic Update", RFC 3007, November 2000.
1808
1809   [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration
1810              Protocol (DHCP) Domain Search Option", RFC 3397, November
1811              2002.
1812
1813   [ZC]       Williams, A., "Requirements for Automatic Configuration
1814              of IP Hosts", Internet-Draft (work in progress),
1815              draft-ietf-zeroconf-reqts-12.txt, September 2002.
1816
1817   [ZCHP]     Guttman, E., "Zeroconf Host Profile Applicability
1818              Statement", Internet-Draft (work in progress),
1819              draft-ietf-zeroconf-host-prof-01.txt, July 2001.
1820
1821
182224. Authors' Addresses
1823
1824   Stuart Cheshire
1825   Apple Computer, Inc.
1826   1 Infinite Loop
1827   Cupertino
1828   California 95014
1829   USA
1830
1831   Phone: +1 408 974 3207
1832   EMail: rfc@stuartcheshire.org
1833
1834
1835   Marc Krochmal
1836   Apple Computer, Inc.
1837   1 Infinite Loop
1838   Cupertino
1839   California 95014
1840   USA
1841
1842   Phone: +1 408 974 4368
1843   EMail: marc@apple.com
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856Expires 7th December 2005          Cheshire & Krochmal         [Page 32]
1857