rfc6763-from-stuart.txt   rfc6763.txt 
Internet Engineering Task Force (IETF) S. Cheshire Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6763 M. Krochmal Request for Comments: 6763 M. Krochmal
Category: Standards Track Apple Inc. Category: Standards Track Apple Inc.
ISSN: 2070-1721 September 2012 ISSN: 2070-1721 December 2012
DNS-Based Service Discovery DNS-Based Service Discovery
Abstract Abstract
This document specifies how DNS resource records are named and This document specifies how DNS resource records are named and
structured to facilitate service discovery. Given a type of service structured to facilitate service discovery. Given a type of service
that a client is looking for, and a domain in which the client is that a client is looking for, and a domain in which the client is
looking for that service, this mechanism allows clients to discover looking for that service, this mechanism allows clients to discover
a list of named instances of that desired service, using standard a list of named instances of that desired service, using standard
DNS queries. This mechanism is referred to as DNS-based Service DNS queries. This mechanism is referred to as DNS-based Service
Discovery, or DNS-SD. Discovery, or DNS-SD.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ....................................................3 1. Introduction ....................................................3
2. Conventions and Terminology Used in This Document ...............5 2. Conventions and Terminology Used in This Document ...............5
3. Design Goals ....................................................5 3. Design Goals ....................................................5
4. Service Instance Enumeration (Browsing) .........................6 4. Service Instance Enumeration (Browsing) .........................6
4.1. Structured Service Instance Names ..........................6 4.1. Structured Service Instance Names ..........................6
4.2. User Interface Presentation ................................9 4.2. User Interface Presentation ................................6
4.3. Internal Handling of Names .................................9 4.3. Internal Handling of Names .................................9
5. Service Instance Resolution ....................................10 5. Service Instance Resolution .....................................9
6. Data Syntax for DNS-SD TXT Records .............................10 6. Data Syntax for DNS-SD TXT Records .............................10
6.1. General Format Rules for DNS TXT Records ..................11 6.1. General Format Rules for DNS TXT Records ..................11
6.2. DNS-SD TXT Record Size ....................................12 6.2. DNS-SD TXT Record Size ....................................11
6.3. DNS TXT Record Format Rules for Use in DNS-SD .............13 6.3. DNS TXT Record Format Rules for Use in DNS-SD .............13
6.4. Rules for Keys in DNS-SD Key/Value Pairs ..................14 6.4. Rules for Keys in DNS-SD Key/Value Pairs ..................14
6.5. Rules for Values in DNS-SD Key/Value Pairs ................16 6.5. Rules for Values in DNS-SD Key/Value Pairs ................16
6.6. Example TXT Record ........................................17 6.6. Example TXT Record ........................................17
6.7. Version Tag ...............................................17 6.7. Version Tag ...............................................17
6.8. Service Instances with Multiple TXT Records ...............18 6.8. Service Instances with Multiple TXT Records ...............18
7. Service Names ..................................................18 7. Service Names ..................................................19
7.1. Selective Instance Enumeration (Subtypes) .................21 7.1. Selective Instance Enumeration (Subtypes) .................21
7.2. Service Name Length Limits ................................23 7.2. Service Name Length Limits ................................23
8. Flagship Naming ................................................24 8. Flagship Naming ................................................25
9. Service Type Enumeration .......................................26 9. Service Type Enumeration .......................................27
10. Populating the DNS with Information ...........................27 10. Populating the DNS with Information ...........................27
11. Discovery of Browsing and Registration Domains (Domain 11. Discovery of Browsing and Registration Domains (Domain
Enumeration) ..................................................27 Enumeration) ..................................................28
12. DNS Additional Record Generation ..............................29 12. DNS Additional Record Generation ..............................30
12.1. PTR Records ..............................................30 12.1. PTR Records ..............................................30
12.2. SRV Records ..............................................30 12.2. SRV Records ..............................................30
12.3. TXT Records ..............................................30 12.3. TXT Records ..............................................31
12.4. Other Record Types .......................................30 12.4. Other Record Types .......................................31
13. Working Examples ..............................................30 13. Working Examples ..............................................31
13.1. What web pages are being advertised from dns-sd.org? .....31 13.1. What web pages are being advertised from dns-sd.org? .....31
13.2. What printer-configuration web pages are there? ..........31 13.2. What printer-configuration web pages are there? ..........31
13.3. How do I access the web page called "Service 13.3. How do I access the web page called "Service
Discovery"? ..............................................31 Discovery"? ..............................................32
14. IPv6 Considerations ...........................................32 14. IPv6 Considerations ...........................................32
15. Security Considerations .......................................32 15. Security Considerations .......................................32
16. IANA Considerations ...........................................32 16. IANA Considerations ...........................................32
17. Acknowledgments ...............................................33 17. Acknowledgments ...............................................33
18. References ....................................................33 18. References ....................................................33
18.1. Normative References .....................................33 18.1. Normative References .....................................33
18.2. Informative References ...................................34 18.2. Informative References ...................................34
Appendix A. Rationale for Using DNS as a Basis for Service Appendix A. Rationale for Using DNS as a Basis for Service
Discovery .............................................36 Discovery .............................................37
Appendix B. Ordering of Service Instance Name Components ..........38 Appendix B. Ordering of Service Instance Name Components ..........38
B.1. Semantic Structure ........................................38 B.1. Semantic Structure ........................................38
B.2. Network Efficiency ........................................39 B.2. Network Efficiency ........................................39
B.3. Operational Flexibility ...................................39 B.3. Operational Flexibility ...................................39
Appendix C. What You See Is What You Get ..........................39 Appendix C. What You See Is What You Get ..........................40
Appendix D. Choice of Factory-Default Names .......................41 Appendix D. Choice of Factory-Default Names .......................42
Appendix E. Name Encodings in the Domain Name System ..............43 Appendix E. Name Encodings in the Domain Name System ..............44
Appendix F. "Continuous Live Update" Browsing Model ...............44 Appendix F. "Continuous Live Update" Browsing Model ...............45
Appendix G. Deployment History ....................................46 Appendix G. Deployment History ....................................47
1. Introduction 1. Introduction
This document specifies how DNS resource records are named and This document specifies how DNS resource records are named and
structured to facilitate service discovery. Given a type of service structured to facilitate service discovery. Given a type of service
that a client is looking for, and a domain in which the client is that a client is looking for, and a domain in which the client is
looking for that service, this mechanism allows clients to discover looking for that service, this mechanism allows clients to discover a
a list of named instances of that desired service, using standard list of named instances of that desired service, using standard DNS
DNS queries. This is mechanism referred to as DNS-based Service queries. This mechanism is referred to as DNS-based Service
Discovery, or DNS-SD. Discovery, or DNS-SD.
This document proposes no change to the structure of DNS messages, This document proposes no change to the structure of DNS messages,
and no new operation codes, response codes, resource record types, or and no new operation codes, response codes, resource record types, or
any other new DNS protocol values. any other new DNS protocol values.
This document specifies that a particular service instance can be This document specifies that a particular service instance can be
described using a DNS SRV [RFC2782] and DNS TXT [RFC1035] record. described using a DNS SRV [RFC2782] and DNS TXT [RFC1035] record.
The SRV record has a name of the form "<Instance>.<Service>.<Domain>" The SRV record has a name of the form "<Instance>.<Service>.<Domain>"
and gives the target host and port where the service instance can be and gives the target host and port where the service instance can be
skipping to change at page 4, line 13 skipping to change at page 4, line 13
operation may be achieved by simply having the device register its operation may be achieved by simply having the device register its
services in a default registration domain learned from the network services in a default registration domain learned from the network
(see Section 11, "Discovery of Browsing and Registration Domains"), (see Section 11, "Discovery of Browsing and Registration Domains"),
but this is the exception and usually security credentials will be but this is the exception and usually security credentials will be
required to perform DNS updates. required to perform DNS updates.
Note that when using DNS-SD with Unicast DNS, the Unicast DNS-SD Note that when using DNS-SD with Unicast DNS, the Unicast DNS-SD
service does NOT have to be provided by the same DNS server hardware service does NOT have to be provided by the same DNS server hardware
that is currently providing an organization's conventional host name that is currently providing an organization's conventional host name
lookup service. While many people think of "DNS" exclusively in the lookup service. While many people think of "DNS" exclusively in the
context of mapping host names to IP addresses, in fact context of mapping host names to IP addresses, in fact, "the DNS is a
"the DNS is a general (if somewhat limited) hierarchical general (if somewhat limited) hierarchical database, and can store
database, and can store almost any kind of data, for almost any almost any kind of data, for almost any purpose" [RFC2181]. By
purpose" [RFC2181]. By delegating the "_tcp" and "_udp" subdomains, delegating the "_tcp" and "_udp" subdomains, all the workload related
all the workload related to DNS-SD can be offloaded to a different to DNS-SD can be offloaded to a different machine. This flexibility,
machine. This flexibility, to handle DNS-SD on the main DNS server to handle DNS-SD on the main DNS server or not, at the network
or not, at the network administrator's discretion, is one of the administrator's discretion, is one of the benefits of using DNS.
benefits of using DNS.
Even when the DNS-SD functions are delegated to a different machine, Even when the DNS-SD functions are delegated to a different machine,
the benefits of using DNS remain: it is mature technology, well the benefits of using DNS remain: it is mature technology, well
understood, with multiple independent implementations from different understood, with multiple independent implementations from different
vendors, a wide selection of books published on the subject, and an vendors, a wide selection of books published on the subject, and an
established workforce experienced in its operation. In contrast, established workforce experienced in its operation. In contrast,
adopting some other service discovery technology would require every adopting some other service discovery technology would require every
site in the world to install, learn, configure, operate, and maintain site in the world to install, learn, configure, operate, and maintain
some entirely new and unfamiliar server software. Faced with these some entirely new and unfamiliar server software. Faced with these
obstacles, it seems unlikely that any other service discovery obstacles, it seems unlikely that any other service discovery
technology could hope to compete with the ubiquitous deployment that technology could hope to compete with the ubiquitous deployment that
DNS already enjoys. For further discussion see Appendix A, DNS already enjoys. For further discussion, see Appendix A,
"Rationale for Using DNS as a Basis for Service Discovery". "Rationale for Using DNS as a Basis for Service Discovery".
This document is written for two audiences: for developers creating This document is written for two audiences: for developers creating
application software that offers or accesses services on the network, application software that offers or accesses services on the network,
and for developers creating DNS-SD libraries to implement the and for developers creating DNS-SD libraries to implement the
advertising and discovery mechanisms. For both audiences, advertising and discovery mechanisms. For both audiences,
understanding the entire document is helpful. For developers understanding the entire document is helpful. For developers
creating application software, this document provides guidance on creating application software, this document provides guidance on
choosing instance names, service names, and other aspects that play a choosing instance names, service names, and other aspects that play a
role in creating a good overall user experience. However, also role in creating a good overall user experience. However, also
skipping to change at page 15, line 15 skipping to change at page 15, line 18
The characters of a key MUST be printable US-ASCII values (0x20-0x7E) The characters of a key MUST be printable US-ASCII values (0x20-0x7E)
[RFC20], excluding '=' (0x3D). [RFC20], excluding '=' (0x3D).
Spaces in the key are significant, whether leading, trailing, or in Spaces in the key are significant, whether leading, trailing, or in
the middle -- so don't include any spaces unless you really intend the middle -- so don't include any spaces unless you really intend
that. that.
Case is ignored when interpreting a key, so "papersize=A4", Case is ignored when interpreting a key, so "papersize=A4",
"PAPERSIZE=A4", and "Papersize=A4" are all identical. "PAPERSIZE=A4", and "Papersize=A4" are all identical.
If there is no '=' in a DNS-SD TXT record string, then it is a boolean If there is no '=' in a DNS-SD TXT record string, then it is a
attribute, simply identified as being present, with no value. boolean attribute, simply identified as being present, with no value.
A given key SHOULD NOT appear more than once in a TXT record. The A given key SHOULD NOT appear more than once in a TXT record. The
reason for this simplifying rule is to facilitate the creation of reason for this simplifying rule is to facilitate the creation of
client libraries that parse the TXT record into an internal data client libraries that parse the TXT record into an internal data
structure (such as a hash table or dictionary object that maps from structure (such as a hash table or dictionary object that maps from
keys to values) and then make that abstraction available to client keys to values) and then make that abstraction available to client
code. The rule that a given key may not appear more than once code. The rule that a given key may not appear more than once
simplifies these abstractions because they aren't required to support simplifies these abstractions because they aren't required to support
the case of returning more than one value for a given key. the case of returning more than one value for a given key.
skipping to change at page 35, line 45 skipping to change at page 36, line 17
2007. 2007.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS "IPv6 Router Advertisement Options for DNS
Configuration", RFC 6106, November 2010. Configuration", RFC 6106, November 2010.
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac (BTMM) Service", "Understanding Apple's Back to My Mac (BTMM) Service",
RFC 6281, June 2011. RFC 6281, June 2011.
[RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC 6709,
September 2012. September 2012.
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a
Protocol to Replace the AppleTalk Name Binding Protocol Protocol to Replace the AppleTalk Name Binding Protocol
(NBP)", RFC 6760, September 2012. (NBP)", RFC 6760, December 2012.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
May 2012. December 2012.
[SN] IANA, "Service Name and Transport Protocol Port Number [SN] IANA, "Service Name and Transport Protocol Port Number
Registry", <http://www.iana.org/assignments/service- Registry", <http://www.iana.org/assignments/service-
names-port-numbers/>. names-port-numbers/>.
[SOAP] Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C [SOAP] Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C
Proposed Recommendation 24 June 2003, Proposed Recommendation 24 June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part0-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part0-20030624>.
[Unicode6] The Unicode Consortium. The Unicode Standard, Version [Unicode6] The Unicode Consortium. The Unicode Standard, Version
skipping to change at page 42, line 23 skipping to change at page 42, line 50
Xerox Phaser 6200DX Xerox Phaser 6200DX
To make the case for why adding long, ugly factory-unique serial To make the case for why adding long, ugly factory-unique serial
numbers to the end of names is neither necessary nor desirable, numbers to the end of names is neither necessary nor desirable,
consider the cases where the user has (a) only one network printer, consider the cases where the user has (a) only one network printer,
(b) two network printers, and (c) many network printers. (b) two network printers, and (c) many network printers.
(a) In the case where the user has only one network printer, (a) In the case where the user has only one network printer,
a simple name like (to use a vendor-neutral example) a simple name like (to use a vendor-neutral example)
"Printer" is more user-friendly than an ugly name like "Printer" is more user-friendly than an ugly name like
"Printer_0001E68C74FB". Appending ugly hexadecimal goop "Printer_0001E68C74FB". Appending ugly hexadecimal goop to the
to the end of the name to make sure the name is unique is end of the name to make sure the name is unique is irrelevant to
irrelevant to a user who only has one printer anyway. a user who only has one printer anyway.
(b) In the case where the user gets a second network printer, having (b) In the case where the user gets a second network printer, having
the new printer detect that the name "Printer" is already in use the new printer detect that the name "Printer" is already in use
and automatically name itself "Printer (2)" instead, provides a and automatically name itself "Printer (2)" instead, provides a
good user experience. For most users, remembering that the old good user experience. For most users, remembering that the old
printer is "Printer" and the new one is "Printer (2)" is easy printer is "Printer" and the new one is "Printer (2)" is easy
and intuitive. Seeing a printer called "Printer_0001E68C74FB" and intuitive. Seeing a printer called "Printer_0001E68C74FB"
and another called "Printer_00306EC3FD1C" is a lot less helpful. and another called "Printer_00306EC3FD1C" is a lot less helpful.
(c) In the case of a network with ten network printers, seeing a (c) In the case of a network with ten network printers, seeing a
skipping to change at page 46, line 12 skipping to change at page 47, line 12
the old wireless access point, and add all the services the old wireless access point, and add all the services
discovered via the new one. discovered via the new one.
Appendix G. Deployment History Appendix G. Deployment History
In July 1997, in an email to the net-thinkers@thumper.vmeng.com In July 1997, in an email to the net-thinkers@thumper.vmeng.com
mailing list, Stuart Cheshire first proposed the idea of running the mailing list, Stuart Cheshire first proposed the idea of running the
AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of
this and related IETF discussions, the IETF Zeroconf working group this and related IETF discussions, the IETF Zeroconf working group
was chartered September 1999. After various working group was chartered September 1999. After various working group
discussions and other informal IETF discussions, several Internet discussions and other informal IETF discussions, several Internet-
Drafts were written that were loosely related to the general themes Drafts were written that were loosely related to the general themes
of DNS and multicast, but did not address the service discovery of DNS and multicast, but did not address the service discovery
aspect of NBP. aspect of NBP.
In April 2000, Stuart Cheshire registered IPv4 multicast address In April 2000, Stuart Cheshire registered IPv4 multicast address
224.0.0.251 with IANA and began writing code to test and develop the 224.0.0.251 with IANA and began writing code to test and develop the
idea of performing NBP-like service discovery using Multicast DNS, idea of performing NBP-like service discovery using Multicast DNS,
which was documented in a group of three Internet Drafts: which was documented in a group of three Internet-Drafts:
o "Requirements for a Protocol to Replace the AppleTalk Name Binding o "Requirements for a Protocol to Replace the AppleTalk Name Binding
Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk
Name Binding Protocol, because many in the IETF community had Name Binding Protocol, because many in the IETF community had
little first-hand experience using AppleTalk, and confusion in the little first-hand experience using AppleTalk, and confusion in the
IETF community about what AppleTalk NBP did was causing confusion IETF community about what AppleTalk NBP did was causing confusion
about what would be required in an IP-based replacement. about what would be required in an IP-based replacement.
o "Discovering Named Instances of Abstract Services using DNS" o "Discovering Named Instances of Abstract Services using DNS"
[NIAS], which later became this document, proposed a way to [NIAS], which later became this document, proposed a way to
 End of changes. 22 change blocks. 
42 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/