From cc7bb72552184951e806f4d0f2449629b35b9c93 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Wed, 27 Jul 2005 18:39:31 +0000 Subject: implement DBUS protocol git-svn-id: file:///home/lennart/svn/public/avahi/trunk@171 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe --- specs/draft-cheshire-dnsext-dns-sd-03.txt | 1856 +++++++++++++++++++++++++++++ 1 file changed, 1856 insertions(+) create mode 100644 specs/draft-cheshire-dnsext-dns-sd-03.txt (limited to 'specs/draft-cheshire-dnsext-dns-sd-03.txt') diff --git a/specs/draft-cheshire-dnsext-dns-sd-03.txt b/specs/draft-cheshire-dnsext-dns-sd-03.txt new file mode 100644 index 0000000..c412806 --- /dev/null +++ b/specs/draft-cheshire-dnsext-dns-sd-03.txt @@ -0,0 +1,1856 @@ +Document: draft-cheshire-dnsext-dns-sd-03.txt Stuart Cheshire +Category: Standards Track Apple Computer, Inc. +Expires 7th December 2005 Marc Krochmal + Apple Computer, Inc. + 7th June 2005 + + DNS-Based Service Discovery + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), + its areas, and its working groups. Note that other groups may + also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet-Drafts as + reference material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Distribution of this memo is unlimited. + + +Abstract + + This document describes a convention for naming and structuring DNS + resource records. Given a type of service that a client is looking + for, and a domain in which the client is looking for that service, + this convention allows clients to discover a list of named instances + of that desired service, using only standard DNS queries. In short, + this is referred to as DNS-based Service Discovery, or DNS-SD. + + + + + + + + + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 1] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +Table of Contents + + 1. Introduction....................................................3 + 2. Conventions and Terminology Used in this Document...............3 + 3. Design Goals....................................................4 + 4. Service Instance Enumeration....................................5 + 4.1 Structured Instance Names.......................................5 + 4.2 User Interface Presentation.....................................7 + 4.3 Internal Handling of Names......................................7 + 4.4 What You See Is What You Get....................................7 + 4.5 Ordering of Service Instance Name Components....................9 + 5. Service Name Resolution........................................11 + 6. Data Syntax for DNS-SD TXT Records.............................12 + 6.1 General Format Rules for DNS TXT Records.......................12 + 6.2 DNS TXT Record Format Rules for use in DNS-SD..................13 + 6.3 DNS-SD TXT Record Size.........................................14 + 6.4 Rules for Names in DNS-SD Name/Value Pairs.....................14 + 6.5 Rules for Values in DNS-SD Name/Value Pairs....................16 + 6.6 Example TXT Record.............................................16 + 6.7 Version Tag....................................................17 + 7. Application Protocol Names.....................................17 + 7.1 Service Name Length Limits.....................................19 + 8. Selective Instance Enumeration.................................20 + 9. Flagship Naming................................................20 + 10. Service Type Enumeration.......................................22 + 11. Populating the DNS with Information............................23 + 12. Relationship to Multicast DNS..................................23 + 13. Discovery of Browsing and Registration Domains.................24 + 14. DNS Additional Record Generation...............................25 + 15. Comparison with Alternative Service Discovery Protocols........26 + 16. Real Example...................................................28 + 17. IPv6 Considerations............................................29 + 18. Security Considerations........................................29 + 19. IANA Considerations............................................29 + 20. Acknowledgments................................................30 + 21. Copyright......................................................30 + 22. Normative References...........................................31 + 23. Informative References.........................................31 + 24. Authors' Addresses.............................................32 + + + + + + + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 2] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +1. Introduction + + This document describes a convention for naming and structuring DNS + resource records. Given a type of service that a client is looking + for, and a domain in which the client is looking for that service, + this convention allows clients to discover a list of named instances + of a that desired service, using only standard DNS queries. In short, + this is referred to as DNS-based Service Discovery, or DNS-SD. + + This document proposes no change to the structure of DNS messages, + and no new operation codes, response codes, resource record types, + or any other new DNS protocol values. This document simply proposes + a convention for how existing resource record types can be named and + structured to facilitate service discovery. + + This proposal is entirely compatible with today's existing unicast + DNS server and client software. + + Note that the DNS-SD service does NOT have to be provided by the same + DNS server hardware that is currently providing an organization's + conventional host name lookup service (the service we traditionally + think of when we say "DNS"). By delegating the "_tcp" subdomain, all + the workload related to DNS-SD can be offloaded to a different + machine. This flexibility, to handle DNS-SD on the main DNS server, + or not, at the network administrator's discretion, is one of the + things that makes DNS-SD so compelling. + + Even when the DNS-SD functions are delegated to a different machine, + the benefits of using DNS remain: It is mature technology, well + understood, with multiple independent implementations from different + vendors, a wide selection of books published on the subject, and an + established workforce experienced in its operation. In contrast, + adopting some other service discovery technology would require every + site in the world to install, learn, configure, operate and maintain + some entirely new and unfamiliar server software. Faced with these + obstacles, it seems unlikely that any other service discovery + technology could hope to compete with the ubiquitous deployment + that DNS already enjoys. + + This proposal is also compatible with (but not dependent on) the + proposal outlined in "Multicast DNS" [mDNS]. + + +2. Conventions and Terminology Used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in "Key words for use in + RFCs to Indicate Requirement Levels" [RFC 2119]. + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 3] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +3. Design Goals + + A good service discovery protocol needs to have many properties, + three of which are mentioned below: + + (i) The ability to query for services of a certain type in a certain + logical domain and receive in response a list of named instances + (network browsing, or "Service Instance Enumeration"). + + (ii) Given a particular named instance, the ability to efficiently + resolve that instance name to the required information a client needs + to actually use the service, i.e. IP address and port number, at the + very least (Service Name Resolution). + + (iii) Instance names should be relatively persistent. If a user + selects their default printer from a list of available choices today, + then tomorrow they should still be able to print on that printer -- + even if the IP address and/or port number where the service resides + have changed -- without the user (or their software) having to repeat + the network browsing step a second time. + + In addition, if it is to become successful, a service discovery + protocol should be so simple to implement that virtually any + device capable of implementing IP should not have any trouble + implementing the service discovery software as well. + + These goals are discussed in more detail in the remainder of this + document. A more thorough treatment of service discovery requirements + may be found in "Requirements for a Protocol to Replace AppleTalk + NBP" [NBP]. That document draws upon examples from two decades of + operational experience with AppleTalk Name Binding Protocol to + develop a list of universal requirements which are broadly applicable + to any potential service discovery protocol. + + + + + + + + + + + + + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 4] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +4. Service Instance Enumeration + + DNS SRV records [RFC 2782] are useful for locating instances of a + particular type of service when all the instances are effectively + indistinguishable and provide the same service to the client. + + For example, SRV records with the (hypothetical) name + "_http._tcp.example.com." would allow a client to discover a list of + all servers implementing the "_http._tcp" service (i.e. Web servers) + for the "example.com." domain. The unstated assumption is that all + these servers offer an identical set of Web pages, and it doesn't + matter to the client which of the servers it uses, as long as it + selects one at random according to the weight and priority rules laid + out in RFC 2782. + + Instances of other kinds of service are less easily interchangeable. + If a word processing application were to look up the (hypothetical) + SRV record "_ipp._tcp.example.com." to find the list of IPP printers + at Example Co., then picking one at random and printing on it would + probably not be what the user wanted. + + The remainder of this section describes how SRV records may be used + in a slightly different way to allow a user to discover the names + of all available instances of a given type of service, in order to + select the particular instance the user desires. + + +4.1 Structured Instance Names + + This document borrows the logical service naming syntax and semantics + from DNS SRV records, but adds one level of indirection. Instead of + requesting records of type "SRV" with name "_ipp._tcp.example.com.", + the client requests records of type "PTR" (pointer from one name to + another in the DNS namespace). + + In effect, if one thinks of the domain name "_ipp._tcp.example.com." + as being analogous to an absolute path to a directory in a file + system then the PTR lookup is akin to performing a listing of that + directory to find all the files it contains. (Remember that domain + names are expressed in reverse order compared to path names: An + absolute path name is read from left to right, beginning with a + leading slash on the left, and then the top level directory, then the + next level directory, and so on. A fully-qualified domain name is + read from right to left, beginning with the dot on the right -- the + root label -- and then the top level domain to the left of that, and + the second level domain to the left of that, and so on. If the fully- + qualified domain name "_ipp._tcp.example.com." were expressed as a + file system path name, it would be "/com/example/_tcp/_ipp".) + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 5] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + The result of this PTR lookup for the name "." is a + list of zero or more PTR records giving Service Instance Names of the + form: + + Service Instance Name = . . + + The portion of the Service Instance Name is a single DNS + label, containing arbitrary precomposed UTF-8-encoded text [RFC + 2279]. It is a user-friendly name, meaning that it is allowed to + contain any characters, without restriction, including spaces, upper + case, lower case, punctuation -- including dots -- accented + characters, non-roman text, and anything else that may be represented + using UTF-8. DNS recommends guidelines for allowable characters for + host names [RFC 1033][RFC 1034][RFC 1035], but Service Instance Names + are not host names. Service Instance Names are not intended to ever + be typed in by a normal user; the user selects a Service Instance + Name by selecting it from a list of choices presented on the screen. + + Note that just because this protocol supports arbitrary UTF-8-encoded + names doesn't mean that any particular user or administrator is + obliged to make use of that capability. Any user is free, if they + wish, to continue naming their services using only letters, digits + and hyphens, with no spaces, capital letters, or other punctuation. + + DNS labels are currently limited to 63 octets in length. UTF-8 + encoding can require up to four octets per Unicode character, which + means that in the worst case, the portion of a name could + be limited to fifteen Unicode characters. However, the Unicode + characters with longer UTF-8 encodings tend to be the more obscure + ones, and tend to be the ones that convey greater meaning per + character. + + Note that any character in the commonly-used 16-bit Unicode space can + be encoded with no more than three octets of UTF-8 encoding. This + means that an Instance name can contain up to 21 Kanji characters, + which is a sufficiently expressive name for most purposes. + + The portion of the Service Instance Name consists of a pair + of DNS labels, following the established convention for SRV records + [RFC 2782], namely: the first label of the pair is the Application + Protocol Name, and the second label is either "_tcp" or "_udp", + depending on the transport protocol used by the application. + More details are given in Section 7, "Application Protocol Names". + + The portion of the Service Instance Name is a conventional + DNS domain name, consisting of as many labels as appropriate. For + example, "apple.com.", "cs.stanford.edu.", and "eng.us.ibm.com." are + all valid domain names for the portion of the Service + Instance Name. + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 6] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +4.2 User Interface Presentation + + The names resulting from the PTR lookup are presented to the user in + a list for the user to select one (or more). Typically only the first + label is shown (the user-friendly portion of the name). In + the common case, the and are already known to the + user, these having been provided by the user in the first place, by + the act of indicating the service being sought, and the domain in + which to look for it. Note: The software handling the response + should be careful not to make invalid assumptions though, since it + *is* possible, though rare, for a service enumeration in one domain + to return the names of services in a different domain. Similarly, + when using subtypes (see "Selective Instance Enumeration") the + of the discovered instance my not be exactly the same as + the that was requested. + + Having chosen the desired named instance, the Service Instance Name + may then be used immediately, or saved away in some persistent + user-preference data structure for future use, depending on what is + appropriate for the application in question. + + +4.3 Internal Handling of Names + + If the , and portions are internally + concatenated together into a single string, then care must be taken + with the portion, since it is allowed to contain any + characters, including dots. + + Any dots in the portion should be escaped by preceding + them with a backslash ("." becomes "\."). Likewise, any backslashes + in the portion should also be escaped by preceding them + with a backslash ("\" becomes "\\"). Having done this, the three + components of the name may be safely concatenated. The + backslash-escaping allows literal dots in the name (escaped) to be + distinguished from label-separator dots (not escaped). + + The resulting concatenated string may be safely passed to standard + DNS APIs like res_query(), which will interpret the string correctly + provided it has been escaped correctly, as described here. + + +4.4 What You See Is What You Get + + Some service discovery protocols decouple the true service identifier + from the name presented to the user. The true service identifier used + by the protocol is an opaque unique id, often represented using a + long string of hexadecimal digits, and should never be seen by the + typical user. The name presented to the user is merely one of the + ephemeral attributes attached to this opaque identifier. + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 7] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + The problem with this approach is that it decouples user perception + from reality: + + * What happens if there are two service instances, with different + unique ids, but they have inadvertently been given the same + user-visible name? If two instances appear in an on-screen list + with the same name, how does the user know which is which? + + * Suppose a printer breaks down, and the user replaces it with + another printer of the same make and model, and configures the new + printer with the exact same name as the one being replaced: + "Stuart's Printer". Now, when the user tries to print, the + on-screen print dialog tells them that their selected default + printer is "Stuart's Printer". When they browse the network to see + what is there, they see a printer called "Stuart's Printer", yet + when the user tries to print, they are told that the printer + "Stuart's Printer" can't be found. The hidden internal unique id + that the software is trying to find on the network doesn't match + the hidden internal unique id of the new printer, even though its + apparent "name" and its logical purpose for being there are the + same. To remedy this, the user typically has to delete the print + queue they have created, and then create a new (apparently + identical) queue for the new printer, so that the new queue will + contain the right hidden internal unique id. Having all this hidden + information that the user can't see makes for a confusing and + frustrating user experience, and exposing long ugly hexadecimal + strings to the user and forcing them to understand what they mean + is even worse. + + * Suppose an existing printer is moved to a new department, and given + a new name and a new function. Changing the user-visible name of + that piece of hardware doesn't change its hidden internal unique + id. Users who had previously created print queues for that printer + will still be accessing the same hardware by its unique id, even + though the logical service that used to be offered by that hardware + has ceased to exist. + + To solve these problems requires the user or administrator to be + aware of the supposedly hidden unique id, and to set its value + correctly as hardware is moved around, repurposed, or replaced, + thereby contradicting the notion that it is a hidden identifier that + human users never need to deal with. Requiring the user to understand + this expert behind-the-scenes knowledge of what is *really* going on + is just one more burden placed on the user when they are trying to + diagnose why their computers and network devices are not working as + expected. + + These anomalies and counter-intuitive behaviors can be eliminated by + maintaining a tight bidirectional one-to-one mapping between what the + user sees on the screen and what is really happening "behind the + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 8] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + curtain". If something is configured incorrectly, then that is + apparent in the familiar day-to-day user interface that everyone + understands, not in some little-known rarely-used "expert" interface. + + In summary: The user-visible name is the primary identifier for a + service. If the user-visible name is changed, then conceptually the + service being offered is a different logical service -- even though + the hardware offering the service stayed the same. If the + user-visible name doesn't change, then conceptually the service being + offered is the same logical service -- even if the hardware offering + the service is new hardware brought in to replace some old equipment. + + There are certainly arguments on both sides of this debate. + Nonetheless, the designers of any service discovery protocol have + to make a choice between between having the primary identifiers be + hidden, or having them be visible, and these are the reasons that we + chose to make them visible. We're not claiming that there are no + disadvantages of having primary identifiers be visible. We considered + both alternatives, and we believe that the few disadvantages + of visible identifiers are far outweighed by the many problems + caused by use of hidden identifiers. + + +4.5 Ordering of Service Instance Name Components + + There have been questions about why services are named using DNS + Service Instance Names of the form: + + Service Instance Name = . . + + instead of: + + Service Instance Name = . . + + There are three reasons why it is beneficial to name service + instances with the parent domain as the most-significant (rightmost) + part of the name, then the abstract service type as the next-most + significant, and then the specific instance name as the + least-significant (leftmost) part of the name: + + +4.5.1. Semantic Structure + + The facility being provided by browsing ("Service Instance + Enumeration") is effectively enumerating the leaves of a tree + structure. A given domain offers zero or more services. For each of + those service types, there may be zero or more instances of that + service. + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 9] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + The user knows what type of service they are seeking. (If they are + running an FTP client, they are looking for FTP servers. If they have + a document to print, they are looking for entities that speak some + known printing protocol.) The user knows in which organizational or + geographical domain they wish to search. (The user does not want a + single flat list of every single printer on the planet, even if such + a thing were possible.) What the user does not know in advance is + whether the service they seek is offered in the given domain, or if + so, how many instances are offered, and the names of those instances. + Hence having the instance names be the leaves of the tree is + consistent with this semantic model. + + Having the service types be the terminal leaves of the tree would + imply that the user knows the domain name, and already knows the + name of the service instance, but doesn't have any idea what the + service does. We would argue that this is a less useful model. + + +4.5.2. Network Efficiency + + When a DNS response contains multiple answers, name compression works + more effectively if all the names contain a common suffix. If many + answers in the packet have the same and , then each + occurrence of a Service Instance Name can be expressed using only the + part followed by a two-byte compression pointer + referencing a previous appearance of ".". This + efficiency would not be possible if the component appeared + first in each name. + + +4.5.3. Operational Flexibility + + This name structure allows subdomains to be delegated along logical + service boundaries. For example, the network administrator at Example + Co. could choose to delegate the "_tcp.example.com." subdomain to a + different machine, so that the machine handling service discovery + doesn't have to be the same as the machine handling other day-to-day + DNS operations. (It *can* be the same machine if the administrator so + chooses, but the point is that the administrator is free to make that + choice.) Furthermore, if the network administrator wishes to delegate + all information related to IPP printers to a machine dedicated to + that specific task, this is easily done by delegating the + "_ipp._tcp.example.com." subdomain to the desired machine. It is also + convenient to set security policies on a per-zone/per-subdomain + basis. For example, the administrator may choose to enable DNS + Dynamic Update [RFC 2136] [RFC 3007] for printers registering in the + "_ipp._tcp.example.com." subdomain, but not for other + zones/subdomains. This easy flexibility would not exist if the + component appeared first in each name. + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 10] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +5. Service Name Resolution + + Given a particular Service Instance Name, when a client needs to + contact that service, it sends a DNS query for the SRV record of + that name. + + The result of the DNS query is a SRV record giving the port number + and target host where the service may be found. + + The use of SRV records is very important. There are only 65535 TCP + port numbers available. These port numbers are being allocated + one-per-application-protocol at an alarming rate. Some protocols like + the X Window System have a block of 64 TCP ports allocated + (6000-6063). If we start allocating blocks of 64 TCP ports at a time, + we will run out even faster. Using a different TCP port for each + different instance of a given service on a given machine is entirely + sensible, but allocating large static ranges, as was done for X, is a + very inefficient way to manage a limited resource. On any given host, + most TCP ports are reserved for services that will never run on that + particular host. This is very poor utilization of the limited port + space. Using SRV records allows each host to allocate its available + port numbers dynamically to those services running on that host that + need them, and then advertise the allocated port numbers via SRV + records. Allocating the available listening port numbers locally + on a per-host basis as needed allows much better utilization of the + available port space than today's centralized global allocation. + + In some environments there may be no compelling reason to assign + managed names to every host, since every available service is + accessible by name anyway, as a first-class entity in its own right. + However, the DNS packet format and record format still require a host + name to link the target host referenced in the SRV record to the + address records giving the IPv4 and/or IPv6 addresses for that + hardware. In the case where no natural host name is available, the + SRV record may give its own name as the name of the target host, and + then the requisite address records may be attached to that same name. + It is perfectly permissible for a single name in the DNS hierarchy to + have multiple records of different type attached. (The only + restriction being that a given name may not have both a CNAME record + and other records at the same time.) + + In the event that more than one SRV is returned, clients MUST + correctly interpret the priority and weight fields -- i.e. Lower + numbered priority servers should be used in preference to higher + numbered priority servers, and servers with equal priority should be + selected randomly in proportion to their relative weights. However, + in the overwhelmingly common case, a single advertised DNS-SD service + instance is described by exactly one SRV record, and in this common + case the priority and weight fields of the SRV record SHOULD both be + set to zero. + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 11] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +6. Data Syntax for DNS-SD TXT Records + + Some services discovered via Service Instance Enumeration may need + more than just an IP address and port number to properly identify the + service. For example, printing via the LPR protocol often specifies a + queue name. This queue name is typically short and cryptic, and need + not be shown to the user. It should be regarded the same way as the + IP address and port number -- it is one component of the addressing + information required to identify a specific instance of a service + being offered by some piece of hardware. Similarly, a file server may + have multiple volumes, each identified by its own volume name. A Web + server typically has multiple pages, each identified by its own URL. + In these cases, the necessary additional data is stored in a TXT + record with the same name as the SRV record. The specific nature of + that additional data, and how it is to be used, is service-dependent, + but the overall syntax of the data in the TXT record is standardized, + as described below. Every DNS-SD service MUST have a TXT record in + addition to its SRV record, with same name, even if the service has + no additional data to store and the TXT record contains no more than + a single zero byte. + + +6.1 General Format Rules for DNS TXT Records + + A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total + length is indicated by the length given in the resource record header + in the DNS message. There is no way to tell directly from the data + alone how long it is (e.g. there is no length count at the start, or + terminating NULL byte at the end). (Note that when using Multicast + DNS [mDNS] the maximum packet size is 9000 bytes, which imposes an + upper limit on the size of TXT records of about 8800 bytes.) + + The format of the data within a DNS TXT record is one or more + strings, packed together in memory without any intervening gaps or + padding bytes for word alignment. + + The format of each constituent string within the DNS TXT record is a + single length byte, followed by 0-255 bytes of text data. + + These format rules are defined in Section 3.3.14 of RFC 1035, and are + not specific to DNS-SD. DNS-SD simply specifies a usage convention + for what data should be stored in those constituent strings. + + An empty TXT record containing zero strings is disallowed by RFC + 1035. DNS-SD implementations MUST NOT emit empty TXT records. DNS-SD + implementations receiving empty TXT records MUST treat them as + equivalent to a one-byte TXT record containing a single zero byte + (i.e. a single empty string). + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 12] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +6.2 DNS TXT Record Format Rules for use in DNS-SD + + DNS-SD uses DNS TXT records to store arbitrary name/value pairs + conveying additional information about the named service. Each + name/value pair is encoded as its own constituent string within the + DNS TXT record, in the form "name=value". Everything up to the first + '=' character is the name. Everything after the first '=' character + to the end of the string (including subsequent '=' characters, if + any) is the value. Specific rules governing names and values are + given below. Each author defining a DNS-SD profile for discovering + instances of a particular type of service should define the base set + of name/value attributes that are valid for that type of service. + + Using this standardized name/value syntax within the TXT record makes + it easier for these base definitions to be expanded later by defining + additional named attributes. If an implementation sees unknown + attribute names in a service TXT record, it MUST silently ignore + them. + + The TCP (or UDP) port number of the service, and target host name, + are given in the SRV record. This information -- target host name and + port number -- MUST NOT be duplicated using name/value attributes in + the TXT record. + + The intention of DNS-SD TXT records is to convey a small amount of + useful additional information about a service. Ideally it SHOULD NOT + be necessary for a client to retrieve this additional information + before it can usefully establish a connection to the service. For a + well-designed TCP-based application protocol, it should be possible, + knowing only the host name and port number, to open a connection to + that listening process, and then perform version- or feature- + negotiation to determine the capabilities of the service instance. + For example, when connecting to an AppleShare server over TCP, the + client enters into a protocol exchange with the server to determine + which version of the AppleShare protocol the server implements, and + which optional features or capabilities (if any) are available. For a + well-designed application protocol, clients should be able to connect + and use the service even if there is no information at all in the TXT + record. In this case, the information in the TXT record should be + viewed as a performance optimization -- when a client discovers many + instances of a service, the TXT record allows the client to know some + rudimentary information about each instance without having to open a + TCP connection to each one and interrogate every service instance + separately. Extreme care should be taken when doing this to ensure + that the information in the TXT record is in agreement with the + information retrieved by a client connecting over TCP. + + There are legacy protocols which provide no feature negotiation + capability, and in these cases it may be useful to convey necessary + information in the TXT record. For example, when printing using the + old Unix LPR (port 515) protocol, the LPR service provides no way for + + +Expires 7th December 2005 Cheshire & Krochmal [Page 13] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + the client to determine whether a particular printer accepts + PostScript, or what version of PostScript, etc. In this case it is + appropriate to embed this information in the TXT record, because the + alternative is worse -- passing around written instructions to the + users, arcane manual configuration of "/etc/printcap" files, etc. + + +6.3 DNS-SD TXT Record Size + + The total size of a typical DNS-SD TXT record is intended to be small + -- 200 bytes or less. + + In cases where more data is justified (e.g. LPR printing), keeping + the total size under 400 bytes should allow it to fit in a single + standard 512-byte DNS message. (This standard DNS message size is + defined in RFC 1035.) + + In extreme cases where even this is not enough, keeping the size of + the TXT record under 1300 bytes should allow it to fit in a single + 1500-byte Ethernet packet. + + Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this + time. + + +6.4 Rules for Names in DNS-SD Name/Value Pairs + + The "Name" MUST be at least one character. Strings beginning with an + '=' character (i.e. the name is missing) SHOULD be silently ignored. + + The characters of "Name" MUST be printable US-ASCII values + (0x20-0x7E), excluding '=' (0x3D). + + Spaces in the name are significant, whether leading, trailing, or in + the middle -- so don't include any spaces unless you really intend + that! + + Case is ignored when interpreting a name, so "papersize=A4", + "PAPERSIZE=A4" and "Papersize=A4" are all identical. + + If there is no '=', then it is a boolean attribute, and is simply + identified as being present, with no value. + + A given attribute name may appear at most once in a TXT record. If a + client receives a TXT record containing the same attribute name more + than once, then the client MUST silently ignore all but the first + occurrence of that attribute. For client implementations that process + a DNS-SD TXT record from start to end, placing name/value pairs into + a hash table, using the name as the hash table key, this means that + if the implementation attempts to add a new name/value pair into the + table and finds an entry with the same name already present, then the + + +Expires 7th December 2005 Cheshire & Krochmal [Page 14] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + new entry being added should be silently discarded instead. For + client implementations that retrieve name/value pairs by searching + the TXT record for the requested name, they should search the TXT + record from the start, and simply return the first matching name they + find. The reason for this simplifying rule is to facilitate the + creation of client libraries that parse the TXT record into an + internal data structure, such as a hash table or dictionary object + that maps from names to values, and then make that abstraction + available to client code. + + When examining a TXT record for a given named attribute, there are + therefore four broad categories of results which may be returned: + + * Attribute not present (Absent) + + * Attribute present, with no value + (e.g. "Anon Allowed" -- server allows anonymous connections) + + * Attribute present, with empty value (e.g. "Installed PlugIns=" -- + server supports plugins, but none are presently installed) + + * Attribute present, with non-empty value + (e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4") + + Each author defining a DNS-SD profile for discovering instances of a + particular type of service should define the interpretation of these + different kinds of result. For example, for some keys, there may be + a natural true/false boolean interpretation: + + * Present implies 'true' + * Absent implies 'false' + + For other keys it may be sensible to define other semantics, such as + value/no-value/unknown: + + * Present with value implies that value. + E.g. "Color=4" for a four-color ink-jet printer, + or "Color=6" for a six-color ink-jet printer. + + * Present with empty value implies 'false'. E.g. Not a color printer. + + * Absent implies 'Unknown'. E.g. A print server connected to some + unknown printer where the print server doesn't actually know if the + printer does color or not -- which gives a very bad user experience + and should be avoided wherever possible. + + (Note that this is a hypothetical example, not an example of actual + name/value keys used by DNS-SD network printers.) + + As a general rule, attribute names that contain no dots are defined + as part of the open-standard definition written by the person or + + +Expires 7th December 2005 Cheshire & Krochmal [Page 15] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + group defining the DNS-SD profile for discovering that particular + service type. Vendor-specific extensions should be given names of the + form "keyname.company.com=value", using a domain name legitimately + registered to the person or organization creating the vendor-specific + key. This reduces the risk of accidental conflict if different + organizations each define their own vendor-specific keys. + + +6.5 Rules for Values in DNS-SD Name/Value Pairs + + If there is an '=', then everything after the first '=' to the end of + the string is the value. The value can contain any eight-bit values + including '='. Leading or trailing spaces are part of the value, so + don't put them there unless you intend them to be there. Any + quotation marks around the value are part of the value, so don't put + them there unless you intend them to be part of the value. + + The value is opaque binary data. Often the value for a particular + attribute will be US-ASCII (or UTF-8) text, but it is legal for a + value to be any binary data. For example, if the value of a key is an + IPv4 address, that address should simply be stored as four bytes of + binary data, not as a variable-length 7-15 byte ASCII string giving + the address represented in textual dotted decimal notation. + + Generic debugging tools should generally display all attribute values + as a hex dump, with accompanying text alongside displaying the UTF-8 + interpretation of those bytes, except for attributes where the + debugging tool has embedded knowledge that the value is some other + kind of data. + + Authors defining DNS-SD profiles SHOULD NOT convert binary attribute + data types into printable text (e.g. using hexadecimal, Base-64 or UU + encoding) merely for the sake of making the data be printable text + when seen in a generic debugging tool. Doing this simply bloats the + size of the TXT record, without actually making the data any more + understandable to someone looking at it in a generic debugging tool. + + +6.6 Example TXT Record + + The TXT record below contains three syntactically valid name/value + pairs. (The meaning of these name/value pairs, if any, would depend + on the definitions pertaining to the service in question that is + using them.) + + --------------------------------------------------------------- + | 0x0A | name=value | 0x08 | paper=A4 | 0x0E | DNS-SD Is Cool | + --------------------------------------------------------------- + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 16] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +6.7 Version Tag + + It is recommended that authors defining DNS-SD profiles include an + attribute of the form "txtvers=xxx" in their definition, and require + it to be the first name/value pair in the TXT record. This + information in the TXT record can be useful to help clients maintain + backwards compatibility with older implementations if it becomes + necessary to change or update the specification over time. Even if + the profile author doesn't anticipate the need for any future + incompatible changes, having a version number in the specification + provides useful insurance should incompatible changes become + unavoidable. Clients SHOULD ignore TXT records with a txtvers number + higher (or lower) than the version(s) they know how to interpret. + + Note that the version number in the txtvers tag describes the version + of the TXT record specification being used to create this TXT record, + not the version of the application protocol that will be used if the + client subsequently decides to contact that service. Ideally, every + DNS-SD TXT record specification starts at txtvers=1 and stays that + way forever. Improvements can be made by defining new keys that older + clients silently ignore. The only reason to increment the version + number is if the old specification is subsequently found to be so + horribly broken that there's no way to do a compatible forward + revision, so the txtvers number has to be incremented to tell all the + old clients they should just not even try to understand this new TXT + record. + + If there is a need to indicate which version number(s) of the + application protocol the service implements, the recommended key + name for this is "protovers". + + +7. Application Protocol Names + + The portion of a Service Instance Name consists of a pair + of DNS labels, following the established convention for SRV records + [RFC 2782], namely: the first label of the pair is the Application + Protocol Name, and the second label is either "_tcp" or "_udp". + + Wise selection of the Application Protocol Name is very important, + and the choice is not always as obvious as it may appear. + + Application Protocol Names may be no more than fourteen characters, + conforming to normal DNS host name rules: Only lower-case letters, + digits, and hyphens; must begin and end with lower-case letter or + digit. + + In some cases, the Application Protocol Name merely names and refers + to the on-the-wire message format and semantics being used. FTP is + "ftp", IPP printing is "ipp", and so on. + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 17] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + However, it is common to "borrow" an existing protocol and repurpose + it for a new task. This is entirely sensible and sound engineering + practice, but that doesn't mean that the new protocol is providing + the same semantic service as the old one, even if it borrows the same + message formats. For example, the local network music playing + protocol implemented by iTunes on Macintosh and Windows is little + more than "HTTP GET" commands. However, that does *not* mean that it + is sensible or useful to try to access one of these music servers by + connecting to it with a standard web browser. Consequently, the + DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp" + (Digital Audio Access Protocol), not "_http._tcp". Advertising + "_http._tcp" service would cause iTunes servers to show up in + conventional Web browsers (Safari, Camino, OmniWeb, Opera, Netscape, + Internet Explorer, etc.) which is little use since it offers no pages + containing human-readable content. Similarly, browsing for + "_http._tcp" service would cause iTunes to find generic web servers, + such as the embedded web servers in devices like printers, which is + little use since printers generally don't have much music to offer. + + Similarly, NFS is built on top of SUN RPC, but that doesn't mean it + makes sense for an NFS server to advertise that it provides "SUN RPC" + service. Likewise, Microsoft SMB file service is built on top of + Netbios running over IP, but that doesn't mean it makes sense for an + SMB file server to advertise that it provides "Netbios-over-IP" + service. The DNS-SD name of a service needs to encapsulate both the + "what" (semantics) and the "how" (protocol implementation) of the + service, since knowledge of both is necessary for a client to + usefully use the service. Merely advertising that a service was built + on top of SUN RPC is no use if the client has no idea what the + service actually does. + + Another common mistake is to assume that the service type advertised + by iTunes should be "_daap._http._tcp." This is also incorrect. Part + of the confusion here is that the presence of "_tcp" or "_udp" in the + portion of a Service Instance Name has led people to assume + that the structure of a service name has to reflect the internal + structure of how the protocol was implemented. This is not correct. + + The "_tcp" or "_udp" should be regarded as little more than + boilerplate text, and care should be taken not to attach too much + importance to it. Some might argue that the "_tcp" or "_udp" should + not be there at all, but this format is defined by RFC 2782, and + that's not going to change. In addition, the presence of "_tcp" has + the useful side-effect that it provides a convenient delegation point + to hand off control to a different DNS server, if so desired. + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 18] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +7.1 Service Name Length Limits + + As described above, application protocol names are allowed to be up + to fourteen characters long. The reason for this limit is to leave + as many bytes of the domain name as possible available for use + by both the network administrator (choosing service domain names) + and the end user (choosing instance names). + + A domain name may be up to 255 bytes long, including the final + terminating root label at the end. Domain names used by DNS-SD + take the following forms: + + .._tcp... + ._sub.._tcp... + + The first example shows a service instance name, i.e. the name of the + service's SRV and TXT records. The second shows a subtype browsing + name, i.e. the name of a PTR record pointing to service instance + names. + + The instance name may be up to 63 bytes. Including the + length byte used by the DNS format when the name is stored in a + packet, that makes 64 bytes. + + When using subtypes, the subtype identifier is allowed to be up to + 63 bytes, plus the length byte, making 64. Including the "_sub" + and its length byte, this makes 69 bytes. + + The application protocol name may be up to 14 bytes, plus the + underscore and length byte, making 16. Including the "_udp" or "_tcp" + and its length byte, this makes 21 bytes. + + Typically, DNS-SD service records are placed into subdomains of their + own beneath a company's existing domain name. Since these subdomains + are intended to be accessed through graphical user interfaces, not + typed on a command-line they are frequently long and descriptive. + Including the length byte, the user-visible service domain may be up + to 64 bytes. + + The terminating root label at the end counts as one byte. + + Of our available 255 bytes, we have now accounted for 69+21+64+1 = + 155 bytes. This leaves 100 bytes to accommodate the organization's + existing domain name . When used with Multicast DNS, + is "local", which easily fits. When used with parent + domains of 100 bytes or less, the full functionality of DNS-SD is + available without restriction. When used with parent domains longer + than 100 bytes, the protocol risks exceeding the maximum possible + length of domain names, causing failures. In this case, careful + choice of short names can help avoid overflows. If + the and are too long, then service + + +Expires 7th December 2005 Cheshire & Krochmal [Page 19] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + instances with long instance names will not be discoverable or + resolvable, and applications making use of long subtype names may + fail. + + Because of this constraint, we choose to limit Application Protocol + Names to 14 characters or less. Allowing more characters would not + add to the expressive power of the protocol, and would needlessly + lower the limit on the maximum length that may be + safely used. + + +8. Selective Instance Enumeration + + This document does not attempt to define an arbitrary query language + for service discovery, nor do we believe one is necessary. + + However, there are some circumstances where narrowing the list of + results may be useful. A Web browser client that is able to retrieve + HTML documents via HTTP and display them may also be able to retrieve + HTML documents via FTP and display them, but only in the case of FTP + servers that allow anonymous login. For that Web browser, discovering + all FTP servers on the network is not useful. The Web browser only + wants to discover FTP servers that it is able to talk to. In this + case, a subtype of "_ftp._tcp" could be defined. Instead of issuing a + query for "_ftp._tcp.", the Web browser issues a query for + "_anon._sub._ftp._tcp.", where "_anon" is a defined subtype + of "_ftp._tcp". The response to this query only includes the names of + SRV records for FTP servers that are willing to allow anonymous + login. + + Note that the FTP server's Service Instance Name is unchanged -- it + is still something of the form "The Server._ftp._tcp.example.com." + The subdomain in which FTP server SRV records are registered defines + the namespace within which FTP server names are unique. Additional + subtypes (e.g. "_anon") of the basic service type (e.g. "_ftp._tcp") + serve to narrow the list of results, not to create more namespace. + + As with the TXT record name/value pairs, the list of possible + subtypes, if any, are defined and specified separately for each basic + service type. + + +9. Flagship Naming + + In some cases, there may be several network protocols available which + all perform roughly the same logical function. For example, the + printing world has the LPR protocol, and the Internet Printing + Protocol (IPP), both of which cause printed sheets to be emitted from + printers in much the same way. In addition, many printer vendors send + their own proprietary page description language (PDL) data over a TCP + connection to TCP port 9100, herein referred to as the + + +Expires 7th December 2005 Cheshire & Krochmal [Page 20] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + "pdl-datastream" protocol. In an ideal world we would have only one + network printing protocol, and it would be sufficiently good that no + one felt a compelling need to invent a different one. However, in + practice, multiple legacy protocols do exist, and a service discovery + protocol has to accommodate that. + + Many printers implement all three printing protocols: LPR, IPP, and + pdl-datastream. For the benefit of clients that may speak only one of + those protocols, all three are advertised. + + However, some clients may implement two, or all three of those + printing protocols. When a client looks for all three service types + on the network, it will find three distinct services -- an LPR + service, an IPP service, and a pdl-datastream service -- all of which + cause printed sheets to be emitted from the same physical printer. + + In the case of multiple protocols like this that all perform + effectively the same function, the client should suppress duplicate + names and display each name only once. When the user prints to a + given named printer, the printing client is responsible for choosing + the protocol which will best achieve the desired effect, without, for + example, requiring the user to make a manual choice between LPR and + IPP. + + As described so far, this all works very well. However, consider some + future printer that only supports IPP printing, and some other future + printer that only supports pdl-datastream printing. The name spaces + for different service types are intentionally disjoint -- it is + acceptable and desirable to be able to have both a file server called + "Sales Department" and a printer called "Sales Department". However, + it is not desirable, in the common case, to have two different + printers both called "Sales Department", just because those printers + are implementing different protocols. + + To help guard against this, when there are two or more network + protocols which perform roughly the same logical function, one of the + protocols is declared the "flagship" of the fleet of related + protocols. Typically the flagship protocol is the oldest and/or + best-known protocol of the set. + + If a device does not implement the flagship protocol, then it instead + creates a placeholder SRV record (priority=0, weight=0, port=0, + target host = hostname of device) with that name. If, when it + attempts to create this SRV record, it finds that a record with the + same name already exists, then it knows that this name is already + taken by some entity implementing at least one of the protocols from + the class, and it must choose another. If no SRV record already + exists, then the act of creating it stakes a claim to that name so + that future devices in the same class will detect a conflict when + they try to use it. The SRV record needs to contain the target host + name in order for the conflict detection rules to operate. If two + + +Expires 7th December 2005 Cheshire & Krochmal [Page 21] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + different devices were to create placeholder SRV records both using a + null target host name (just the root label), then the two SRV records + would be seen to be in agreement so no conflict would be registered. + + By defining a common well-known flagship protocol for the class, + future devices that may not even know about each other's protocols + establish a common ground where they can coordinate to verify + uniqueness of names. + + No PTR record is created advertising the presence of empty flagship + SRV records, since they do not represent a real service being + advertised. + + +10. Service Type Enumeration + + In general, clients are not interested in finding *every* service on + the network, just the services that the client knows how to talk to. + (Software designers may *think* there's some value to finding *every* + service on the network, but that's just wooly thinking.) + + However, for problem diagnosis and network management tools, it may + be useful for network administrators to find the list of advertised + service types on the network, even if those service names are just + opaque identifiers and not particularly informative in isolation. + + For this reason, a special meta-query is defined. A DNS query for + PTR records with the name "_services._dns-sd._udp." yields + a list of PTR records, where the rdata of each PTR record is the + name of a service type. A subsequent query for PTR records with + one of those names yields a list of instances of that service type. + + + + + + + + + + + + + + + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 22] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +11. Populating the DNS with Information + + How the SRV and PTR records that describe services and allow them to + be enumerated make their way into the DNS is outside the scope of + this document. However, it can happen easily in any of a number of + ways, for example: + + On some networks, the administrator might manually enter the records + into the name server's configuration file. + + A network monitoring tool could output a standard zone file to be + read into a conventional DNS server. For example, a tool that can + find Apple LaserWriters using AppleTalk NBP could find the list of + printers, communicate with each one to find its IP address, + PostScript version, installed options, etc., and then write out a DNS + zone file describing those printers and their capabilities using DNS + resource records. That information would then be available to DNS-SD + clients that don't implement AppleTalk NBP, and don't want to. + + Future IP printers could use Dynamic DNS Update [RFC 2136] to + automatically register their own SRV and PTR records with the DNS + server. + + A printer manager device which has knowledge of printers on the + network through some other management protocol could also use Dynamic + DNS Update [RFC 2136]. + + Alternatively, a printer manager device could implement enough of the + DNS protocol that it is able to answer DNS queries directly, and + Example Co.'s main DNS server could delegate the + _ipp._tcp.example.com subdomain to the printer manager device. + + Zeroconf printers answer Multicast DNS queries on the local link + for appropriate PTR and SRV names ending with ".local." [mDNS] + + +12. Relationship to Multicast DNS + + DNS-Based Service Discovery is only peripherally related to Multicast + DNS, in that the standard unicast DNS queries used by DNS-SD may also + be performed using multicast when appropriate, which is particularly + beneficial in Zeroconf environments [ZC]. + + + + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 23] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +13. Discovery of Browsing and Registration Domains (Domain Enumeration) + + One of the main reasons for DNS-Based Service Discovery is so that + when a visiting client (e.g. a laptop computer) arrives at a new + network, it can discover what services are available on that network + without manual configuration. This logic that applies to discovering + services without manual configuration also applies to discovering the + domains in which services are registered without requiring manual + configuration. + + This discovery is performed recursively, using Unicast or Multicast + DNS. Five special RR names are reserved for this purpose: + + b._dns-sd._udp.. + db._dns-sd._udp.. + r._dns-sd._udp.. + dr._dns-sd._udp.. + lb._dns-sd._udp.. + + By performing PTR queries for these names, a client can learn, + respectively: + + o A list of domains recommended for browsing + + o A single recommended default domain for browsing + + o A list of domains recommended for registering services using + Dynamic Update + + o A single recommended default domain for registering services. + + o The final query shown yields the "legacy browsing" domain. + Sophisticated client applications that care to present choices of + domain to the user, use the answers learned from the previous four + queries to discover those domains to present. In contrast, many + current applications browse without specifying an explicit domain, + allowing the operating system to automatically select an + appropriate domain on their behalf. It is for this class of + application that the "legacy browsing" query is provided, to allow + the network administrator to communicate to the client operating + systems which domain should be used for these applications. + + These domains are purely advisory. The client or user is free to + browse and/or register services in any domains. The purpose of these + special queries is to allow software to create a user-interface that + displays a useful list of suggested choices to the user, from which + they may make a suitable selection, or ignore the offered suggestions + and manually enter their own choice. + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 24] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + The part of the name may be "local" (meaning "perform the + query using link-local multicast) or it may be learned through some + other mechanism, such as the DHCP "Domain" option (option code 15) + [RFC 2132] or the DHCP "Domain Search" option (option code 119) + [RFC 3397]. + + The part of the name may also be derived from the host's IP + address. The host takes its IP address, and calculates the logical + AND of that address and its subnet mask, to derive the 'base' address + of the subnet. It then constructs the conventional DNS "reverse + mapping" name corresponding to that base address, and uses that as + the part of the name for the queries described above. + For example, if a host has address 192.168.12.34, with subnet mask + 255.255.0.0, then the 'base' address of the subnet is 192.168.0.0, + and to discover the recommended legacy browsing domain for devices + on this subnet, the host issues a DNS PTR query for the name + "lb._dns-sd._udp.0.0.168.192.in-addr.arpa." + + Sophisticated clients may perform domain enumeration queries both in + "local" and in one or more unicast domains, and then present the user + with an aggregate result, combining the information received from all + sources. + + +14. DNS Additional Record Generation + + DNS has an efficiency feature whereby a DNS server may place + additional records in the Additional Section of the DNS Message. + These additional records are typically records that the client did + not explicitly request, but the server has reasonable grounds to + expect that the client might request them shortly. + + This section recommends which additional records should be generated + to improve network efficiency for both unicast and multicast DNS-SD + responses. + + +14.1 PTR Records + + When including a PTR record in a response packet, the + server/responder SHOULD include the following additional records: + + o The SRV record(s) named in the PTR rdata. + o The TXT record(s) named in the PTR rdata. + o All address records (type "A" and "AAAA") named in the SRV rdata. + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 25] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +14.2 SRV Records + + When including an SVR record in a response packet, the + server/responder SHOULD include the following additional records: + + o All address records (type "A" and "AAAA") named in the SRV rdata. + + +14.3 TXT Records + + When including a TXT record in a response packet, no additional + records are required. + + +14.4 Other Record Types + + In response to address queries, or other record types, no additional + records are required by this document. + + +15. Comparison with Alternative Service Discovery Protocols + + Over the years there have been many proposed ways to do network + service discovery with IP, but none achieved ubiquity in the + marketplace. Certainly none has achieved anything close to the + ubiquity of today's deployment of DNS servers, clients, and other + infrastructure. + + The advantage of using DNS as the basis for service discovery is that + it makes use of those existing servers, clients, protocols, + infrastructure, and expertise. Existing network analyzer tools + already know how to decode and display DNS packets for network + debugging. + + For ad-hoc networks such as Zeroconf environments, peer-to-peer + multicast protocols are appropriate. The Zeroconf host profile [ZCHP] + requires the use of a DNS-like protocol over IP Multicast for host + name resolution in the absence of DNS servers. Given that Zeroconf + hosts will have to implement this Multicast-based DNS-like protocol + anyway, it makes sense for them to also perform service discovery + using that same Multicast-based DNS-like software, instead of also + having to implement an entirely different service discovery protocol. + + In larger networks, a high volume of enterprise-wide IP multicast + traffic may not be desirable, so any credible service discovery + protocol intended for larger networks has to provide some facility to + aggregate registrations and lookups at a central server (or servers) + instead of working exclusively using multicast. This requires some + service discovery aggregation server software to be written, + debugged, deployed, and maintained. This also requires some service + discovery registration protocol to be implemented and deployed for + + +Expires 7th December 2005 Cheshire & Krochmal [Page 26] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + clients to register with the central aggregation server. Virtually + every company with an IP network already runs a DNS server, and DNS + already has a dynamic registration protocol [RFC 2136]. Given that + virtually every company already has to operate and maintain a DNS + server anyway, it makes sense to take advantage of this instead of + also having to learn, operate and maintain a different service + registration server. It should be stressed again that using the same + software and protocols doesn't necessarily mean using the same + physical piece of hardware. The DNS-SD service discovery functions + do not have to be provided by the same piece of hardware that + is currently providing the company's DNS name service. The + "_tcp." subdomain may be delegated to a different piece of + hardware. However, even when the DNS-SD service is being provided by + a different piece of hardware, it is still the same familiar DNS + server software that is running, with the same configuration file + syntax, the same log file format, and so forth. + + Service discovery needs to be able to provide appropriate security. + DNS already has existing mechanisms for security [RFC 2535]. + + In summary: + + Service discovery requires a central aggregation server. + DNS already has one: It's called a DNS server. + + Service discovery requires a service registration protocol. + DNS already has one: It's called DNS Dynamic Update. + + Service discovery requires a query protocol + DNS already has one: It's called DNS. + + Service discovery requires security mechanisms. + DNS already has security mechanisms: DNSSEC. + + Service discovery requires a multicast mode for ad-hoc networks. + Zeroconf environments already require a multicast-based DNS-like + name lookup protocol for mapping host names to addresses, so it + makes sense to let one multicast-based protocol do both jobs. + + It makes more sense to use the existing software that every network + needs already, instead of deploying an entire parallel system just + for service discovery. + + + + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 27] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +16. Real Example + + The following examples were prepared using standard unmodified + nslookup and standard unmodified BIND running on GNU/Linux. + + Note: In real products, this information is obtained and presented to + the user using graphical network browser software, not command-line + tools, but if you wish you can try these examples for yourself as you + read along, using the command-line tools already available on your + own Unix machine. + +16.1 Question: What FTP servers are being advertised from dns-sd.org? + + nslookup -q=ptr _ftp._tcp.dns-sd.org. + _ftp._tcp.dns-sd.org + name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org + _ftp._tcp.dns-sd.org + name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org + _ftp._tcp.dns-sd.org + name = Registered\032Users'\032Only._ftp._tcp.dns-sd.org + + Answer: There are three, called "Apple QuickTime Files", + "Microsoft Developer Files" and "Registered Users' Only". + + Note that nslookup escapes spaces as "\032" for display purposes, + but a graphical DNS-SD browser does not. + +16.2 Question: What FTP servers allow anonymous access? + + nslookup -q=ptr _anon._sub._ftp._tcp.dns-sd.org + _anon._sub._ftp._tcp.dns-sd.org + name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org + _anon._sub._ftp._tcp.dns-sd.org + name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org + + Answer: Only "Apple QuickTime Files" and "Microsoft Developer Files" + allow anonymous access. + +16.3 Question: How do I access "Apple QuickTime Files"? + + nslookup -q=any "Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org." + Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org + text = "path=/quicktime" + Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org + priority = 0, weight = 0, port= 21 host = ftp.apple.com + ftp.apple.com internet address = 17.254.0.27 + ftp.apple.com internet address = 17.254.0.31 + ftp.apple.com internet address = 17.254.0.26 + + Answer: You need to connect to ftp.apple.com, port 21, path + "/quicktime". The addresses for ftp.apple.com are also given. + + +Expires 7th December 2005 Cheshire & Krochmal [Page 28] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + +17. IPv6 Considerations + + IPv6 has no significant differences, except that the address of the + SRV record's target host is given by the appropriate IPv6 address + records instead of the IPv4 "A" record. + + +18. Security Considerations + + DNSSEC [RFC 2535] should be used where the authenticity of + information is important. Since DNS-SD is just a naming and usage + convention for records in the existing DNS system, it has no specific + additional security requirements over and above those that already + apply to DNS queries and DNS updates. + + +19. IANA Considerations + + This protocol builds on DNS SRV records [RFC 2782], and similarly + requires IANA to assign unique application protocol names. + Unfortunately, the "IANA Considerations" section of RFC 2782 says + simply, "The IANA has assigned RR type value 33 to the SRV RR. + No other IANA services are required by this document." + Due to this oversight, IANA is currently prevented from carrying + out the necessary function of assigning these unique identifiers. + + This document proposes the following IANA allocation policy for + unique application protocol names: + + Allowable names: + * Must be no more than fourteen characters long + * Must consist only of: + - lower-case letters 'a' - 'z' + - digits '0' - '9' + - the hyphen character '-' + * Must begin and end with a lower-case letter or digit. + * Must not already be assigned to some other protocol in the + existing IANA "list of assigned application protocol names + and port numbers" [ports]. + + These identifiers are allocated on a First Come First Served basis. + In the event of abuse (e.g. automated mass registrations, etc.), + the policy may be changed without notice to Expert Review [RFC 2434]. + + The textual nature of service/protocol names means that there are + almost infinitely many more of them available than the finite set of + 65535 possible port numbers. This means that developers can produce + experimental implementations using unregistered service names with + little chance of accidental collision, providing service names are + chosen with appropriate care. However, this document strongly + advocates that on or before the date a product ships, developers + should properly register their service names. + +Expires 7th December 2005 Cheshire & Krochmal [Page 29] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + Some developers have expressed concern that publicly registering + their service names (and port numbers today) with IANA before a + product ships may give away clues about that product to competitors. + For this reason, IANA should consider allowing service name + applications to remain secret for some period of time, much as US + patent applications remain secret for two years after the date of + filing. + + This proposed IANA allocation policy is not in force until this + document is published as an RFC. In the meantime, unique application + protocol names may be registered according to the instructions at + . As of January 2004, there + are roughly 100 application protocols in currently shipping products + that have been so registered as using DNS-SD for service discovery. + + +20. Acknowledgments + + The concepts described in this document have been explored, developed + and implemented with help from Richard Brown, Erik Guttman, Paul + Vixie, and Bill Woodcock. + + Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, + Roger Pantos and Kiren Sekar for their significant contributions. + + +21. Copyright + + Copyright (C) The Internet Society 2005. + All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + + +Expires 7th December 2005 Cheshire & Krochmal [Page 30] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +22. Normative References + + [ports] IANA list of assigned application protocol names and port + numbers + + [RFC 1033] Lottor, M., "Domain Administrators Operations Guide", + RFC 1033, November 1987. + + [RFC 1034] Mockapetris, P., "Domain Names - Concepts and + Facilities", STD 13, RFC 1034, November 1987. + + [RFC 1035] Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the + location of services (DNS SRV)", RFC 2782, February 2000. + + +23. Informative References + + [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS", + Internet-Draft (work in progress), + draft-cheshire-dnsext-multicastdns-05.txt, June 2005. + + [NBP] Cheshire, S., and M. Krochmal, + "Requirements for a Protocol to Replace AppleTalk NBP", + Internet-Draft (work in progress), + draft-cheshire-dnsext-nbp-04.txt, June 2005. + + [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP + Vendor Extensions", RFC 2132, March 1997. + + [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name + System (DNS UPDATE)", RFC 2136, April 1997. + + [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", RFC 2434, + October 1998. + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 31] + +Internet Draft DNS-Based Service Discovery 7th June 2005 + + + [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS) + Dynamic Update", RFC 3007, November 2000. + + [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration + Protocol (DHCP) Domain Search Option", RFC 3397, November + 2002. + + [ZC] Williams, A., "Requirements for Automatic Configuration + of IP Hosts", Internet-Draft (work in progress), + draft-ietf-zeroconf-reqts-12.txt, September 2002. + + [ZCHP] Guttman, E., "Zeroconf Host Profile Applicability + Statement", Internet-Draft (work in progress), + draft-ietf-zeroconf-host-prof-01.txt, July 2001. + + +24. Authors' Addresses + + Stuart Cheshire + Apple Computer, Inc. + 1 Infinite Loop + Cupertino + California 95014 + USA + + Phone: +1 408 974 3207 + EMail: rfc@stuartcheshire.org + + + Marc Krochmal + Apple Computer, Inc. + 1 Infinite Loop + Cupertino + California 95014 + USA + + Phone: +1 408 974 4368 + EMail: marc@apple.com + + + + + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 32] -- cgit