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-02.txt | 1798 +++++++++++++++ specs/draft-cheshire-dnsext-dns-sd-03.txt | 1856 ++++++++++++++++ specs/draft-cheshire-dnsext-multicastdns-03.txt | 2494 +++++++++++++++++++++ specs/draft-cheshire-dnsext-multicastdns-04.txt | 2494 +++++++++++++++++++++ specs/draft-cheshire-dnsext-multicastdns-05.txt | 2640 +++++++++++++++++++++++ 5 files changed, 11282 insertions(+) create mode 100644 specs/draft-cheshire-dnsext-dns-sd-02.txt create mode 100644 specs/draft-cheshire-dnsext-dns-sd-03.txt create mode 100644 specs/draft-cheshire-dnsext-multicastdns-03.txt create mode 100644 specs/draft-cheshire-dnsext-multicastdns-04.txt create mode 100644 specs/draft-cheshire-dnsext-multicastdns-05.txt (limited to 'specs') diff --git a/specs/draft-cheshire-dnsext-dns-sd-02.txt b/specs/draft-cheshire-dnsext-dns-sd-02.txt new file mode 100644 index 0000000..bebc28d --- /dev/null +++ b/specs/draft-cheshire-dnsext-dns-sd-02.txt @@ -0,0 +1,1798 @@ +Document: draft-cheshire-dnsext-dns-sd-02.txt Stuart Cheshire +Category: Standards Track Apple Computer, Inc. +Expires 14th August 2004 Marc Krochmal + Apple Computer, Inc. + 14th February 2004 + + 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 14th August 2004 Cheshire & Krochmal [Page 1] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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..................12 + 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.....................................18 + 8. Selective Instance Enumeration.................................19 + 9. Flagship Naming................................................10 + 10. Service Type Enumeration.......................................21 + 11. Populating the DNS with Information............................22 + 12. Relationship to Multicast DNS..................................22 + 13. Discovery of Browsing and Registration Domains.................23 + 14. DNS Additional Record Generation...............................24 + 15. Comparison with Alternative Service Discovery Protocols........25 + 16. Real Example...................................................27 + 17. IPv6 Considerations............................................28 + 18. Security Considerations........................................28 + 19. IANA Considerations............................................28 + 20. Acknowledgements...............................................29 + 21. Copyright......................................................29 + 22. Normative References...........................................30 + 23. Informative References.........................................30 + 24. Author's Addresses.............................................31 + + + + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 2] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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 14th August 2004 Cheshire & Krochmal [Page 3] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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 14th August 2004 Cheshire & Krochmal [Page 4] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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 14th August 2004 Cheshire & Krochmal [Page 5] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + 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 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 service pair is the + application protocol name, as recorded in the IANA list of assigned + application protocol names and port numbers [ports]. The second label + of the service pair is either "_tcp" or "_udp", depending on the + transport protocol used by the application. + + 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 14th August 2004 Cheshire & Krochmal [Page 6] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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 preceeding + them with a backslash ("." becomes "\."). Likewise, any backslashes + in the portion should also be escaped by preceeding 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 14th August 2004 Cheshire & Krochmal [Page 7] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + 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 unserstand + 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 behaviours 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 14th August 2004 Cheshire & Krochmal [Page 8] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + 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 nextmost + 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 14th August 2004 Cheshire & Krochmal [Page 9] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + 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 14th August 2004 Cheshire & Krochmal [Page 10] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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. + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 11] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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. + + +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 zero 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. + + +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 + + +Expires 14th August 2004 Cheshire & Krochmal [Page 12] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + 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 + 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. + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 13] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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. + + Unless specified otherwise by a particular DNS-SD profile, 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 SHOULD 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 + 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. + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 14] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + 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 + 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. + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 15] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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, Base64 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 atually 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 14th August 2004 Cheshire & Krochmal [Page 16] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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". + + + + + + + + + + + + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 17] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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. + + 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. + + 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 Procol), 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. + + +Expires 14th August 2004 Cheshire & Krochmal [Page 18] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + 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. + + +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._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. + + + + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 19] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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 + "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, + + +Expires 14th August 2004 Cheshire & Krochmal [Page 20] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + 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 + 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 14th August 2004 Cheshire & Krochmal [Page 21] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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 14th August 2004 Cheshire & Krochmal [Page 22] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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. Four special RR names are reserved for this purpose: + + _browse._dns-sd._udp. + _default._browse._dns-sd._udp. + _register._dns-sd._udp. + _default._register._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. + + 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. + + 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]. Sophisticated clients may perform these 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. + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 23] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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. + + +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. + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 24] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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 analyser 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 + 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. + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 25] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + 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 14th August 2004 Cheshire & Krochmal [Page 26] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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.dns-sd.org + _ftp._tcp.dns-sd.org name=Microsoft\032Developer\032Files.dns-sd.org + _ftp._tcp.dns-sd.org name=Registered\032Users'\032Only.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._ftp._tcp.dns-sd.org + _anon._ftp._tcp.dns-sd.org + name=Apple\032QuickTime\032Files.dns-sd.org + _anon._ftp._tcp.dns-sd.org + name=Microsoft\032Developer\032Files.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.dns-sd.org." + Apple\032QuickTime\032Files.dns-sd.org text = "path=/quicktime" + Apple\032QuickTime\032Files.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 14th August 2004 Cheshire & Krochmal [Page 27] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + +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. automatated 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 + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 28] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + advocates that on or before the date a product ships, developers + should properly register their service names. + + 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. Acknowledgements + + We would like to thank (in alphabetical order) Richard Brown, Josh + Graessley, Erik Guttman, Paul Vixie, and Bill Woodcock, for their + contributions. + + +21. Copyright + + Copyright (C) The Internet Society 2004. + 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 14th August 2004 Cheshire & Krochmal [Page 29] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + 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-04.txt, February 2004. + + [NBP] Cheshire, S., and M. Krochmal, + "Requirements for a Protocol to Replace AppleTalk NBP", + Internet-Draft (work in progress), + draft-cheshire-dnsext-nbp-03.txt, February 2004. + + [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 14th August 2004 Cheshire & Krochmal [Page 30] + +Internet Draft DNS-Based Service Discovery 14th February 2004 + + + [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. Author's 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 14th August 2004 Cheshire & Krochmal [Page 31] 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] diff --git a/specs/draft-cheshire-dnsext-multicastdns-03.txt b/specs/draft-cheshire-dnsext-multicastdns-03.txt new file mode 100644 index 0000000..f9505d9 --- /dev/null +++ b/specs/draft-cheshire-dnsext-multicastdns-03.txt @@ -0,0 +1,2494 @@ +Document: draft-cheshire-dnsext-multicastdns-03.txt Stuart Cheshire +Category: Standards Track Apple Computer, Inc. +Expires 29th July 2004 Marc Krochmal + Apple Computer, Inc. + 29th January 2003 + + Multicast DNS + + + + +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 + + As networked devices become smaller, more portable, and more + ubiquitous, the ability to operate with less configured + infrastructure is increasingly important. In particular, the ability + to look up DNS resource record data types (including, but not limited + to, host names) in the absence of a conventional managed DNS server, + is becoming essential. + + Multicast DNS (mDNS) provides the ability to do DNS-like operations + on the local link in the absense of any conventional unicast DNS + server. In addition, mDNS designates a portion of the DNS namespace + to be free for local use, without the need to pay any annual fee, and + without the need to set up delegations or otherwise configure a + conventional DNS server to answer for those names. + + The primary benefits of mDNS names are that (i) they require little + or no administration or configuration to set them up, (ii) they work + when no infrastructure is present, and (iii) they work during + infrastructure failures. + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 1] + +Internet Draft Multicast DNS 29th January 2003 + + +Table of Contents + + 1. Introduction...................................................3 + 2. Conventions and Terminology Used in this Document..............4 + 3. Multicast DNS Names............................................4 + 4. IP TTL Checks..................................................8 + 5. Reverse Address Mapping........................................8 + 6. Querying.......................................................9 + 7. Duplicate Suppression.........................................13 + 8. Responding....................................................15 + 9. Probing and Announcing on Startup.............................17 + 10. Conflict Resolution...........................................21 + 11. Special Characteristics of Multicast DNS Domains..............23 + 12. Multicast DNS for Service Discovery...........................24 + 13. Resource Record TTL Values and Cache Coherency................25 + 14. Enabling and Disabling Multicast DNS..........................30 + 15. Considerations for Multiple Interfaces........................30 + 16. Multicast DNS and Power Management............................31 + 17. Multicast DNS Character Set...................................32 + 18. Multicast DNS Message Size....................................33 + 19. Multicast DNS Message Format..................................33 + 20. Choice of UDP Port Number.....................................36 + 21. Summary of Differences Between Multicast DNS and Unicast DNS..37 + 22. Benefits of Multicast Responses...............................38 + 23. IPv6 Considerations...........................................39 + 24. Security Considerations.......................................40 + 25. IANA Considerations...........................................41 + 26. Acknowledgements..............................................41 + 27. Copyright.....................................................41 + 28. Normative References..........................................42 + 29. Informative References........................................42 + 30. Author's Addresses............................................43 + + + + + + + + + + + + + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 2] + +Internet Draft Multicast DNS 29th January 2003 + + +1. Introduction + + When reading this document, familiarity with the concepts of Zero + Configuration Networking [ZC] and automatic link-local addressing + [v4LL] [RFC 2462] is helpful. + + This document proposes no change to the structure of DNS messages, + and no new operation codes, response codes, or resource record types. + This document simply discusses what needs to happen if DNS clients + start sending DNS queries to a multicast address, and how a + collection of hosts can cooperate to collectively answer those + queries in a useful manner. + + There has been discussion of how much burden Multicast DNS might + impose on a network. It should be remembered that whenever IPv4 hosts + communicate, they broadcast ARP packets on the network on a regular + basis, and this is not disastrous. The approximate amount of + multicast traffic generated by hosts making conventional use of + Multicast DNS is anticipated to be roughly the same order of + magnitude as the amount of broadcast ARP traffic those hosts already + generate. + + New applications making new use of Multicast DNS capabilities for + unconventional purposes may generate more traffic. If some of those + new applications are "chatty", then work will be needed to help them + become less chatty. When performing any analysis, it is important to + make a distinction between the application behavior and the + underlying protocol behavior. If a chatty application uses UDP, that + doesn't mean that UDP is chatty, or that IP is chatty, or that + Ethernet is chatty. What it means is that the application is chatty. + The same applies to any future applications that may decide to layer + increasing portions of their functionality over Multicast DNS. + + + + + + + + + + + + + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 3] + +Internet Draft Multicast DNS 29th January 2003 + + +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]. + + This document uses the term "host name" in the strict sense to mean a + fully qualified domain name that has an address record. It does not + use the term "host name" in the commonly used but incorrect sense to + mean just the first DNS label of a host's fully qualified domain + name. + + A DNS (or mDNS) packet contains an IP TTL in the IP header, which + is effectively a hop-count limit for the packet, to guard against + routing loops. Each Resource Record also contains a TTL, which is + the number of seconds for which the Resource Record may be cached. + + In any place where there may be potential confusion between these two + types of TTL, the term "IP TTL" is used to refer to the IP header TTL + (hop limit), and the term "RR TTL" is used to refer to the Resource + Record TTL (cache lifetime). + + When this document uses the term "Multicast DNS", it should be taken + to mean: Clients performing DNS-like queries for DNS-like resource + records by sending DNS-like UDP query and response packets over IP + Multicast to UDP port 5353." + + +3. Multicast DNS Names + + This document proposes that the DNS top-level domain ".local." be + designated a special domain with special semantics, namely that any + fully-qualified name ending in ".local." is link-local, and names + within this domain are meaningful only on the link where they + originate. This is analogous to IPv4 addresses in the 169.254/16 + prefix, which are link-local and meaningful only on the link where + they originate. + + Any DNS query for a name ending with ".local." MUST be sent + to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent + FF02::FB). + + It is unimportant whether a name ending with ".local." occurred + because the user explicitly typed in a fully qualified domain name + ending in ".local.", or because the user entered an unqualified + domain name and the host software appended the suffix ".local." + because that suffix appears in the user's search list. The ".local." + suffix could appear in the search list because the user manually + configured it, or because it was received in a DHCP option, or via + any other valid mechanism for configuring the DNS search list. In + + +Expires 29th July 2004 Cheshire & Krochmal [Page 4] + +Internet Draft Multicast DNS 29th January 2003 + + + this respect the ".local." suffix is treated no differently to any + other search domain that might appear in the DNS search list. + + DNS queries for names that do not end with ".local." MAY be sent to + the mDNS multicast address, if no other conventional DNS server is + available. This can allow hosts on the same link to continue + communicating using each other's globally unique DNS names during + network outages which disrupt communication with the greater + Internet. When resolving global names via local multicast, it is even + more important to use DNSSEC or other security mechanisms to ensure + that the response is trustworthy. Resolving global names via local + multicast is a contentious issue, and this document does not discuss + it in detail, instead concentrating on the issue of resolving local + names using DNS packets sent to a multicast address. + + A host which belongs to an organization or individual who has control + over some portion of the DNS namespace can be assigned a globally + unique name within that portion of the DNS namespace, for example, + "cheshire.apple.com." For those of us who have this luxury, this + works very well. However, the majority of home customers do not have + easy access to any portion of the global DNS namespace within which + they have the authority to create names as they wish. This leaves the + majority of home computers effectively anonymous for practical + purposes. + + To remedy this problem, this document allows any computer user to + elect to give their computers link-local Multicast DNS host names of + the form: "single-dns-label.local." For example, my Titanium + PowerBook laptop computer answers to the name "sctibook.local." Any + computer user is granted the authority to name their computer this + way, providing that the chosen host name is not already in use on + that link. Having named their computer this way, the user has the + authority to continue using that name until such time as a name + conflict occurs on the link which is not resolved in the user's + favour. If this happens, the computer (or its human user) SHOULD + cease using the name, and may choose to attempt to allocate a new + unique name for use on that link. Like law suits over global DNS + names, these conflicts are expected to be relatively rare for people + who choose reasonably imaginative names, but it is still important + to have a mechanism in place to handle them when they happen. + + The point made in the previous paragraph is very important and bears + repeating. It is easy for those of us in the IETF community who run + our own name servers at home to forget that the majority of computer + users do not run their own name server and have no easy way to create + their own host names. When these users wish to transfer files between + two laptop computers, they are frequently reduced to typing in + dotted-decimal IP addresses because they simply have no other way for + one host to refer to the other by name. This is a sorry state of + affairs. What is worse, most users don't even bother trying to use + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 5] + +Internet Draft Multicast DNS 29th January 2003 + + + dotted-decimal IP addresses. Most users still move data between + machines by copying it onto a floppy disk or similar removable media. + + In a world of gigabit Ethernet and ubiquitous wireless networking it + is a sad indictment of the networking community that the preferred + communication medium for most computer users is still the floppy + disk. + + Allowing ad-hoc allocation of single-label names in a single flat + ".local." namespace may seem to invite chaos. However, operational + experience with AppleTalk NBP names, which on any given link are also + effectively single-label names in a flat namespace, shows that in + practice name collisions happen extremely rarely and are not a + problem. Groups of computer users from disparate organizations bring + Macintosh laptop computers to events such as IETF Meetings, the Mac + Hack conference, the Apple World Wide Developer Conference, etc., and + complaints at these events about users suffering conflicts and being + forced to rename their machines have never been an issue. + + Enforcing uniqueness of host names (i.e. the names of DNS address + records mapping names to IP addresses) is probably desirable in the + common case, but this document does not mandate that. It is + permissible for a collection of coordinated hosts to agree to + maintain multiple DNS address records with the same name, possibly + for load balancing or fault-tolerance reasons. This document does not + take a position on whether that is sensible. It is important that + both modes of operation are supported. The Multicast DNS protocol + allows hosts to verify and maintain unique names for resource records + where that behaviour is desired, and it also allows hosts to maintain + multiple resource records with a single shared name where that + behaviour is desired. This consideration applies to all resource + records, not just address records (host names). In summary: It is + required that the protocol have the ability to detect and handle name + conflicts, but it is not required that this ability be used for every + record. + + +3.1 Governing Standards Body + + Note that this use of the ".local." suffix falls under IETF + jurisdiction, not ICANN jurisdiction. DNS is an IETF network + protocol, governed by protocol rules defined by the IETF. These IETF + protocol rules dictate character set, maximum name length, packet + format, etc. ICANN determines additional rules that apply when the + IETF's DNS protocol is used on the public Internet. In contrast, + private uses of the DNS protocol on isolated private networks are not + governed by ICANN. Since this proposed change is a change to the core + DNS protocol rules, it affects everyone, not just those machines + using the ICANN-governed Internet. Hence this change falls into the + category of an IETF protocol rule, not an ICANN usage rule. + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 6] + +Internet Draft Multicast DNS 29th January 2003 + + +3.2 Private DNS Namespaces + + Note also that the special treatment of names ending in ".local." has + been implemented in Macintosh computers since the days of Mac OS 9, + and continues today in Mac OS X. There are also implementations for + Linux and other platforms [dotlocal]. Operators setting up private + internal networks ("intranets") are advised that their lives may be + easier if they avoid using the suffix ".local." in names in their + private internal DNS server. Alternative possibilities include: + + .intranet + .internal + .private + .corp + .home + + Another alternative naming scheme, advocated by Professor D. J. + Bernstein, is to use a numerical suffix, such as ".6." [djbdl]. + + +3.3 Maximum Multicast DNS Name Length + + RFC 1034 says: + + "the total number of octets that represent a domain name (i.e., + the sum of all label octets and label lengths) is limited to 255." + + This text implies that the final root label at the end of every name + is included in this count (a name can't be represented without it), + but the text does not explicitly state that. Implementations of + Multicast DNS MUST include the label length byte of the final root + label at the end of every name when enforcing the rule that no name + may be longer than 255 bytes. For example, the length of the name + "apple.com." is considered to be 11, which is the number of bytes it + takes to represent that name in a packet without using name + compression: + + ------------------------------------------------------ + | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 | + ------------------------------------------------------ + + + + + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 7] + +Internet Draft Multicast DNS 29th January 2003 + + +4. IP TTL Checks + + All Multicast DNS responses (including responses sent via unicast) + MUST be sent with IP TTL set to 255. + + A host sending Multicast DNS queries to a link-local destination + address (including the 224.0.0.251 link-local multicast address) MUST + verify that the IP TTL in response packets is 255, and silently + discard any response packets where the IP TTL is not 255. Without + this check, it could be possible for remote rogue hosts to send + spoof answer packets (perhaps unicast to the victim host) which the + receiving machine could misinterpret as having originated on the + local link. + + The authors have heard complaints that some older network stack + implementations do not implement the IP_RECVTTL socket option + (or equivalent API) for obtaining the IP TTL of received packets. + This is unfortunate, and these old network stacks would benefit + from adding this API support so that they may benefit from this + enhanced protection against spoof packets arriving from off-link. + + Note that Multicast DNS Responders SHOULD NOT discard queries with + TTLs other than 255. There may be valid future applications of + Multicast DNS where hosts issue unicast queries directed at Multicast + DNS Responders more than one hop away, if Multicast DNS Responders + were to discard queries where the TTL is not 255, they would not + answer these queries. + + +5. Reverse Address Mapping + + Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also + defined to be link-local. + + Any DNS query for a name ending with "254.169.in-addr.arpa." MUST + be sent to the mDNS multicast address 224.0.0.251. Since names under + this domain correspond to IPv4 link-local addresses, it is logical + that the local link is the best place to find information pertaining + to those names. As an optimization, these queries MAY be first + unicast directly to the address in question, but if this query is not + answered, the query MUST also be sent via multicast, to accommodate + the case where the machine in question is not answering for itself + (for example, because it is currently sleeping). + + Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa." + MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB, + with or without an optional initial query unicast directly to the + address in question. + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 8] + +Internet Draft Multicast DNS 29th January 2003 + + +6. Querying + + There are three kinds of Multicast DNS Queries, one-shot queries of + the kind made by today's conventional DNS clients, one-shot queries + accumulating multiple responses made by multicast-aware DNS clients, + and continuous ongoing Multicast DNS Queries used by IP network + browser software. + + A Multicast DNS Responder that is offering records that are intended + to be unique on the local link MUST also implement a Multicast DNS + Querier so that it can first verify the uniqueness of those records + before it begins answering queries for them. + + +6.1 One-Shot Queries + + An unsophisticated DNS client may simply send its DNS queries + blindly to the 224.0.0.251 multicast address, without necessarily + even being aware what a multicast address is. + + Such an unsophisticated DNS client may not get ideal behaviour. Such + a client may simply take the first response it receives and fail to + wait to see if there are more, but in many instances this may not be + a serious problem. If a user types "http://stu.local." into their Web + browser and gets to see the page they were hoping for, then the + protocol has met the user's needs in this case. + + +6.2 One-Shot Queries, Accumulating Multiple Responses + + A more sophisticated DNS client should understand that Multicast DNS + is not exactly the same as unicast DNS, and should modify its + behaviour in some simple ways. + + As described above, there are some cases, such as looking up the + address associated with a unique host name, where a single response + is sufficient, and moreover may be all that is expected. However, + there are other DNS queries where more than one response is + possible, and for these queries a more sophisticated Multicast DNS + client should include the ability to wait for an appropriate period + of time to collect multiple responses. + + A naive DNS client retransmits its query only so long as it has + received no response. A more sophisticated Multicast DNS client is + aware that having received one response is not necessarily an + indication that it might not receive others, and has the ability to + retransmit its query an appropriate number of times at appropriate + intervals until it is satisfied with the collection of responses it + has gathered. + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 9] + +Internet Draft Multicast DNS 29th January 2003 + + + A more sophisticated Multicast DNS client that is retransmitting + a query for which it has already received some responses, MUST + implement Known Answer Suppression, as described below in Section + 7.1. This indicates to responders who have already replied that their + responses have been received, and they don't need to send them again + in response to this repeated query. In addition, the interval between + the first two queries MUST be at least one second, and the + intervals between subsequent queries MUST double. + + +6.3 Continuous Querying + + In One-Shot Queries, with either a single or multiple responses, + the underlying assumption is that the transaction begins when the + application issues a query, and ends when all the desired responses + have been received. There is another type of operation which is more + akin to continuous monitoring. + + Macintosh users are accustomed to opening the "Chooser" window, + selecting a desired printer, and then closing the Chooser window. + However, when the desired printer does not appear in the list, the + user will typically leave the "Chooser" window open while they go and + check to verify that the printer is plugged in, powered on, connected + to the Ethernet, etc. While the user jiggles the wires, hits the + Ethernet hub, and so forth, they keep an eye on the Chooser window, + and when the printer name appears, they know they have fixed whatever + the problem was. This can be a useful and intuitive troubleshooting + technique, but a user who goes home for the weekend leaving the + Chooser window open places a non-trivial burden on the network. + + With continuous querying, multiple queries are sent over a long + period of time, until the user terminates the operation. It is + important that an IP network browser window displaying live + information from the network using Multicast DNS, if left running for + an extended period of time, should generate significantly less + multicast traffic on the network than the old AppleTalk Chooser. + Therefore, the interval between the first two queries MUST be at + least one second, the intervals between subsequent queries MUST + double, and the querier MUST implement Known Answer Suppression, as + described below in Section 7.1. + + When a Multicast DNS Querier receives an answer, the answer contains + a TTL value that indicates for how many seconds this answer is valid. + After this interval has passed, the answer will no longer be valid + and should be deleted from the cache. Before this time is reached, a + Multicast DNS Querier with an ongoing interest in that record SHOULD + re-issue its query to determine whether the record is still valid, + and if so update its expiry time. + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 10] + +Internet Draft Multicast DNS 29th January 2003 + + + To perform this cache maintenance, a Multicast DNS Querier should + plan to issue a query at 80% of the record lifetime, and then if no + answer is received, at 85%, 90% and 95%. If an answer is received, + then the remaining TTL is reset to the value given in the answer, and + this process repeats for as long as the Multicast DNS Querier has an + ongoing interest in the record. If after four queries no answer is + received, the record is deleted when it reaches 100% of its lifetime. + + To avoid the case where multiple Multicast DNS Queriers on a network + all issue their queries simultaneously, a random variation of 2% of + the record TTL should be added, so that queries are scheduled to be + performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL. + + +6.4 Multiple Questions per Query + + Multicast DNS allows a querier to place multiple questions in the + question section of a single Multicast DNS query packet. + + The semantics of a Multicast DNS query packet containing multiple + questions is identical to a series of individual DNS query packets + containing one question each. Combining multiple questions into a + single packet is purely an efficiency optimization, and has no other + semantic significance. + + A useful technique for adaptively combining multiple questions into a + single query is to use a Nagle-style algorithm: When a client issues + its first question, a Query packet is immediately built and sent, + without delay. If the client then continues issuing a rapid series of + questions they are held until either the first query receives at + least one answer, or 100ms has passed, or there are enough questions + to fill the question section of a Multicast DNS query packet. At this + time, all the held questions are placed into a Multicast DNS query + packet and sent. + + +6.5 Questions Requesting Unicast Responses + + Sending Multicast DNS responses via multicast has the benefit that + all the other hosts on the network get to see those responses, and + can keep their caches up to date, and detect conflicting responses. + + However, there are situations where all the other hosts on the + network don't need to see every response. One example is a laptop + computer waking from sleep. At that instant it is a brand new + participant on a new network. Its Multicast DNS cache is empty, and + it has no knowledge of its surroundings. It may have a significant + number of queries that it wants answered right away to discover + information about its new surroundings and present that information + to the user. As a new participant on the network, it has no idea + whether the exact same questions may have been asked and answered + + +Expires 29th July 2004 Cheshire & Krochmal [Page 11] + +Internet Draft Multicast DNS 29th January 2003 + + + just seconds ago. In this case, trigging a large sudden flood of + multicast responses may impose an unreasonable burden on the network. + To avoid this, the Multicast DNS Querier SHOULD set the top bit in + the class field of its DNS question(s), to indicate that it is + willing to accept unicast responses instead of the usual multicast + responses. These questions requesting unicast responses are referred + to as "QU" questions, to distinguish them from the more usual + questions requesting multicast responses ("QM" questions). + + When retransmitting a question more than once, the 'unicast response' + bit SHOULD be set only for the first question of the series. After + the first question has received its responses, the querier should + have a large known-answer list (see "Known Answer Suppression" below) + so that subsequent queries should elicit few, if any, further + responses. Reverting to multicast responses as soon as possible is + important because of the benefits that multicast responses provide + (see "Benefits of Multicast Responses" below). + + When receiving a question with the 'unicast response' bit set, a + responder SHOULD usually respond with a unicast packet directed back + to the querier. If the responder has not multicast that record + recently (within one quarter of its TTL), then the responder SHOULD + instead multicast the response so as to keep all the peer caches up + to date, and to permit passive conflict detection. + + +6.6 Suppressing Initial Query + + If a query is issued for which there already exist one or more + records in the local cache, and those record(s) were received with + the cache flush bit set, indicating that they form a unique RRSet, + then the host SHOULD suppress its initial "QU" query, and proceed to + issue a "QM" query. To avoid the situation where a group of hosts + are synchronized by some external event and all perform the same + query simultaneously, a host suppressing its initial "QU" query + SHOULD impose a random delay from 500-1000ms before transmitting its + first "QM" query for this question. This means that when the first + host (selected randomly by this algorithm) transmits its "QM" query, + all the other hosts that were about to transmit the same query can + suppress their superfluous query, as described in "Duplicate + Question Suppression" below. + + + + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 12] + +Internet Draft Multicast DNS 29th January 2003 + + +7. Duplicate Suppression + + A variety of techniques are used to reduce the amount of redundant + traffic on the network. + + +7.1 Known Answer Suppression + + When a Multicast DNS Querier sends a query to which it already knows + some answers, it populates the Answer Section of the DNS message with + those answers. + + A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if + the answer it would give is already included in the Answer Section + with an RR TTL at least half the correct value. If the RR TTL of the + answer as given in the Answer Section is less than half of the true + RR TTL as known by the Multicast DNS Responder, the responder MUST + send an answer so as to update the Querier's cache before the record + becomes in danger of expiration. + + Because a Multicast DNS Responder will respond if the remaining TTL + given in the known answer list is less than half the true TTL, it is + superfluous for the Querier to include such records in the known + answer list. Therefore a Multicast DNS Querier SHOULD NOT include + records in the known answer list whose remaining TTL is less than + half their original TTL. Doing so would simply consume space in the + packet without achieving the goal of suppressing responses, and would + therefore be a pointless waste of network bandwidth. + + A Multicast DNS Querier MUST NOT cache resource records observed in + the Known Answer Section of other Multicast DNS Queries. The Answer + Section of Multicast DNS Queries is not authoritative. By placing + information in the Answer Section of a Multicast DNS Query the + querier is stating that it *believes* the information to be true. + It is not asserting that the information *is* true. Some of those + records may have come from other hosts that are no longer on the + network. Propagating that stale information to other Multicast DNS + Queriers on the network would not be helpful. + + +7.2 Multi-Packet Known Answer Suppression + + Sometimes a Multicast DNS Querier will already have too many answers + to fit in the Known Answer section of its query packets. In this + case, it should issue a Multicast DNS Query containing a question and + as many Known Answer records as will fit. It should then set the TC + (Truncated) bit in the header before sending the Query. It should + then immediately follow the packet with another query containing no + questions, and as many more Known Answer records as will fit. If + there are still too many records remaining to fit in the packet, it + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 13] + +Internet Draft Multicast DNS 29th January 2003 + + + again sets the TC bit and continues until all the Known Answer + records have been sent. + + A Multicast DNS Responder seeing a Multicast DNS Query with the TC + bit set defers its response for a time period randomly selected in + the interval 20-120ms. This gives the Multicast DNS Querier time to + send additional Known Answer packets before the Responder responds. + If the Responder sees any of its answers listed in the Known Answer + lists of subsequent packets from the querying host, it should delete + that answer from the list of answers it is planning to give, provided + that no other host on the network is also waiting to receive the same + answer record. + + +7.3 Duplicate Question Suppression + + If a host is planning to send a query, and it sees another host on + the network send a query containing the same question, and the Known + Answer section of that query does not contain any records which this + host would not also put in its own Known Answer section, then this + host should treat its own query as having been sent. When multiple + clients on the network are querying for the same resource records, + there is no need for them to all be repeatedly asking the same + question. + + +7.4 Duplicate Answer Suppression + + If a host is planning to send an answer, and it sees another host on + the network send a response packet containing the same answer record, + and the TTL in that record is not less than the TTL this host would + have given, then this host should treat its own answer as having been + sent. When multiple responders on the network have the same data, + there is no need for all of them to respond. + + This feature is particularly useful when multiple Sleep Proxy Servers + are deployed (see Section 16. "Multicast DNS and Power Management"). + In the future it is possible that every general-purpose OS (Mac, + Windows, Linux, etc.) will implement Sleep Proxy Service as a matter + of course. In this case there could be a large number of Sleep Proxy + Servers on any given network, which is good for reliability and + fault-tolerance, but would be bad for the network if every Sleep + Proxy Server were to answer every query. + + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 14] + +Internet Draft Multicast DNS 29th January 2003 + + +8. Responding + + A Multicast DNS Responder MUST only respond when it has a positive + non-null response to send. Error responses must never be sent. The + non-existence of any name in a Multicast DNS Domain is ascertained by + the failure of any machine to respond to the Multicast DNS query, not + by NXDOMAIN errors. + + Multicast DNS Responses MUST NOT contain any questions in the + Question Section. Any questions in the Question Section of a received + Multicast DNS Response MUST be silently ignored. Multicast DNS + Queriers receiving Multicast DNS Responses do not care what question + elicited the response; they care only that the information in the + response is true and accurate. + + A Multicast DNS Responder on Ethernet [IEEE802] and similar shared + multiple access networks SHOULD delay its responses by a random + amount of time selected with uniform random distribution in the range + 20-120ms. If multiple Multicast DNS Responders were all to respond + immediately to a particular query, a collision would be virtually + guaranteed. By imposing a small random delay, the number of + collisions is dramatically reduced. 120ms is a short enough time that + it is almost imperceptible to a human user, but long enough to + significantly reduce the risk of Ethernet collisions. On a full-sized + Ethernet using the maximum cable lengths allowed and the maximum + number of repeaters allowed, an Ethernet frame is vulnerable to + collisions during the transmission of its first 256 bits. On 10Mb/s + Ethernet, this equates to a vulnerable time window of 25.6us. + + In the case where a Multicast DNS Responder has good reason to + believe that it will be the only responder on the link with a + positive non-null response, it SHOULD NOT impose the random delay + before responding, and SHOULD normally generate its response within + 10ms. To do this safely, it MUST have previously verified that the + requested name, type and class in the DNS query are unique on this + link. Responding immediately without delay is appropriate for things + like looking up the address record for a particular host name, when + the host name has been previously verified unique. Responding + immediately without delay is *not* appropriate for things like + looking up PTR records used for DNS Service Discovery [DNS-SD], where + a large number of responses may be anticipated. + + Except when a unicast reply has been explicitly requested via the + "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port + 5353 (the well-known port assigned to mDNS) on the 224.0.0.251 + multicast address (or its IPv6 equivalent FF02::FB). Operating in a + Zeroconf environment requires constant vigilance. Just because a name + has been previously verified unique does not mean it will continue to + be so indefinitely. By allowing all Multicast DNS Responders to + constantly monitor their peers' responses, conflicts arising out of + network topology changes can be promptly detected and resolved. + + +Expires 29th July 2004 Cheshire & Krochmal [Page 15] + +Internet Draft Multicast DNS 29th January 2003 + + + Sending all responses by multicast also facilitates opportunistic + caching by other hosts on the network. + + To protect the network against excessive packet flooding due to + software bugs or malicious attack, a Multicast DNS Responder MUST NOT + multicast a given record on a given interface if it has previously + multicast that record on that interface within the last second. A + legitimate client on the network should have seen the previous + transmission and cached it. A client that did not receive and cache + the previous transmission will retry its request and receive a + subsequent response. Under no circumstances is there any legitimate + reason for a Multicast DNS Responder to multicast a given record more + than once per second on any given interface. + + +8.1 Legacy Unicast Responses + + If the source UDP port in a received Multicast DNS Query is not port + 5353, this indicates that the client originating the query is a + simple client that does not fully implement all of Multicast DNS. In + this case, the Multicast DNS Responder MUST send a UDP response + directly back to the client, via unicast, to the query packet's + source IP address and port. This unicast response MUST be a + conventional unicast response as would be generated by a conventional + unicast DNS server; for example, it must repeat the query ID and the + question given in the query packet. + + The resource record TTL given in a unicast response SHOULD NOT be + greater than ten seconds, even if the true TTL of the Multicast DNS + resource record is higher. This is because Multicast DNS Responders + that fully participate in the protocol use the cache coherency + mechanisms described in Section 13 to update and invalidate stale + data. Were unicast responses sent to legacy clients to use the same + high TTLs, these legacy clients, which do not implement these cache + coherency mechanisms, could retain stale cached resource record data + long after it is no longer valid. + + Having sent this unicast response, if the Responder has not sent this + record in any multicast response recently, it SHOULD schedule the + record to be sent via multicast as well, to facilitate passive + conflict detection. "Recently" in this context means "if the time + since the record was last sent via multicast is less than one quarter + of the record's TTL". + + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 16] + +Internet Draft Multicast DNS 29th January 2003 + + +8.2 Multi-Question Queries + + Multicast DNS Responders MUST correctly handle DNS query packets + containing more than one question, by answering any or all of the + questions to which they have answers. Any answers generated + in response to query packets containing more than one question + MUST be randomly delayed in the range 20-120ms, as described above. + + +8.3 Response Aggregation + + Having delayed one or more multicast responses by 20-120ms as + described above in Section 8 "Responding", a Multicast DNS Responder + SHOULD, for the sake of network efficiency, aggregate as many of its + pending responses as possible into a single Multicast DNS response + packet. + + +9. Probing and Announcing on Startup + + Typically a Multicast DNS Responder should have, at the very least, + address records for all of its active interfaces. Creating and + advertising an HINFO record on each interface as well can be useful + to network administrators. + + Whenever a Multicast DNS Responder starts up, wakes up from sleep, + receives an indication of an Ethernet "Link Change" event, or has any + other reason to believe that its network connectivity may have + changed in some relevant way, it MUST perform the two startup steps + below. + + +9.1 Probing + + The first startup step is that for all those resource records that a + Multicast DNS Responder desires to be unique on the local link, it + MUST send a Multicast DNS Query asking for those resource records, to + see if any of them are already in use. The primary example of this is + its address record which maps its unique host name to its unique IP + address. All Probe Queries SHOULD be done using the desired resource + record name and query type T_ANY (255), to elicit answers for all + types of records with that name. This allows a single question to be + used in place of several questions, which is more efficient on the + network. It also allows a host to verify exclusive ownership of a + name, which is desirable in most cases. It would be confusing, for + example, if one host owned the "A" record for "myhost.local.", but a + different host owned the HINFO record for that name. + + The ability to place more than one question in a Multicast DNS Query + is useful here, because it can allow a host to use a single packet + for all of its resource records instead of needing a separate packet + + +Expires 29th July 2004 Cheshire & Krochmal [Page 17] + +Internet Draft Multicast DNS 29th January 2003 + + + for each. For example, a host can simultaneously probe for uniqueness + of its "A" record and all its SRV records [DNS-SD] in the same query + packet. + + When ready to send its mDNS probe packet(s) the host should first + wait for a short random delay time, uniformly distributed in the + range 0-250ms. This random delay is to guard against the case where a + group of devices are powered on simultaneously, or a group of devices + are connected to an Ethernet hub which is then powered on, or some + other external event happens that might cause a group of hosts to all + send synchronized probes. + + 250ms after the first query the host should send a second, then + 250ms after that a third. If, by 250ms after the third probe, no + conflicting Multicast DNS responses have been received, the host may + move to the next step, announcing. + + If any conflicting Multicast DNS responses are received, then the + probing host MUST defer to the existing host, and must choose new + names for some or all of its resource records as appropriate, to + avoid conflict with pre-existing hosts on the network. In the case + of a host probing using query type T_ANY as recommended above, any + answer containing a record with that name, of any type, MUST be + considered a conflicting response and handled accordingly. + + If ten failures occur within any ten-second period, then the host + MUST wait at least five seconds before each successive additional + probe attempt. This is to help ensure that in the event of software + bugs or other unanticipated problems, errant hosts do not flood the + network with a continuous stream of multicast traffic. For very + simple devices, a valid way to comply with this requirement is to + always wait five seconds after any failed probe attempt. + + +9.2 Simultaneous Probe Tie-Breaking + + The astute reader will observe that there is a race condition + inherent in the previous description. If two hosts are probing for + the same name simultaneously, neither will receive any response to + the probe, and the hosts could incorrectly conclude that they may + both proceed to use the name. To break this symmetry, each host + populates the Authority Section of its queries with records giving + the rdata that it would be proposing to use, should its probing be + successful. The Authority Section is being used here in a way + analogous to the Update section of a DNS Update packet [RFC 2136]. + + When a host that is probing for a record sees another host issue a + query for the same record, it consults the Authority Section of that + query. If it finds any resource record there which answers the query, + then it compares the data of that resource record with its own + tentative data. The lexicographically later data wins. This means + + +Expires 29th July 2004 Cheshire & Krochmal [Page 18] + +Internet Draft Multicast DNS 29th January 2003 + + + that if the host finds that its own data is lexicographically later, + it simply ignores the other host's probe. If the host finds that its + own data is lexicographically earlier, then it treats this exactly + as if it had received a positive answer to its query, and concludes + that it may not use the desired name. + + The determination of 'lexicographically later' is performed by first + comparing the record class, then the record type, then raw comparison + of the binary content of the rdata without regard for meaning or + structure. If the record classes differ, then the numerically greater + class is considered 'lexicographically later'. Otherwise, if the + record types differ, then the numerically greater type is considered + 'lexicographically later'. If the type and class both match then the + rdata is compared. + + In the case of resource records containing rdata that is subject to + name compression, the names must be uncompressed before comparison. + (The details of how a particular name is compressed is an artifact of + how and where the record is written into the DNS message; it is not + an intrinsic property of the resource record itself.) + + The bytes of the raw uncompressed rdata are compared in turn, + interpreting the bytes as eight-bit UNSIGNED values, until a byte + is found whose value is greater than that of its counterpart (in + which case the rdata whose byte has the greater value is deemed + lexicographically later) or one of the resource records runs out + of rdata (in which case the resource record which still has + remaining data first is deemed lexicographically later). + + The following is an example of a conflict: + + sctibook.local. A 196.254.100.200 + sctibook.local. A 196.254.200.100 + + In this case 196.254.200.100 is lexicographically later, so it is + deemed the winner. + + Note that it is vital that the bytes are interpreted as UNSIGNED + values, or the wrong outcome may result. In the example above, if + the byte with value 200 had been incorrectly interpreted as a + signed value then it would be interpreted as value -56, and the + wrong address record would be deemed the winner. + + +9.3 Announcing + + The second startup step is that the Multicast DNS Responder MUST send + a gratuitous Multicast DNS Response containing, in the Answer + Section, all of its resource records. If there are too many resource + records to fit in a single packet, multiple packets should be used. + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 19] + +Internet Draft Multicast DNS 29th January 2003 + + + In the case of shared records (e.g. the PTR records used by DNS + Service Discovery [DNS-SD]), the records are simply placed as-is + into the answer section of the DNS Response. + + In the case of records that have been verified to be unique in the + previous step, they are placed into the answer section of the DNS + Response with the most significant bit of the rrclass set to one. The + most significant bit of the rrclass is the mDNS "cache flush" bit and + is discussed in more detail below in Section 13.3 "Announcements to + Flush Outdated Cache Entries". + + The Multicast DNS Responder MUST send at least two gratuitous + responses, one second apart. A Responder MAY send up to ten + gratuitous Responses, providing that the interval between gratuitous + responses doubles with every response sent. + + A Multicast DNS Responder SHOULD NOT continue sending gratuitous + Responses for longer than the TTL of the record. The purpose of + announcing new records via gratuitous Responses is to ensure that + peer caches are up to date. After a time interval equal to the TTL of + the record has passed, it is very likely that old stale copies of + that record in peer caches will have expired naturally, so subsequent + announcements serve little purpose. + + Whenever a Multicast DNS Responder receives any Multicast DNS + response (gratuitous or otherwise) containing a conflicting resource + record, the conflict MUST be resolved as described below in "Conflict + Resolution". + + A Multicast DNS Responder MUST NOT send announcements in the absence + of information that its network connectivity may have changed in some + relevant way. In particular, a Multicast DNS Responder MUST NOT send + regular periodic announcements as a matter of course. + + +9.4 Updating + + At any time, if the rdata of any of a host's Multicast DNS records + changes, the host MUST repeat the Announcing step described above to + update neighbouring caches. For example, if any of a host's IP + addresses change, it must re-announce those address records. + + A host may update the contents of any of its records at any time, + though a host SHOULD NOT update records more frequently than ten + times per minute. Frequent rapid updates impose a burden on the + network. If a host has information to disseminate which changes more + frequently than ten times per minute, then Multicast DNS may not be + the appropriate protocol to disseminate that information. + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 20] + +Internet Draft Multicast DNS 29th January 2003 + + +10. Conflict Resolution + + A conflict occurs when two resource records with the same name, type + and class have inconsistent rdata. What may be considered + inconsistent is context sensitive, except that resource records with + identical rdata are never considered inconsistent, even if they + originate from different hosts. A common example of a resource record + type that is intended to be unique, not shared between hosts, is the + address record that maps a host's name to its IP address. Should a + host witness another host announce an address record with the same + name but a different IP address, then that is considered + inconsistent, and that address record is considered to be in + conflict. + + Whenever a Multicast DNS Responder receives any Multicast DNS + response (gratuitous or otherwise) containing a conflicting resource + record, the Multicast DNS Responder MUST immediately reset that + record to probing state, and go through the startup steps described + above in Section 9. "Probing and Announcing on Startup". The + protocol used in the Probing phase will determine a winner and a + loser, and the loser must cease using the name, and reconfigure. + + It is very important that any host that observes an apparent conflict + MUST take action. In the case of two hosts using the same host name, + where one has been configured to require a unique host name and the + other has not, the one that has not been configured to require a + unique host name will not perceive any conflict, and will not take + any action. By reverting to Probing state, the host that desires a + unique host name will go through the necessary steps to ensure that a + unique host is obtained. + + + + + + + + + + + + + + + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 21] + +Internet Draft Multicast DNS 29th January 2003 + + + The recommended course of action after probing and failing is as + follows: + + o Programmatically change the resource record name in an attempt to + find a new name that is unique. This could be done by adding some + further identifying information (e.g. the model name of the + hardware) if it is not already present in the name, appending the + digit "2" to the name, or incrementing a number at the end of the + name if one is already present. + + o Probe again, and repeat until a unique name is found. + + o Record this newly chosen name in persistent storage so that the + device will use the same name the next time it is power-cycled. + + o Display a message to the user or operator informing them of the + name change. For example: + + The name "Bob's Music" is in use by another iTunes music + server on the network. Your music has been renamed to + "Bob's Music (G4 Cube)". If you want to change this name, + use [describe appropriate menu item or preference dialog]. + + How the user or operator is informed depends on context. A desktop + computer with a screen might put up a dialog box. A headless server + in the closet may write a message to a log file, or use whatever + mechanism (email, SNMP trap, etc.) it uses to inform the + administrator of other error conditions. On the other hand a headless + server in the closet may not inform the user at all -- if the user + cares, they will notice the name has changed, and connect to the + server in the usual way (e.g. via Web Browser) to configure a new + name. + + The examples in this section focus on address records (i.e. host + names), but the same considerations apply to all resource records + where uniqueness (or maintenance of some other defined constraint) is + desired. + + + + + + + + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 22] + +Internet Draft Multicast DNS 29th January 2003 + + +11. Special Characteristics of Multicast DNS Domains + + Unlike conventional DNS names, names that end in ".local.", + "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local + significance. Conventional DNS seeks to provide a single unified + namespace, where a given DNS query yields the same answer no matter + where on the planet it is performed or to which recursive DNS server + the query is sent. (However, split views, firewalls, intranets and + the like have somewhat interfered with this goal of DNS representing + a single universal truth.) In contrast, each IP link has its own + private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa." + namespaces, and the answer to any query for a name within those + domains depends on where that query is asked. + + Multicast DNS Domains are not delegated from their parent domain via + use of NS records. There are no NS records anywhere in Multicast DNS + Domains. Instead, all Multicast DNS Domains are delegated to the IP + addresses 224.0.0.251 and FF02::FB by virtue of the individual + organizations producing DNS client software deciding how to handle + those names. It would be extremely valuable for the industry if this + special handling were ratified and recorded by IANA, since otherwise + the special handling provided by each vendor is likely to be + inconsistent. + + The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The + IPv6 name server for a Multicast DNS Domain is FF02::FB. These are + multicast addresses; therefore they identify not a single host but a + collection of hosts, working in cooperation to maintain some + reasonable facsimile of a competently managed DNS zone. Conceptually + a Multicast DNS Domain is a single DNS zone, however its server is + implemented as a distributed process running on a cluster of loosely + cooperating CPUs rather than as a single process running on a single + CPU. + + No delegation is performed within Multicast DNS Domains. Because the + cluster of loosely coordinated CPUs is cooperating to administer a + single zone, delegation is neither necessary nor desirable. Just + because a particular host on the network may answer queries for a + particular record type with the name "example.local." does not imply + anything about whether that host will answer for the name + "child.example.local.", or indeed for other record types with the + name "example.local." + + Multicast DNS Zones have no SOA record. A conventional DNS zone's + SOA record contains information such as the email address of the zone + administrator and the monotonically increasing serial number of the + last zone modification. There is no single human administrator for + any given Multicast DNS Zone, so there is no email address. Because + the hosts managing any given Multicast DNS Zone are only loosely + coordinated, there is no readily available monotonically increasing + serial number to determine whether or not the zone contents have + + +Expires 29th July 2004 Cheshire & Krochmal [Page 23] + +Internet Draft Multicast DNS 29th January 2003 + + + changed. A host holding part of the shared zone could crash or be + disconnected from the network at any time without informing the other + hosts. There is no reliable way to provide a zone serial number that + would, whenever such a crash or disconnection occurred, immediately + change to indicate that the contents of the shared zone had changed. + + Zone transfers are not possible for any Multicast DNS Zone. + + +12. Multicast DNS for Service Discovery + + This document does not describe using Multicast DNS for network + browsing or service discovery. However, the mechanisms this document + describes are compatible with (and support) the browsing and service + discovery mechanisms proposed in "DNS-Based Service Discovery" + [DNS-SD]. + + This document places few limitations on what DNS record types may be + looked up using local multicast. One particular kind of Multicast DNS + query that might be useful is a query for the SRV record named + "_domain._udp.local.", yielding the port number and IP address of a + conventional DNS server willing to perform general recursive DNS + lookups. This could solve a particular problem facing the IPv6 + community, which is that IPv6 is able to self-configure almost all of + the information it needs to operate [RFC 2462], except for the + address of the DNS server. Bringing in all of the mechanisms of DHCP + just for that one little additional piece of information is not an + attractive solution. Using DNS-format messages and DNS-format + resource records to find the address of the DNS server has an elegant + self-sufficiency about it. Any host that needs to know the address of + the DNS server must already have code to generate and parse DNS + packets, so using that same code and those same packets to find the + DNS server in the first place is a simple self-reliant solution that + avoids taking external dependencies on other protocols. + + +13. Resource Record TTL Values and Cache Coherency + + The recommended TTL value for Multicast DNS resource records is + 120 minutes. + + A client with an active outstanding query will issue a query packet + when one or more of the resource record(s) in its cache is (are) 80% + of the way to expiry. If the TTL on those records is 120 minutes, + this ongoing cache maintenance process yields a steady-state query + rate of one query every 96 minutes. + + Any distributed cache needs a cache coherency protocol. If Multicast + DNS resource records follow the recommendation and have a TTL of 120 + minutes, that means that stale data could persist in the system for + up to two hours. Making the default TTL significantly lower would + + +Expires 29th July 2004 Cheshire & Krochmal [Page 24] + +Internet Draft Multicast DNS 29th January 2003 + + + reduce the lifetime of stale data, but would produce too much extra + traffic on the network. Various techniques are available to minimize + the impact of such stale data. + + +13.1 Cooperating Multicast DNS Responders + + If a Multicast DNS Responder ("A") observes some other Multicast DNS + Responder ("B") send a Multicast DNS Response packet containing a + resource record with the same name type and class as one of A's + resource records, but different rdata, then: + + o If A's resource record is intended to be a shared resource record, + then this is no conflict, and no action is required. + + o If A's resource record is intended to be a unique resource record + then this is a conflict and MUST be handled as described in Section + 10 "Conflict Resolution". + + If a Multicast DNS Responder ("A") observes some other Multicast DNS + Responder ("B") send a Multicast DNS Response packet containing a + resource record with the same name type and class as one of A's + resource records, and identical rdata, then: + + o If the TTL of B's resource record given in the packet is at least + half the true TTL from A's point of view, then no action is + required. + + o If the TTL of B's resource record given in the packet is less than + half the true TTL from A's point of view, then A MUST mark its + record to be announced via multicast. Clients receiving the record + from B would use the TTL given by B, and hence may delete the + record sooner than A expects. By sending its own multicast response + correcting the TTL, A ensures that the record will be retained for + the desired time. + + These rules allow multiple Multicast DNS Responders to offer the same + data on the network (perhaps for fault tolerance reasons) without + conflicting with each other. + + +13.2 Goodbye Packets + + In the case where a host knows that certain resource record data is + about to become invalid (for example when the host is undergoing a + clean shutdown) the host SHOULD send a gratuitous announcement mDNS + response packet, giving the same resource record name, type, class + and rdata, but an RR TTL of zero. This has the effect of updating the + TTL stored in neighbouring hosts' cache entries to zero, causing that + cache entry to be promptly deleted. + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 25] + +Internet Draft Multicast DNS 29th January 2003 + + + Clients receiving a Multicast DNS Response with a TTL of zero SHOULD + NOT immediately delete the record from the cache, but instead record + a TTL of 1 and then delete the record one second later. In the case + of multiple Multicast DNS Responders on the network described in + Section 13.1 above, if one of the Responders shuts down and + incorrectly sends goodbye packets for its records, it gives the other + cooperating Responders one second to send out their own response to + "rescue" the records before they expire and are deleted. + + Generally speaking, it is more important to send goodbye packets for + shared records than unique records. A given shared record name (such + as a PTR record used for DNS Service Discovery [DNS-SD]) by its + nature often has many representatives from many different hosts, and + tends to be the subject of long-lived ongoing queries. Those + long-lived queries are often concerned not just about being informed + when records appear, but also about being informed if those records + vanish again. In contrast, a unique record set (such as an SRV + record, or a host address record), by its nature, often has far fewer + members than a shared record set, and is usually the subject of + one-shot queries which simply retrieve the data and then cease + querying once they have the answer they are seeking. Therefore, + sending a goodbye packet for a unique record set is likely to offer + less benefit, because it is likely at any given moment that no one + has an active query running for that record set. One example where + goodbye packets for SRV and address records are useful is when + transferring control to a Sleep Proxy Server (see Section 16. + "Multicast DNS and Power Management"). + + +13.3 Announcements to Flush Outdated Cache Entries + + Whenever a host has a resource record with potentially new data (e.g. + after rebooting, waking from sleep, connecting to a new network link, + changing IP address, etc.), the host MUST send a series of gratuitous + announcements to update cache entries in its neighbour hosts. In + these gratuitous announcements, if the record is one that is intended + to be unique, the host sets the most significant bit of the rrclass + field of the resource record. This bit, the "cache flush" bit, tells + neighbouring hosts that this is not a shared record type. Instead of + merging this new record additively into the cache in addition to any + previous records with the same name, type and class, all old records + with that name, type and class that were received more than one + second ago are declared invalid, and marked to expire from the cache + in one second. + + The semantics of the cache flush bit are as follows: Normally when a + resource record appears in the answer section of the DNS Response, it + means, "This is an assertion that this information is true." When a + resource record appears in the answer section of the DNS Response + with the "cache flush" bit set, it means, "This is an assertion that + this information is the truth and the whole truth, and anything you + + +Expires 29th July 2004 Cheshire & Krochmal [Page 26] + +Internet Draft Multicast DNS 29th January 2003 + + + may have heard more than a second ago regarding records of this + name/type/class is no longer valid". + + To accommodate the case where the set of records from one host + constituting a single unique RRSet is too large to fit in a single + packet, only cache records that are more than one second old are + flushed. This allows the announcing host to generate a quick burst of + packets back-to-back on the wire containing all the members + of the RRSet. When receiving records with the "cache flush" bit set, + all records older than one second are marked to be deleted one second + in the future. One second after the end of the little packet burst, + any records not represented within that packet burst will then be + expired from all peer caches. + + Any time a host sends a response packet containing some members of a + unique RRSet, it SHOULD send the entire RRSet, preferably in a single + packet, or if the entire RRSet will not fit in a single packet, in a + quick burst of packets sent as close together as possible. The host + SHOULD set the cache flush bit on all members of the unique RRSet. + In the event that for some reason the host chooses not to send the + entire unique RRSet in a single packet or a rapid packet burst, + it MUST NOT set the cache flush bit on any of those records. + + The reason for waiting one second before deleting stale records from + the cache is to accommodate bridged networks. For example, a host's + address record announcement on a wireless interface may be bridged + onto a wired Ethernet, and cause that same host's Ethernet address + records to be flushed from peer caches. The one-second delay gives + the host the chance to see its own announcement arrive on the wired + Ethernet, and immediately re-announce its Ethernet address records + so that both sets remain valid and live in peer caches. + + These rules apply regardless of *why* the response packet is being + generated. They apply to startup announcements as described in + Section 9.3, and to responses generated as a result of receiving + query packets. + + The "cache flush" bit is only set in Multicast DNS responses sent to + UDP port 5353. The "cache flush" bit MUST NOT be set in any resource + records in a response packet sent in legacy unicast responses to UDP + ports other than 5353. + + The "cache flush" bit MUST NOT be set in any resource records in the + known-answer list of any query packet. + + The "cache flush" bit MUST NOT ever be set in any shared resource + record. To do so would cause all the other shared versions of this + resource record with different rdata from different Responders to be + immediately deleted from all the caches on the network. + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 27] + +Internet Draft Multicast DNS 29th January 2003 + + + Note that the "cache flush" bit is NOT part of the resource record + class. The "cache flush" bit is the most significant bit of the + second 16-bit word of a resource record in an mDNS packet (the field + conventionally referred to as the rrclass field), and the actual + resource record class is the least-significant fifteen bits of this + field. There is no mDNS resource record class 0x8001. The value + 0x8001 in the rrclass field of a resource record in an mDNS response + packet indicates a resource record with class 1, with the "cache + flush" bit set. When receiving a resource record with the "cache + flush" bit set, implementations should take care to mask off that bit + before storing the resource record in memory. + + +13.4 Cache Flush on Topology change + + If the hardware on a given host is able to indicate physical changes + of connectivity, then when the hardware indicates such a change, the + host should take this information into account in its mDNS cache + management strategy. For example, a host may choose to immediately + flush all cache records received on a particular interface when that + cable is disconnected. Alternatively, a host may choose to adjust the + remaining TTL on all those records to a few seconds so that if the + cable is not reconnected quickly, those records will expire from the + cache. + + Likewise, when a host reboots, or wakes from sleep, or undergoes some + other similar discontinuous state change, the cache management + strategy should take that information into account. + + +13.5 Cache Flush on Failure Indication + + Sometimes a cache record can be determined to be stale when a client + attempts to use the rdata it contains, and finds that rdata to be + incorrect. + + For example, the rdata in an address record can be determined to be + incorrect if attempts to contact that host fail, either because + ARP/ND requests for that address go unanswered (for an address on a + local subnet) or because a router returns an ICMP "Host Unreachable" + error (for an address on a remote subnet). + + The rdata in an SRV record can be determined to be incorrect if + attempts to communicate with the indicated service at the host and + port number indicated are not successful. + + The rdata in a DNS-SD PTR record can be determined to be incorrect if + attempts to look up the SRV record it references are not successful. + + In any such case, the software implementing the mDNS resource record + cache should provide a mechanism so that clients detecting stale + rdata can inform the cache. + +Expires 29th July 2004 Cheshire & Krochmal [Page 28] + +Internet Draft Multicast DNS 29th January 2003 + + + When the cache receives this hint that it should reconfirm some + record, it MUST issue two or more queries for the resource record in + question. If no response is received in a reasonable amount of time, + then, even though its TTL may indicate that it is not yet due to + expire, that record SHOULD be promptly flushed from the cache. + + The end result of this is that if a printer suffers a sudden power + failure or other abrupt disconnection from the network, its name may + continue to appear in DNS-SD browser lists displayed on users' + screens. Eventually that entry will expire from the cache naturally, + but if a user tries to access the printer before that happens, the + failure to successfully contact the printer will trigger the more + hasty demise of its cache entries. This is a sensible trade-off + between good user-experience and good network efficiency. If we were + to insist that printers should disappear from the printer list within + 30 seconds of becoming unavailable, for all failure modes, the only + way to achieve this would be for the client to poll the printer at + least every 30 seconds, or for the printer to announce its presence + at least every 30 seconds, both of which would be an unreasonable + burden on most networks. + + +13.6 Passive Observation of Failures + + A host observes the multicast queries issued by the other hosts on + the network. One of the major benefits of also sending responses + using multicast is that it allows all hosts to see the responses (or + lack thereof) to those queries. + + If a host sees queries, for which a record in its cache would be + expected to be given as an answer in a multicast response, but no + such answer is seen, then the host may take this as an indication + that the record may no longer be valid. + + After seeing two or more of these queries, and seeing no multicast + response containing the expected answer within a reasonable amount of + time, then even though its TTL may indicate that it is not yet due to + expire, that record MAY be flushed from the cache. The host SHOULD + NOT perform its own queries to re-confirm that the record is truly + gone. If every host on a large network were to do this, it would + cause a lot of unnecessary multicast traffic. If host A sends + multicast queries that remain unanswered, then there is no reason to + suppose that host B or any other host is likely to be any more + successful. + + The previous section, "Cache Flush on Failure Indication", describes + a situation where a user trying to print discovers that the printer + is no longer available. By implementing the passive observation + described here, when one user fails to contact the printer, all hosts + on the network observe that failure and update their caches + accordingly. + + +Expires 29th July 2004 Cheshire & Krochmal [Page 29] + +Internet Draft Multicast DNS 29th January 2003 + + +14. Enabling and Disabling Multicast DNS + + The option to fail-over to Multicast DNS for names not ending in + ".local." SHOULD be a user-configured option, and SHOULD + be disabled by default because of the possible security issues + related to unintended local resolution of apparently global names. + + The option to lookup unqualified (relative) names by appending + ".local." (or not) is controlled by whether ".local." appears + (or not) in the client's DNS search list. + + No special control is needed for enabling and disabling Multicast DNS + for names explicitly ending with ".local." as entered by the user. + The user doesn't need a way to disable Multicast DNS for names ending + with ".local.", because if the user doesn't want to use Multicast + DNS, they can achieve this by simply not using those names. If a user + *does* enter a name ending in ".local.", then we can safely assume + the user's intention was probably that it should work. Having user + configuration options that can be (intentionally or unintentionally) + set so that local names don't work is just one more way of + frustrating the user's ability to perform the tasks they want, + perpetuating the view that, "IP networking is too complicated to + configure and too hard to use." This in turn perpetuates the + continued use of protocols like AppleTalk. If we want to retire + AppleTalk, NetBIOS, etc., we need to offer users equivalent IP + functionality that they can rely on to, "always work, like + AppleTalk." A little Multicast DNS traffic may be a burden on the + network, but it is an insignificant burden compared to continued + widespread use of AppleTalk. + + +15. Considerations for Multiple Interfaces + + A host should defend its host name (FQDN) on all active interfaces on + which it is answering Multicast DNS queries. + + In the event of a name conflict on *any* interface, a host should + configure a new host name, if it wishes to maintain uniqueness of its + host name. + + When answering a Multicast DNS query, a multi-homed host with a + link-local address (or addresses) should take care to ensure that + any address going out in a Multicast DNS response is valid for use + on the interface on which the response is going out. + + Just as the same link-local IP address may validly be in use + simultaneously on different links by different hosts, the same + link-local host name may validly be in use simultaneously on + different links, and this is not an error. A multi-homed host with + connections to two different links may be able to communicate with + two different hosts that are validly using the same name. While this + + +Expires 29th July 2004 Cheshire & Krochmal [Page 30] + +Internet Draft Multicast DNS 29th January 2003 + + + kind of name duplication should be rare, it means that a host that + wants to fully support this case needs network programming APIs that + allow applications to specify on what interface to perform a + link-local Multicast DNS query, and to discover on what interface a + Multicast DNS response was received. + + +16. Multicast DNS and Power Management + + Many modern network devices have the ability to go into a low-power + mode where only a small part of the Ethernet hardware remains + powered, and the device can be woken up by sending a specially + formatted Ethernet frame which the device's power-management hardware + recognizes. + + To make use of this in conjunction with Multicast DNS, the device + first uses DNS-SD to determine if Sleep Proxy Service is available on + the local network. In some networks there may be more than one piece + of hardware implementing Sleep Proxy Service, for fault-tolerance + reasons. + + If the device finds the network has Sleep Proxy Service, the device + transmits two or more gratuitous mDNS announcements setting the TTL + of its relevant resource records to zero, to delete them from + neighbouring caches. The relevant resource records include address + records and SRV records, and other resource records as may apply to a + particular device. The device then communicates all of its remaining + active records, plus the names, types and classes of the deleted + records, to the Sleep Proxy Service(s), along with a copy of the + specific "magic packet" required to wake the device up. + + When a Sleep Proxy Service sees an mDNS query for one of the + device's active records (e.g. a DNS-SD PTR record), it answers on + behalf of the device without waking it up. When a Sleep Proxy Service + sees an mDNS query for one of the device's deleted resource + records, it deduces that some client on the network needs to make an + active connection to the device, and sends the specified "magic + packet" to wake the device up. The device then wakes up, reactivates + its deleted resource records, and re-announces them to the network. + The client waiting to connect sees the announcements, learns the + current IP address and port number of the desired service on the + device, and proceeds to connect to it. + + The connecting client does not need to be aware of how Sleep Proxy + Service works. Only devices that implement low power mode and wish to + make use of Sleep Proxy Service need to be aware of how that protocol + works. + + The reason that a device using a Sleep Proxy Service should send more + than one goodbye packet is that the wakeup message is caused by the + Sleep Proxy Service seeing queries for the device's SRV and/or + address records, and those queries are in turn caused by the records + +Expires 29th July 2004 Cheshire & Krochmal [Page 31] + +Internet Draft Multicast DNS 29th January 2003 + + + being absent from peer caches. If the records are not deleted from + peer caches, then those peers may use the cached value directly + without querying, and no wakeup message would be generated. + + The full specification of mDNS / DNS-SD Sleep Proxy Service + is described in another document [not yet published]. + + +17. Multicast DNS Character Set + + Unicast DNS has been plagued by the lack of any support for non-US + characters. Indeed, conventional DNS is usually limited to just + letters, digits and hyphens, with no spaces or other punctuation. + Attempts to remedy this have made slow progress because of the need + to accommodate old buggy legacy implementations. + + Multicast DNS is a new protocol and doesn't (yet) have old buggy + legacy implementations to constrain the design choices. Accordingly, + it adopts the obvious simple solution: all names in Multicast DNS are + encoded using UTF-8 [RFC 2279]. For names that are restricted to + letters, digits and hyphens, the UTF-8 encoding is identical to the + US-ASCII encoding, so this is entirely compatible with existing host + names. For characters outside the US-ASCII range, UTF-8 encoding is + used. + + Multicast DNS implementations MUST NOT use any other encodings apart + from UTF-8 (US-ASCII being considered a compatible subset of UTF-8). + + This point bears repeating: There are various baroque representations + of international text being proposed for Unicast DNS. None of these + representations may be used in Multicast DNS packets. Any text being + represented internally in some other representation MUST be converted + to canonical UTF-8 before being placed in any Multicast DNS packet. + + The simple rules for case-insensitivity in Unicast DNS also apply in + Multicast DNS; that is to say, in name comparisons, the lower-case + letters "a" to "z" match their upper-case equivalents "A" to "Z". + Hence, if a client issues a query for an address record with the name + "stuartcheshire.local", then a responder having an address record + with the name "StuartCheshire.local" should issue a response. + + No other automatic character equivalence is defined in Multicast DNS. + For example, accented characters are not defined to be automatically + equivalent to their unaccented counterparts. Where automatic + equivalences are desired, this may be achieved through the use of + programmatically-generated CNAME records. For example, if a responder + has an address record for an accented name Y, and a client issues a + query for a name X, where X is the same as Y with all the accents + removed, then the responder may issue a response containing two + resource records: A CNAME record "X CNAME Y", asserting that the + requested name X (unaccented) is an alias for the true (accented) + name Y, followed by the address record for Y. + +Expires 29th July 2004 Cheshire & Krochmal [Page 32] + +Internet Draft Multicast DNS 29th January 2003 + + +18. Multicast DNS Message Size + + RFC 1035 restricts DNS Messages carried by UDP to no more than 512 + bytes (not counting the IP or UDP headers). For UDP packets carried + over the wide-area Internet in 1987, this was appropriate. For + link-local multicast packets on today's networks, there is no reason + to retain this restriction. Given that the packets are by definition + link-local, there are no Path MTU issues to consider. + + Multicast DNS Messages carried by UDP may be up to the IP MTU of the + physical interface, less the space required for the IP header (20 + bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes). + + In the case of a single mDNS Resource Record which is too large to + fit in a single MTU-sized multicast response packet, a Multicast DNS + Responder SHOULD send the Resource Record alone, in a single IP + datagram, sent using multiple IP fragments. Resource Records this + large SHOULD be avoided, except in the very rare cases where they + really are the appropriate solution to the problem at hand. + Implementers should be aware that many simple devices do not + re-assemble fragmented IP datagrams, so large Resource Records SHOULD + only be used in specialized cases where the implementer knows that + all receivers implement reassembly. + + A Multicast DNS packet larger than the interface MTU, which is sent + using fragments, MUST NOT contain more than one Resource Record. + + Even when fragmentation is used, a Multicast DNS packet, including IP + and UDP headers, MUST NOT exceed 9000 bytes. + + +19. Multicast DNS Message Format + + This section describes specific restrictions on the allowable + values for the header fields of a Multicast DNS message. + +19.1. ID (Query Identifier) + + Multicast DNS clients SHOULD listen for gratuitous responses + issued by hosts booting up (or waking up from sleep or otherwise + joining the network). Since these gratuitous responses may contain a + useful answer to a question for which the client is currently + awaiting an answer, Multicast DNS clients SHOULD examine all received + Multicast DNS response messages for useful answers, without regard to + the contents of the ID field or the question section. In Multicast + DNS, knowing which particular query message (if any) is responsible + for eliciting a particular response message is less interesting than + knowing whether the response message contains useful information. + + Multicast DNS clients MAY cache any or all Multicast DNS response + messages they receive, for possible future use, providing of course + that normal TTL aging is performed on these cashed resource records. + +Expires 29th July 2004 Cheshire & Krochmal [Page 33] + +Internet Draft Multicast DNS 29th January 2003 + + + In multicast query messages, the Query ID SHOULD be set to zero on + transmission. + + In multicast responses, including gratuitous multicast responses, the + Query ID MUST be set to zero on transmission, and MUST be ignored on + reception. + + In unicast response messages generated specifically in response to a + particular (unicast or multicast) query, the Query ID MUST match the + ID from the query message. + + +19.2. QR (Query/Response) Bit + + In query messages, MUST be zero. + + In response messages, MUST be one. + + +19.3. OPCODE + + In both multicast query and multicast response messages, MUST be zero + (only standard queries are currently supported over multicast, unless + other queries are allowed by future IETF Standards Action). + + +19.4. AA (Authoritative Answer) Bit + + In query messages, the Authoritative Answer bit MUST be zero on + transmission, and MUST be ignored on reception. + + In response messages for Multicast Domains, the Authoritative Answer + bit MUST be set to one (not setting this bit implies there's some + other place where "better" information may be found) and MUST be + ignored on reception. + + +19.5. TC (Truncated) Bit + + In query messages, if the TC bit is set, it means that additional + Known Answer records may be following shortly. A responder MAY choose + to record this fact, and wait for those additional Known Answer + records, before deciding whether to respond. If the TC bit is clear, + it means that the querying host has no additional Known Answers. + + In multicast response messages, the TC bit MUST be zero on + transmission, and MUST be ignored on reception. + + In legacy unicast response messages, the TC bit has the same meaning + as in conventional unicast DNS: it means that the response was too + large to fit in a single packet, so the client SHOULD re-issue its + query using TCP in order to receive the larger response. + +Expires 29th July 2004 Cheshire & Krochmal [Page 34] + +Internet Draft Multicast DNS 29th January 2003 + + +19.6. RD (Recursion Desired) Bit + + In both multicast query and multicast response messages, the + Recursion Desired bit SHOULD be zero on transmission, and MUST be + ignored on reception. + + +19.7. RA (Recursion Available) Bit + + In both multicast query and multicast response messages, the + Recursion Available bit MUST be zero on transmission, and MUST be + ignored on reception. + + +19.8. Z (Zero) Bit + + In both query and response messages, the Zero bit MUST be zero on + transmission, and MUST be ignored on reception. + + +19.9. AD (Authentic Data) Bit [RFC 2535] + + In query messages the Authentic Data bit MUST be zero on + transmission, and MUST be ignored on reception. + + In response messages, the Authentic Data bit MAY be set. Resolvers + receiving response messages with the AD bit set MUST NOT trust the AD + bit unless they trust the source of the message and either have a + secure path to it or use DNS transaction security. + + +19.10. CD (Checking Disabled) Bit [RFC 2535] + + In query messages, a resolver willing to do cryptography SHOULD set + the Checking Disabled bit to permit it to impose its own policies. + + In response messages, the Checking Disabled bit MUST be zero on + transmission, and MUST be ignored on reception. + + +19.11. RCODE (Response Code) + + In both multicast query and multicast response messages, the Response + Code MUST be zero on transmission. Multicast DNS messages received + with non-zero Response Codes MUST be silently ignored. + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 35] + +Internet Draft Multicast DNS 29th January 2003 + + +20. Choice of UDP Port Number + + Arguments were made for and against using Multicast on UDP port 53. + The final decision was to use UDP port 5353. Some of the arguments + for and against are given below. + + +20.1 Arguments for using UDP port 53: + + * This is "just DNS", so it should be the same port. + + * There is less work to be done updating old clients to do simple + mDNS queries. Only the destination address need be changed. + In some cases, this can be achieved without any code changes, + just by adding the address 224.0.0.251 to a configuration file. + + +20.2 Arguments for using a different port (UDP port 5353): + + * This is not "just DNS". This is a DNS-like protocol, but different. + + * Changing client code to use a different port number is not hard. + + * Using the same port number makes it hard to run an mDNS Responder + and a conventional unicast DNS server on the same machine. If a + conventional unicast DNS server wishes to implement mDNS as well, + it can still do that, by opening two sockets. Having two different + port numbers is important to allow this flexibility. + + * Some VPN software hijacks all outgoing traffic to port 53 and + redirects it to a special DNS server set up to serve those VPN + clients while they are connected to the corporate network. It is + questionable whether this is the right thing to do, but it is + common, and redirecting link-local multicast DNS packets to a + remote server rarely produces any useful results. It does mean, for + example, that the user becomes unable to access their local network + printer sitting on their desk right next to their computer. Using + a different UDP port eliminates this particular problem. + + * On many operating systems, unprivileged clients may not send or + receive packets on low-numbered ports. This means that any client + sending or receiving mDNS packets on port 53 would have to run as + "root", which is an undesirable security risk. Using a higher- + numbered UDP port eliminates this particular problem. + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 36] + +Internet Draft Multicast DNS 29th January 2003 + + +21. Summary of Differences Between Multicast DNS and Unicast DNS + + The value of Multicast DNS is that it shares, as much as possible, + the familiar APIs, naming syntax, resource record types, etc., of + Unicast DNS. There are of course necessary differences by virtue of + it using Multicast, and by virtue of it operating in a community of + cooperating peers, rather than a precisely defined authoritarian + hierarchy controlled by a strict chain of formal delegations from the + top. These differences are listed below: + + Multicast DNS... + * uses multicast + * uses UDP port 5353 instead of port 53 + * operates in well-defined parts of the DNS namespace + * uses UTF-8, and only UTF-8, to encode resource record names + * defines a clear limit on the maximum legal domain name (255 bytes) + * allows larger UDP packets + * allows more than one question in a query packet + * uses the Answer Section of a query to list Known Answers + * uses the TC bit in a query to indicate additional Known Answers + * uses the Authority Section of a query for probe tie-breaking + * ignores the Query ID field (except for generating legacy responses) + * doesn't require the question to be repeated in the response packet + * uses gratuitous responses to announce new records to the peer group + * defines a "unicast response" bit in the rrclass of query questions + * defines a "cache flush" bit in the rrclass of responses + * uses DNS TTL 0 to indicate that a record has been deleted + * uses IP TTL 255 to verify that answers originated on the local link + * monitors queries to perform Duplicate Question Suppression + * monitors responses to perform Duplicate Answer Suppression... + * ... and Ongoing Conflict Detection + * ... and Opportunistic Caching + + + + + + + + + + + + + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 37] + +Internet Draft Multicast DNS 29th January 2003 + + +22. Benefits of Multicast Responses + + Some people have argued that sending responses via multicast is + inefficient on the network. In fact the benefits of using multicast + responses result in a net lowering of overall multicast traffic, for + a variety of reasons. + + * One multicast response can update the cache on all machines on the + network. If another machine later wants to issue the same query, it + already has the answer in its cache, so it may not need to even + transmit that multicast query on the network at all. + + * When more than one machine has the same ongoing long-lived query + running, every machine does not have to transmit its own + independent query. When one machine transmits a query, all the + other hosts see the answers, so they can suppress their own + queries. + + * When a host sees a multicast query, but does not see the + corresponding multicast response, it can use this information to + promptly delete stale data from its cache. To achieve the same + level of user-interface quality and responsiveness without + multicast responses would require lower cache lifetimes and more + frequent network polling, resulting in a significantly higher + packet rate. + + * Multicast responses allow passive conflict detection. Without this + ability, some other conflict detection mechanism would be needed, + imposing its own additional burden on the network. + + + + + + + + + + + + + + + + + + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 38] + +Internet Draft Multicast DNS 29th January 2003 + + +23. IPv6 Considerations + + An IPv4-only host and an IPv6-only host behave as "ships that pass in + the night". Even if they are on the same Ethernet, neither is aware + of the other's traffic. For this reason, each physical link may have + *two* unrelated ".local." zones, one for IPv4 and one for IPv6. + Since for practical purposes, a group of IPv4-only hosts and a group + of IPv6-only hosts on the same Ethernet act as if they were on two + entirely separate Ethernet segments, it is unsurprising that their + use of the ".local." zone should occur exactly as it would if + they really were on two entirely separate Ethernet segments. + + A dual-stack (v4/v6) host can participate in both ".local." + zones, and should register its name(s) and perform its lookups both + using IPv4 and IPv6. This enables it to reach, and be reached by, + both IPv4-only and IPv6-only hosts. In effect this acts like a + multi-homed host, with one connection to the logical "IPv4 Ethernet + segment", and a connection to the logical "IPv6 Ethernet segment". + +23.1 IPv6 Multicast Addresses by Hashing + + Some discovery protocols use a range of multicast addresses, and + determine the address to be used by a hash function of the name being + sought. Queries are sent via multicast to the address as indicated by + the hash function, and responses are returned to the querier via + unicast. Particularly in IPv6, where multicast addresses are + extremely plentiful, this approach is frequently advocated. + + There are some problems with this: + + * When a host has a large number of records with different names, the + host may have to join a large number of multicast groups. This can + place undue burden on the Ethernet hardware, which typically + supports a limited number of multicast addresses efficiently. When + this number is exceeded, the Ethernet hardware may have to resort + to receiving all multicasts and passing them up to the host + software for filtering, thereby defeating the point of using a + multicast address range in the first place. + + * Multiple questions cannot be placed in one packet if they don't all + hash to the same multicast address. + + * Duplicate Question Suppression doesn't work if queriers are not + seeing each other's queries. + + * Duplicate Answer Suppression doesn't work if responders are not + seeing each other's responses. + + * Opportunistic Caching doesn't work. + + * Ongoing Conflict Detection doesn't work. + + +Expires 29th July 2004 Cheshire & Krochmal [Page 39] + +Internet Draft Multicast DNS 29th January 2003 + + +24. Security Considerations + + The algorithm for detecting and resolving name conflicts is, by its + very nature, an algorithm that assumes cooperating participants. Its + purpose is to allow a group of hosts to arrive at a mutually disjoint + set of host names and other DNS resource record names, in the absence + of any central authority to coordinate this or mediate disputes. In + the absence of any higher authority to resolve disputes, the only + alternative is that the participants must work together cooperatively + to arrive at a resolution. + + In an environment where the participants are mutually antagonistic + and unwilling to cooperate, other mechanisms are appropriate, like + manually administered DNS. + + In an environment where there is a group of cooperating participants, + but there may be other antagonistic participants on the same physical + link, the cooperating participants need to use IPSEC signatures + and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS + messages from trusted participants (which they process as usual) from + mDNS messages from untrusted participants (which they silently + discard). + + When DNS queries for *global* DNS names are sent to the mDNS + multicast address (during network outages which disrupt communication + with the greater Internet) it is *especially* important to use + DNSSEC, because the user may have the impression that he or she is + communicating with some authentic host, when in fact he or she is + really communicating with some local host that is merely masquerading + as that name. This is less critical for names ending with ".local.", + because the user should be aware that those names have only local + significance and no global authority is implied. + + Most computer users neglect to type the trailing dot at the end of a + fully qualified domain name, making it a relative domain name (e.g. + "www.example.com"). In the event of network outage, attempts to + positively resolve the name as entered will fail, resulting in + application of the search list, including ".local.", if present. + A malicious host could masquerade as "www.example.com" by answering + the resulting Multicast DNS query for "www.example.com.local." + To avoid this, a host MUST NOT append the search suffix + ".local.", if present, to any relative (partially qualified) + domain name containing two or more labels. Appending ".local." to + single-label relative domain names is acceptable, since the user + should have no expectation that a single-label domain name will + resolve as-is. + + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 40] + +Internet Draft Multicast DNS 29th January 2003 + + +25. IANA Considerations + + The IANA has allocated the IPv4 link-local multicast address + 224.0.0.251 for the use described in this document. + + The IANA has allocated the IPv6 multicast address set FF0X::FB + for the use described in this document. + + When this document is published, IANA should designate a list + of domains which are deemed to have only link-local significance, + as described in this document. + + No other IANA services are required by this document. + + +26. Acknowledgements + + The concepts described in this document have been explored and + developed with help from Erik Guttman, Paul Vixie, Bill Woodcock, + and others. + + +27. Copyright + + Copyright (C) The Internet Society January 2004. + 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 + 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. + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 41] + +Internet Draft Multicast DNS 29th January 2003 + + +28. Normative References + + [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. + + +29. Informative References + + [dotlocal] + + [djbdl] + + [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: + Overview and Architecture. + Institute of Electrical and Electronic Engineers, + IEEE Standard 802, 1990. + + [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service + Discovery", Internet-Draft (work in progress), + draft-cheshire-dnsext-dns-sd-03.txt, January 2004. + + [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name + System (DNS UPDATE)", RFC 2136, April 1997. + + [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", + Internet-Draft (work in progress), + draft-ietf-zeroconf-ipv4-linklocal-11.txt, January 2004. + + [ZC] Williams, A., "Requirements for Automatic Configuration + of IP Hosts", Internet-Draft (work in progress), + draft-ietf-zeroconf-reqts-12.txt, September 2002. + + + + + + +Expires 29th July 2004 Cheshire & Krochmal [Page 42] + +Internet Draft Multicast DNS 29th January 2003 + + +30. Author's 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 29th July 2004 Cheshire & Krochmal [Page 43] diff --git a/specs/draft-cheshire-dnsext-multicastdns-04.txt b/specs/draft-cheshire-dnsext-multicastdns-04.txt new file mode 100644 index 0000000..8750583 --- /dev/null +++ b/specs/draft-cheshire-dnsext-multicastdns-04.txt @@ -0,0 +1,2494 @@ +Document: draft-cheshire-dnsext-multicastdns-04.txt Stuart Cheshire +Category: Standards Track Apple Computer, Inc. +Expires 14th August 2004 Marc Krochmal + Apple Computer, Inc. + 14th February 2004 + + Multicast DNS + + + + +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 + + As networked devices become smaller, more portable, and more + ubiquitous, the ability to operate with less configured + infrastructure is increasingly important. In particular, the ability + to look up DNS resource record data types (including, but not limited + to, host names) in the absence of a conventional managed DNS server, + is becoming essential. + + Multicast DNS (mDNS) provides the ability to do DNS-like operations + on the local link in the absense of any conventional unicast DNS + server. In addition, mDNS designates a portion of the DNS namespace + to be free for local use, without the need to pay any annual fee, and + without the need to set up delegations or otherwise configure a + conventional DNS server to answer for those names. + + The primary benefits of mDNS names are that (i) they require little + or no administration or configuration to set them up, (ii) they work + when no infrastructure is present, and (iii) they work during + infrastructure failures. + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 1] + +Internet Draft Multicast DNS 14th February 2004 + + +Table of Contents + + 1. Introduction...................................................3 + 2. Conventions and Terminology Used in this Document..............4 + 3. Multicast DNS Names............................................4 + 4. IP TTL Checks..................................................8 + 5. Reverse Address Mapping........................................8 + 6. Querying.......................................................9 + 7. Duplicate Suppression.........................................13 + 8. Responding....................................................15 + 9. Probing and Announcing on Startup.............................17 + 10. Conflict Resolution...........................................21 + 11. Special Characteristics of Multicast DNS Domains..............23 + 12. Multicast DNS for Service Discovery...........................24 + 13. Resource Record TTL Values and Cache Coherency................25 + 14. Enabling and Disabling Multicast DNS..........................30 + 15. Considerations for Multiple Interfaces........................30 + 16. Multicast DNS and Power Management............................31 + 17. Multicast DNS Character Set...................................32 + 18. Multicast DNS Message Size....................................33 + 19. Multicast DNS Message Format..................................33 + 20. Choice of UDP Port Number.....................................36 + 21. Summary of Differences Between Multicast DNS and Unicast DNS..37 + 22. Benefits of Multicast Responses...............................38 + 23. IPv6 Considerations...........................................39 + 24. Security Considerations.......................................40 + 25. IANA Considerations...........................................41 + 26. Acknowledgements..............................................41 + 27. Copyright.....................................................41 + 28. Normative References..........................................42 + 29. Informative References........................................42 + 30. Author's Addresses............................................43 + + + + + + + + + + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 2] + +Internet Draft Multicast DNS 14th February 2004 + + +1. Introduction + + When reading this document, familiarity with the concepts of Zero + Configuration Networking [ZC] and automatic link-local addressing + [v4LL] [RFC 2462] is helpful. + + This document proposes no change to the structure of DNS messages, + and no new operation codes, response codes, or resource record types. + This document simply discusses what needs to happen if DNS clients + start sending DNS queries to a multicast address, and how a + collection of hosts can cooperate to collectively answer those + queries in a useful manner. + + There has been discussion of how much burden Multicast DNS might + impose on a network. It should be remembered that whenever IPv4 hosts + communicate, they broadcast ARP packets on the network on a regular + basis, and this is not disastrous. The approximate amount of + multicast traffic generated by hosts making conventional use of + Multicast DNS is anticipated to be roughly the same order of + magnitude as the amount of broadcast ARP traffic those hosts already + generate. + + New applications making new use of Multicast DNS capabilities for + unconventional purposes may generate more traffic. If some of those + new applications are "chatty", then work will be needed to help them + become less chatty. When performing any analysis, it is important to + make a distinction between the application behavior and the + underlying protocol behavior. If a chatty application uses UDP, that + doesn't mean that UDP is chatty, or that IP is chatty, or that + Ethernet is chatty. What it means is that the application is chatty. + The same applies to any future applications that may decide to layer + increasing portions of their functionality over Multicast DNS. + + + + + + + + + + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 3] + +Internet Draft Multicast DNS 14th February 2004 + + +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]. + + This document uses the term "host name" in the strict sense to mean a + fully qualified domain name that has an address record. It does not + use the term "host name" in the commonly used but incorrect sense to + mean just the first DNS label of a host's fully qualified domain + name. + + A DNS (or mDNS) packet contains an IP TTL in the IP header, which + is effectively a hop-count limit for the packet, to guard against + routing loops. Each Resource Record also contains a TTL, which is + the number of seconds for which the Resource Record may be cached. + + In any place where there may be potential confusion between these two + types of TTL, the term "IP TTL" is used to refer to the IP header TTL + (hop limit), and the term "RR TTL" is used to refer to the Resource + Record TTL (cache lifetime). + + When this document uses the term "Multicast DNS", it should be taken + to mean: Clients performing DNS-like queries for DNS-like resource + records by sending DNS-like UDP query and response packets over IP + Multicast to UDP port 5353." + + +3. Multicast DNS Names + + This document proposes that the DNS top-level domain ".local." be + designated a special domain with special semantics, namely that any + fully-qualified name ending in ".local." is link-local, and names + within this domain are meaningful only on the link where they + originate. This is analogous to IPv4 addresses in the 169.254/16 + prefix, which are link-local and meaningful only on the link where + they originate. + + Any DNS query for a name ending with ".local." MUST be sent + to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent + FF02::FB). + + It is unimportant whether a name ending with ".local." occurred + because the user explicitly typed in a fully qualified domain name + ending in ".local.", or because the user entered an unqualified + domain name and the host software appended the suffix ".local." + because that suffix appears in the user's search list. The ".local." + suffix could appear in the search list because the user manually + configured it, or because it was received in a DHCP option, or via + any other valid mechanism for configuring the DNS search list. In + + +Expires 14th August 2004 Cheshire & Krochmal [Page 4] + +Internet Draft Multicast DNS 14th February 2004 + + + this respect the ".local." suffix is treated no differently to any + other search domain that might appear in the DNS search list. + + DNS queries for names that do not end with ".local." MAY be sent to + the mDNS multicast address, if no other conventional DNS server is + available. This can allow hosts on the same link to continue + communicating using each other's globally unique DNS names during + network outages which disrupt communication with the greater + Internet. When resolving global names via local multicast, it is even + more important to use DNSSEC or other security mechanisms to ensure + that the response is trustworthy. Resolving global names via local + multicast is a contentious issue, and this document does not discuss + it in detail, instead concentrating on the issue of resolving local + names using DNS packets sent to a multicast address. + + A host which belongs to an organization or individual who has control + over some portion of the DNS namespace can be assigned a globally + unique name within that portion of the DNS namespace, for example, + "cheshire.apple.com." For those of us who have this luxury, this + works very well. However, the majority of home customers do not have + easy access to any portion of the global DNS namespace within which + they have the authority to create names as they wish. This leaves the + majority of home computers effectively anonymous for practical + purposes. + + To remedy this problem, this document allows any computer user to + elect to give their computers link-local Multicast DNS host names of + the form: "single-dns-label.local." For example, my Titanium + PowerBook laptop computer answers to the name "sctibook.local." Any + computer user is granted the authority to name their computer this + way, providing that the chosen host name is not already in use on + that link. Having named their computer this way, the user has the + authority to continue using that name until such time as a name + conflict occurs on the link which is not resolved in the user's + favour. If this happens, the computer (or its human user) SHOULD + cease using the name, and may choose to attempt to allocate a new + unique name for use on that link. Like law suits over global DNS + names, these conflicts are expected to be relatively rare for people + who choose reasonably imaginative names, but it is still important + to have a mechanism in place to handle them when they happen. + + The point made in the previous paragraph is very important and bears + repeating. It is easy for those of us in the IETF community who run + our own name servers at home to forget that the majority of computer + users do not run their own name server and have no easy way to create + their own host names. When these users wish to transfer files between + two laptop computers, they are frequently reduced to typing in + dotted-decimal IP addresses because they simply have no other way for + one host to refer to the other by name. This is a sorry state of + affairs. What is worse, most users don't even bother trying to use + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 5] + +Internet Draft Multicast DNS 14th February 2004 + + + dotted-decimal IP addresses. Most users still move data between + machines by copying it onto a floppy disk or similar removable media. + + In a world of gigabit Ethernet and ubiquitous wireless networking it + is a sad indictment of the networking community that the preferred + communication medium for most computer users is still the floppy + disk. + + Allowing ad-hoc allocation of single-label names in a single flat + ".local." namespace may seem to invite chaos. However, operational + experience with AppleTalk NBP names [NBP], which on any given link + are also effectively single-label names in a flat namespace, shows + that in practice name collisions happen extremely rarely and are not + a problem. Groups of computer users from disparate organizations + bring Macintosh laptop computers to events such as IETF Meetings, the + Mac Hack conference, the Apple World Wide Developer Conference, etc., + and complaints at these events about users suffering conflicts and + being forced to rename their machines have never been an issue. + + Enforcing uniqueness of host names (i.e. the names of DNS address + records mapping names to IP addresses) is probably desirable in the + common case, but this document does not mandate that. It is + permissible for a collection of coordinated hosts to agree to + maintain multiple DNS address records with the same name, possibly + for load balancing or fault-tolerance reasons. This document does not + take a position on whether that is sensible. It is important that + both modes of operation are supported. The Multicast DNS protocol + allows hosts to verify and maintain unique names for resource records + where that behaviour is desired, and it also allows hosts to maintain + multiple resource records with a single shared name where that + behaviour is desired. This consideration applies to all resource + records, not just address records (host names). In summary: It is + required that the protocol have the ability to detect and handle name + conflicts, but it is not required that this ability be used for every + record. + + +3.1 Governing Standards Body + + Note that this use of the ".local." suffix falls under IETF + jurisdiction, not ICANN jurisdiction. DNS is an IETF network + protocol, governed by protocol rules defined by the IETF. These IETF + protocol rules dictate character set, maximum name length, packet + format, etc. ICANN determines additional rules that apply when the + IETF's DNS protocol is used on the public Internet. In contrast, + private uses of the DNS protocol on isolated private networks are not + governed by ICANN. Since this proposed change is a change to the core + DNS protocol rules, it affects everyone, not just those machines + using the ICANN-governed Internet. Hence this change falls into the + category of an IETF protocol rule, not an ICANN usage rule. + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 6] + +Internet Draft Multicast DNS 14th February 2004 + + +3.2 Private DNS Namespaces + + Note also that the special treatment of names ending in ".local." has + been implemented in Macintosh computers since the days of Mac OS 9, + and continues today in Mac OS X. There are also implementations for + Linux and other platforms [dotlocal]. Operators setting up private + internal networks ("intranets") are advised that their lives may be + easier if they avoid using the suffix ".local." in names in their + private internal DNS server. Alternative possibilities include: + + .intranet + .internal + .private + .corp + .home + + Another alternative naming scheme, advocated by Professor D. J. + Bernstein, is to use a numerical suffix, such as ".6." [djbdl]. + + +3.3 Maximum Multicast DNS Name Length + + RFC 1034 says: + + "the total number of octets that represent a domain name (i.e., + the sum of all label octets and label lengths) is limited to 255." + + This text implies that the final root label at the end of every name + is included in this count (a name can't be represented without it), + but the text does not explicitly state that. Implementations of + Multicast DNS MUST include the label length byte of the final root + label at the end of every name when enforcing the rule that no name + may be longer than 255 bytes. For example, the length of the name + "apple.com." is considered to be 11, which is the number of bytes it + takes to represent that name in a packet without using name + compression: + + ------------------------------------------------------ + | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 | + ------------------------------------------------------ + + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 7] + +Internet Draft Multicast DNS 14th February 2004 + + +4. IP TTL Checks + + All Multicast DNS responses (including responses sent via unicast) + MUST be sent with IP TTL set to 255. + + A host sending Multicast DNS queries to a link-local destination + address (including the 224.0.0.251 link-local multicast address) MUST + verify that the IP TTL in response packets is 255, and silently + discard any response packets where the IP TTL is not 255. Without + this check, it could be possible for remote rogue hosts to send + spoof answer packets (perhaps unicast to the victim host) which the + receiving machine could misinterpret as having originated on the + local link. + + The authors have heard complaints that some older network stack + implementations do not implement the IP_RECVTTL socket option + (or equivalent API) for obtaining the IP TTL of received packets. + This is unfortunate, and these old network stacks would benefit + from adding this API support so that they may benefit from this + enhanced protection against spoof packets arriving from off-link. + + Note that Multicast DNS Responders SHOULD NOT discard queries with + TTLs other than 255. There may be valid future applications of + Multicast DNS where hosts issue unicast queries directed at Multicast + DNS Responders more than one hop away, if Multicast DNS Responders + were to discard queries where the TTL is not 255, they would not + answer these queries. + + +5. Reverse Address Mapping + + Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also + defined to be link-local. + + Any DNS query for a name ending with "254.169.in-addr.arpa." MUST + be sent to the mDNS multicast address 224.0.0.251. Since names under + this domain correspond to IPv4 link-local addresses, it is logical + that the local link is the best place to find information pertaining + to those names. As an optimization, these queries MAY be first + unicast directly to the address in question, but if this query is not + answered, the query MUST also be sent via multicast, to accommodate + the case where the machine in question is not answering for itself + (for example, because it is currently sleeping). + + Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa." + MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB, + with or without an optional initial query unicast directly to the + address in question. + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 8] + +Internet Draft Multicast DNS 14th February 2004 + + +6. Querying + + There are three kinds of Multicast DNS Queries, one-shot queries of + the kind made by today's conventional DNS clients, one-shot queries + accumulating multiple responses made by multicast-aware DNS clients, + and continuous ongoing Multicast DNS Queries used by IP network + browser software. + + A Multicast DNS Responder that is offering records that are intended + to be unique on the local link MUST also implement a Multicast DNS + Querier so that it can first verify the uniqueness of those records + before it begins answering queries for them. + + +6.1 One-Shot Queries + + An unsophisticated DNS client may simply send its DNS queries + blindly to the 224.0.0.251 multicast address, without necessarily + even being aware what a multicast address is. + + Such an unsophisticated DNS client may not get ideal behaviour. Such + a client may simply take the first response it receives and fail to + wait to see if there are more, but in many instances this may not be + a serious problem. If a user types "http://stu.local." into their Web + browser and gets to see the page they were hoping for, then the + protocol has met the user's needs in this case. + + +6.2 One-Shot Queries, Accumulating Multiple Responses + + A more sophisticated DNS client should understand that Multicast DNS + is not exactly the same as unicast DNS, and should modify its + behaviour in some simple ways. + + As described above, there are some cases, such as looking up the + address associated with a unique host name, where a single response + is sufficient, and moreover may be all that is expected. However, + there are other DNS queries where more than one response is + possible, and for these queries a more sophisticated Multicast DNS + client should include the ability to wait for an appropriate period + of time to collect multiple responses. + + A naive DNS client retransmits its query only so long as it has + received no response. A more sophisticated Multicast DNS client is + aware that having received one response is not necessarily an + indication that it might not receive others, and has the ability to + retransmit its query an appropriate number of times at appropriate + intervals until it is satisfied with the collection of responses it + has gathered. + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 9] + +Internet Draft Multicast DNS 14th February 2004 + + + A more sophisticated Multicast DNS client that is retransmitting + a query for which it has already received some responses, MUST + implement Known Answer Suppression, as described below in Section + 7.1. This indicates to responders who have already replied that their + responses have been received, and they don't need to send them again + in response to this repeated query. In addition, the interval between + the first two queries MUST be at least one second, and the + intervals between subsequent queries MUST double. + + +6.3 Continuous Querying + + In One-Shot Queries, with either a single or multiple responses, + the underlying assumption is that the transaction begins when the + application issues a query, and ends when all the desired responses + have been received. There is another type of operation which is more + akin to continuous monitoring. + + Macintosh users are accustomed to opening the "Chooser" window, + selecting a desired printer, and then closing the Chooser window. + However, when the desired printer does not appear in the list, the + user will typically leave the "Chooser" window open while they go and + check to verify that the printer is plugged in, powered on, connected + to the Ethernet, etc. While the user jiggles the wires, hits the + Ethernet hub, and so forth, they keep an eye on the Chooser window, + and when the printer name appears, they know they have fixed whatever + the problem was. This can be a useful and intuitive troubleshooting + technique, but a user who goes home for the weekend leaving the + Chooser window open places a non-trivial burden on the network. + + With continuous querying, multiple queries are sent over a long + period of time, until the user terminates the operation. It is + important that an IP network browser window displaying live + information from the network using Multicast DNS, if left running for + an extended period of time, should generate significantly less + multicast traffic on the network than the old AppleTalk Chooser. + Therefore, the interval between the first two queries MUST be at + least one second, the intervals between subsequent queries MUST + double, and the querier MUST implement Known Answer Suppression, as + described below in Section 7.1. + + When a Multicast DNS Querier receives an answer, the answer contains + a TTL value that indicates for how many seconds this answer is valid. + After this interval has passed, the answer will no longer be valid + and should be deleted from the cache. Before this time is reached, a + Multicast DNS Querier with an ongoing interest in that record SHOULD + re-issue its query to determine whether the record is still valid, + and if so update its expiry time. + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 10] + +Internet Draft Multicast DNS 14th February 2004 + + + To perform this cache maintenance, a Multicast DNS Querier should + plan to issue a query at 80% of the record lifetime, and then if no + answer is received, at 85%, 90% and 95%. If an answer is received, + then the remaining TTL is reset to the value given in the answer, and + this process repeats for as long as the Multicast DNS Querier has an + ongoing interest in the record. If after four queries no answer is + received, the record is deleted when it reaches 100% of its lifetime. + + To avoid the case where multiple Multicast DNS Queriers on a network + all issue their queries simultaneously, a random variation of 2% of + the record TTL should be added, so that queries are scheduled to be + performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL. + + +6.4 Multiple Questions per Query + + Multicast DNS allows a querier to place multiple questions in the + question section of a single Multicast DNS query packet. + + The semantics of a Multicast DNS query packet containing multiple + questions is identical to a series of individual DNS query packets + containing one question each. Combining multiple questions into a + single packet is purely an efficiency optimization, and has no other + semantic significance. + + A useful technique for adaptively combining multiple questions into a + single query is to use a Nagle-style algorithm: When a client issues + its first question, a Query packet is immediately built and sent, + without delay. If the client then continues issuing a rapid series of + questions they are held until either the first query receives at + least one answer, or 100ms has passed, or there are enough questions + to fill the question section of a Multicast DNS query packet. At this + time, all the held questions are placed into a Multicast DNS query + packet and sent. + + +6.5 Questions Requesting Unicast Responses + + Sending Multicast DNS responses via multicast has the benefit that + all the other hosts on the network get to see those responses, and + can keep their caches up to date, and detect conflicting responses. + + However, there are situations where all the other hosts on the + network don't need to see every response. One example is a laptop + computer waking from sleep. At that instant it is a brand new + participant on a new network. Its Multicast DNS cache is empty, and + it has no knowledge of its surroundings. It may have a significant + number of queries that it wants answered right away to discover + information about its new surroundings and present that information + to the user. As a new participant on the network, it has no idea + whether the exact same questions may have been asked and answered + + +Expires 14th August 2004 Cheshire & Krochmal [Page 11] + +Internet Draft Multicast DNS 14th February 2004 + + + just seconds ago. In this case, trigging a large sudden flood of + multicast responses may impose an unreasonable burden on the network. + To avoid this, the Multicast DNS Querier SHOULD set the top bit in + the class field of its DNS question(s), to indicate that it is + willing to accept unicast responses instead of the usual multicast + responses. These questions requesting unicast responses are referred + to as "QU" questions, to distinguish them from the more usual + questions requesting multicast responses ("QM" questions). + + When retransmitting a question more than once, the 'unicast response' + bit SHOULD be set only for the first question of the series. After + the first question has received its responses, the querier should + have a large known-answer list (see "Known Answer Suppression" below) + so that subsequent queries should elicit few, if any, further + responses. Reverting to multicast responses as soon as possible is + important because of the benefits that multicast responses provide + (see "Benefits of Multicast Responses" below). + + When receiving a question with the 'unicast response' bit set, a + responder SHOULD usually respond with a unicast packet directed back + to the querier. If the responder has not multicast that record + recently (within one quarter of its TTL), then the responder SHOULD + instead multicast the response so as to keep all the peer caches up + to date, and to permit passive conflict detection. + + +6.6 Suppressing Initial Query + + If a query is issued for which there already exist one or more + records in the local cache, and those record(s) were received with + the cache flush bit set, indicating that they form a unique RRSet, + then the host SHOULD suppress its initial "QU" query, and proceed to + issue a "QM" query. To avoid the situation where a group of hosts + are synchronized by some external event and all perform the same + query simultaneously, a host suppressing its initial "QU" query + SHOULD impose a random delay from 500-1000ms before transmitting its + first "QM" query for this question. This means that when the first + host (selected randomly by this algorithm) transmits its "QM" query, + all the other hosts that were about to transmit the same query can + suppress their superfluous query, as described in "Duplicate + Question Suppression" below. + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 12] + +Internet Draft Multicast DNS 14th February 2004 + + +7. Duplicate Suppression + + A variety of techniques are used to reduce the amount of redundant + traffic on the network. + + +7.1 Known Answer Suppression + + When a Multicast DNS Querier sends a query to which it already knows + some answers, it populates the Answer Section of the DNS message with + those answers. + + A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if + the answer it would give is already included in the Answer Section + with an RR TTL at least half the correct value. If the RR TTL of the + answer as given in the Answer Section is less than half of the true + RR TTL as known by the Multicast DNS Responder, the responder MUST + send an answer so as to update the Querier's cache before the record + becomes in danger of expiration. + + Because a Multicast DNS Responder will respond if the remaining TTL + given in the known answer list is less than half the true TTL, it is + superfluous for the Querier to include such records in the known + answer list. Therefore a Multicast DNS Querier SHOULD NOT include + records in the known answer list whose remaining TTL is less than + half their original TTL. Doing so would simply consume space in the + packet without achieving the goal of suppressing responses, and would + therefore be a pointless waste of network bandwidth. + + A Multicast DNS Querier MUST NOT cache resource records observed in + the Known Answer Section of other Multicast DNS Queries. The Answer + Section of Multicast DNS Queries is not authoritative. By placing + information in the Answer Section of a Multicast DNS Query the + querier is stating that it *believes* the information to be true. + It is not asserting that the information *is* true. Some of those + records may have come from other hosts that are no longer on the + network. Propagating that stale information to other Multicast DNS + Queriers on the network would not be helpful. + + +7.2 Multi-Packet Known Answer Suppression + + Sometimes a Multicast DNS Querier will already have too many answers + to fit in the Known Answer section of its query packets. In this + case, it should issue a Multicast DNS Query containing a question and + as many Known Answer records as will fit. It should then set the TC + (Truncated) bit in the header before sending the Query. It should + then immediately follow the packet with another query containing no + questions, and as many more Known Answer records as will fit. If + there are still too many records remaining to fit in the packet, it + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 13] + +Internet Draft Multicast DNS 14th February 2004 + + + again sets the TC bit and continues until all the Known Answer + records have been sent. + + A Multicast DNS Responder seeing a Multicast DNS Query with the TC + bit set defers its response for a time period randomly selected in + the interval 20-120ms. This gives the Multicast DNS Querier time to + send additional Known Answer packets before the Responder responds. + If the Responder sees any of its answers listed in the Known Answer + lists of subsequent packets from the querying host, it should delete + that answer from the list of answers it is planning to give, provided + that no other host on the network is also waiting to receive the same + answer record. + + +7.3 Duplicate Question Suppression + + If a host is planning to send a query, and it sees another host on + the network send a query containing the same question, and the Known + Answer section of that query does not contain any records which this + host would not also put in its own Known Answer section, then this + host should treat its own query as having been sent. When multiple + clients on the network are querying for the same resource records, + there is no need for them to all be repeatedly asking the same + question. + + +7.4 Duplicate Answer Suppression + + If a host is planning to send an answer, and it sees another host on + the network send a response packet containing the same answer record, + and the TTL in that record is not less than the TTL this host would + have given, then this host should treat its own answer as having been + sent. When multiple responders on the network have the same data, + there is no need for all of them to respond. + + This feature is particularly useful when multiple Sleep Proxy Servers + are deployed (see Section 16. "Multicast DNS and Power Management"). + In the future it is possible that every general-purpose OS (Mac, + Windows, Linux, etc.) will implement Sleep Proxy Service as a matter + of course. In this case there could be a large number of Sleep Proxy + Servers on any given network, which is good for reliability and + fault-tolerance, but would be bad for the network if every Sleep + Proxy Server were to answer every query. + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 14] + +Internet Draft Multicast DNS 14th February 2004 + + +8. Responding + + A Multicast DNS Responder MUST only respond when it has a positive + non-null response to send. Error responses must never be sent. The + non-existence of any name in a Multicast DNS Domain is ascertained by + the failure of any machine to respond to the Multicast DNS query, not + by NXDOMAIN errors. + + Multicast DNS Responses MUST NOT contain any questions in the + Question Section. Any questions in the Question Section of a received + Multicast DNS Response MUST be silently ignored. Multicast DNS + Queriers receiving Multicast DNS Responses do not care what question + elicited the response; they care only that the information in the + response is true and accurate. + + A Multicast DNS Responder on Ethernet [IEEE802] and similar shared + multiple access networks SHOULD delay its responses by a random + amount of time selected with uniform random distribution in the range + 20-120ms. If multiple Multicast DNS Responders were all to respond + immediately to a particular query, a collision would be virtually + guaranteed. By imposing a small random delay, the number of + collisions is dramatically reduced. 120ms is a short enough time that + it is almost imperceptible to a human user, but long enough to + significantly reduce the risk of Ethernet collisions. On a full-sized + Ethernet using the maximum cable lengths allowed and the maximum + number of repeaters allowed, an Ethernet frame is vulnerable to + collisions during the transmission of its first 256 bits. On 10Mb/s + Ethernet, this equates to a vulnerable time window of 25.6us. + + In the case where a Multicast DNS Responder has good reason to + believe that it will be the only responder on the link with a + positive non-null response, it SHOULD NOT impose the random delay + before responding, and SHOULD normally generate its response within + 10ms. To do this safely, it MUST have previously verified that the + requested name, type and class in the DNS query are unique on this + link. Responding immediately without delay is appropriate for things + like looking up the address record for a particular host name, when + the host name has been previously verified unique. Responding + immediately without delay is *not* appropriate for things like + looking up PTR records used for DNS Service Discovery [DNS-SD], where + a large number of responses may be anticipated. + + Except when a unicast reply has been explicitly requested via the + "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port + 5353 (the well-known port assigned to mDNS) on the 224.0.0.251 + multicast address (or its IPv6 equivalent FF02::FB). Operating in a + Zeroconf environment requires constant vigilance. Just because a name + has been previously verified unique does not mean it will continue to + be so indefinitely. By allowing all Multicast DNS Responders to + constantly monitor their peers' responses, conflicts arising out of + network topology changes can be promptly detected and resolved. + + +Expires 14th August 2004 Cheshire & Krochmal [Page 15] + +Internet Draft Multicast DNS 14th February 2004 + + + Sending all responses by multicast also facilitates opportunistic + caching by other hosts on the network. + + To protect the network against excessive packet flooding due to + software bugs or malicious attack, a Multicast DNS Responder MUST NOT + multicast a given record on a given interface if it has previously + multicast that record on that interface within the last second. A + legitimate client on the network should have seen the previous + transmission and cached it. A client that did not receive and cache + the previous transmission will retry its request and receive a + subsequent response. Under no circumstances is there any legitimate + reason for a Multicast DNS Responder to multicast a given record more + than once per second on any given interface. + + +8.1 Legacy Unicast Responses + + If the source UDP port in a received Multicast DNS Query is not port + 5353, this indicates that the client originating the query is a + simple client that does not fully implement all of Multicast DNS. In + this case, the Multicast DNS Responder MUST send a UDP response + directly back to the client, via unicast, to the query packet's + source IP address and port. This unicast response MUST be a + conventional unicast response as would be generated by a conventional + unicast DNS server; for example, it must repeat the query ID and the + question given in the query packet. + + The resource record TTL given in a unicast response SHOULD NOT be + greater than ten seconds, even if the true TTL of the Multicast DNS + resource record is higher. This is because Multicast DNS Responders + that fully participate in the protocol use the cache coherency + mechanisms described in Section 13 to update and invalidate stale + data. Were unicast responses sent to legacy clients to use the same + high TTLs, these legacy clients, which do not implement these cache + coherency mechanisms, could retain stale cached resource record data + long after it is no longer valid. + + Having sent this unicast response, if the Responder has not sent this + record in any multicast response recently, it SHOULD schedule the + record to be sent via multicast as well, to facilitate passive + conflict detection. "Recently" in this context means "if the time + since the record was last sent via multicast is less than one quarter + of the record's TTL". + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 16] + +Internet Draft Multicast DNS 14th February 2004 + + +8.2 Multi-Question Queries + + Multicast DNS Responders MUST correctly handle DNS query packets + containing more than one question, by answering any or all of the + questions to which they have answers. Any answers generated + in response to query packets containing more than one question + MUST be randomly delayed in the range 20-120ms, as described above. + + +8.3 Response Aggregation + + Having delayed one or more multicast responses by 20-120ms as + described above in Section 8 "Responding", a Multicast DNS Responder + SHOULD, for the sake of network efficiency, aggregate as many of its + pending responses as possible into a single Multicast DNS response + packet. + + +9. Probing and Announcing on Startup + + Typically a Multicast DNS Responder should have, at the very least, + address records for all of its active interfaces. Creating and + advertising an HINFO record on each interface as well can be useful + to network administrators. + + Whenever a Multicast DNS Responder starts up, wakes up from sleep, + receives an indication of an Ethernet "Link Change" event, or has any + other reason to believe that its network connectivity may have + changed in some relevant way, it MUST perform the two startup steps + below. + + +9.1 Probing + + The first startup step is that for all those resource records that a + Multicast DNS Responder desires to be unique on the local link, it + MUST send a Multicast DNS Query asking for those resource records, to + see if any of them are already in use. The primary example of this is + its address record which maps its unique host name to its unique IP + address. All Probe Queries SHOULD be done using the desired resource + record name and query type T_ANY (255), to elicit answers for all + types of records with that name. This allows a single question to be + used in place of several questions, which is more efficient on the + network. It also allows a host to verify exclusive ownership of a + name, which is desirable in most cases. It would be confusing, for + example, if one host owned the "A" record for "myhost.local.", but a + different host owned the HINFO record for that name. + + The ability to place more than one question in a Multicast DNS Query + is useful here, because it can allow a host to use a single packet + for all of its resource records instead of needing a separate packet + + +Expires 14th August 2004 Cheshire & Krochmal [Page 17] + +Internet Draft Multicast DNS 14th February 2004 + + + for each. For example, a host can simultaneously probe for uniqueness + of its "A" record and all its SRV records [DNS-SD] in the same query + packet. + + When ready to send its mDNS probe packet(s) the host should first + wait for a short random delay time, uniformly distributed in the + range 0-250ms. This random delay is to guard against the case where a + group of devices are powered on simultaneously, or a group of devices + are connected to an Ethernet hub which is then powered on, or some + other external event happens that might cause a group of hosts to all + send synchronized probes. + + 250ms after the first query the host should send a second, then + 250ms after that a third. If, by 250ms after the third probe, no + conflicting Multicast DNS responses have been received, the host may + move to the next step, announcing. + + If any conflicting Multicast DNS responses are received, then the + probing host MUST defer to the existing host, and must choose new + names for some or all of its resource records as appropriate, to + avoid conflict with pre-existing hosts on the network. In the case + of a host probing using query type T_ANY as recommended above, any + answer containing a record with that name, of any type, MUST be + considered a conflicting response and handled accordingly. + + If ten failures occur within any ten-second period, then the host + MUST wait at least five seconds before each successive additional + probe attempt. This is to help ensure that in the event of software + bugs or other unanticipated problems, errant hosts do not flood the + network with a continuous stream of multicast traffic. For very + simple devices, a valid way to comply with this requirement is to + always wait five seconds after any failed probe attempt. + + +9.2 Simultaneous Probe Tie-Breaking + + The astute reader will observe that there is a race condition + inherent in the previous description. If two hosts are probing for + the same name simultaneously, neither will receive any response to + the probe, and the hosts could incorrectly conclude that they may + both proceed to use the name. To break this symmetry, each host + populates the Authority Section of its queries with records giving + the rdata that it would be proposing to use, should its probing be + successful. The Authority Section is being used here in a way + analogous to the Update section of a DNS Update packet [RFC 2136]. + + When a host that is probing for a record sees another host issue a + query for the same record, it consults the Authority Section of that + query. If it finds any resource record there which answers the query, + then it compares the data of that resource record with its own + tentative data. The lexicographically later data wins. This means + + +Expires 14th August 2004 Cheshire & Krochmal [Page 18] + +Internet Draft Multicast DNS 14th February 2004 + + + that if the host finds that its own data is lexicographically later, + it simply ignores the other host's probe. If the host finds that its + own data is lexicographically earlier, then it treats this exactly + as if it had received a positive answer to its query, and concludes + that it may not use the desired name. + + The determination of 'lexicographically later' is performed by first + comparing the record class, then the record type, then raw comparison + of the binary content of the rdata without regard for meaning or + structure. If the record classes differ, then the numerically greater + class is considered 'lexicographically later'. Otherwise, if the + record types differ, then the numerically greater type is considered + 'lexicographically later'. If the type and class both match then the + rdata is compared. + + In the case of resource records containing rdata that is subject to + name compression, the names must be uncompressed before comparison. + (The details of how a particular name is compressed is an artifact of + how and where the record is written into the DNS message; it is not + an intrinsic property of the resource record itself.) + + The bytes of the raw uncompressed rdata are compared in turn, + interpreting the bytes as eight-bit UNSIGNED values, until a byte + is found whose value is greater than that of its counterpart (in + which case the rdata whose byte has the greater value is deemed + lexicographically later) or one of the resource records runs out + of rdata (in which case the resource record which still has + remaining data first is deemed lexicographically later). + + The following is an example of a conflict: + + sctibook.local. A 196.254.100.200 + sctibook.local. A 196.254.200.100 + + In this case 196.254.200.100 is lexicographically later, so it is + deemed the winner. + + Note that it is vital that the bytes are interpreted as UNSIGNED + values, or the wrong outcome may result. In the example above, if + the byte with value 200 had been incorrectly interpreted as a + signed value then it would be interpreted as value -56, and the + wrong address record would be deemed the winner. + + +9.3 Announcing + + The second startup step is that the Multicast DNS Responder MUST send + a gratuitous Multicast DNS Response containing, in the Answer + Section, all of its resource records. If there are too many resource + records to fit in a single packet, multiple packets should be used. + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 19] + +Internet Draft Multicast DNS 14th February 2004 + + + In the case of shared records (e.g. the PTR records used by DNS + Service Discovery [DNS-SD]), the records are simply placed as-is + into the answer section of the DNS Response. + + In the case of records that have been verified to be unique in the + previous step, they are placed into the answer section of the DNS + Response with the most significant bit of the rrclass set to one. The + most significant bit of the rrclass is the mDNS "cache flush" bit and + is discussed in more detail below in Section 13.3 "Announcements to + Flush Outdated Cache Entries". + + The Multicast DNS Responder MUST send at least two gratuitous + responses, one second apart. A Responder MAY send up to ten + gratuitous Responses, providing that the interval between gratuitous + responses doubles with every response sent. + + A Multicast DNS Responder SHOULD NOT continue sending gratuitous + Responses for longer than the TTL of the record. The purpose of + announcing new records via gratuitous Responses is to ensure that + peer caches are up to date. After a time interval equal to the TTL of + the record has passed, it is very likely that old stale copies of + that record in peer caches will have expired naturally, so subsequent + announcements serve little purpose. + + Whenever a Multicast DNS Responder receives any Multicast DNS + response (gratuitous or otherwise) containing a conflicting resource + record, the conflict MUST be resolved as described below in "Conflict + Resolution". + + A Multicast DNS Responder MUST NOT send announcements in the absence + of information that its network connectivity may have changed in some + relevant way. In particular, a Multicast DNS Responder MUST NOT send + regular periodic announcements as a matter of course. + + +9.4 Updating + + At any time, if the rdata of any of a host's Multicast DNS records + changes, the host MUST repeat the Announcing step described above to + update neighbouring caches. For example, if any of a host's IP + addresses change, it must re-announce those address records. + + A host may update the contents of any of its records at any time, + though a host SHOULD NOT update records more frequently than ten + times per minute. Frequent rapid updates impose a burden on the + network. If a host has information to disseminate which changes more + frequently than ten times per minute, then Multicast DNS may not be + the appropriate protocol to disseminate that information. + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 20] + +Internet Draft Multicast DNS 14th February 2004 + + +10. Conflict Resolution + + A conflict occurs when two resource records with the same name, type + and class have inconsistent rdata. What may be considered + inconsistent is context sensitive, except that resource records with + identical rdata are never considered inconsistent, even if they + originate from different hosts. A common example of a resource record + type that is intended to be unique, not shared between hosts, is the + address record that maps a host's name to its IP address. Should a + host witness another host announce an address record with the same + name but a different IP address, then that is considered + inconsistent, and that address record is considered to be in + conflict. + + Whenever a Multicast DNS Responder receives any Multicast DNS + response (gratuitous or otherwise) containing a conflicting resource + record, the Multicast DNS Responder MUST immediately reset that + record to probing state, and go through the startup steps described + above in Section 9. "Probing and Announcing on Startup". The + protocol used in the Probing phase will determine a winner and a + loser, and the loser must cease using the name, and reconfigure. + + It is very important that any host that observes an apparent conflict + MUST take action. In the case of two hosts using the same host name, + where one has been configured to require a unique host name and the + other has not, the one that has not been configured to require a + unique host name will not perceive any conflict, and will not take + any action. By reverting to Probing state, the host that desires a + unique host name will go through the necessary steps to ensure that a + unique host is obtained. + + + + + + + + + + + + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 21] + +Internet Draft Multicast DNS 14th February 2004 + + + The recommended course of action after probing and failing is as + follows: + + o Programmatically change the resource record name in an attempt to + find a new name that is unique. This could be done by adding some + further identifying information (e.g. the model name of the + hardware) if it is not already present in the name, appending the + digit "2" to the name, or incrementing a number at the end of the + name if one is already present. + + o Probe again, and repeat until a unique name is found. + + o Record this newly chosen name in persistent storage so that the + device will use the same name the next time it is power-cycled. + + o Display a message to the user or operator informing them of the + name change. For example: + + The name "Bob's Music" is in use by another iTunes music + server on the network. Your music has been renamed to + "Bob's Music (G4 Cube)". If you want to change this name, + use [describe appropriate menu item or preference dialog]. + + How the user or operator is informed depends on context. A desktop + computer with a screen might put up a dialog box. A headless server + in the closet may write a message to a log file, or use whatever + mechanism (email, SNMP trap, etc.) it uses to inform the + administrator of other error conditions. On the other hand a headless + server in the closet may not inform the user at all -- if the user + cares, they will notice the name has changed, and connect to the + server in the usual way (e.g. via Web Browser) to configure a new + name. + + The examples in this section focus on address records (i.e. host + names), but the same considerations apply to all resource records + where uniqueness (or maintenance of some other defined constraint) is + desired. + + + + + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 22] + +Internet Draft Multicast DNS 14th February 2004 + + +11. Special Characteristics of Multicast DNS Domains + + Unlike conventional DNS names, names that end in ".local.", + "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local + significance. Conventional DNS seeks to provide a single unified + namespace, where a given DNS query yields the same answer no matter + where on the planet it is performed or to which recursive DNS server + the query is sent. (However, split views, firewalls, intranets and + the like have somewhat interfered with this goal of DNS representing + a single universal truth.) In contrast, each IP link has its own + private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa." + namespaces, and the answer to any query for a name within those + domains depends on where that query is asked. + + Multicast DNS Domains are not delegated from their parent domain via + use of NS records. There are no NS records anywhere in Multicast DNS + Domains. Instead, all Multicast DNS Domains are delegated to the IP + addresses 224.0.0.251 and FF02::FB by virtue of the individual + organizations producing DNS client software deciding how to handle + those names. It would be extremely valuable for the industry if this + special handling were ratified and recorded by IANA, since otherwise + the special handling provided by each vendor is likely to be + inconsistent. + + The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The + IPv6 name server for a Multicast DNS Domain is FF02::FB. These are + multicast addresses; therefore they identify not a single host but a + collection of hosts, working in cooperation to maintain some + reasonable facsimile of a competently managed DNS zone. Conceptually + a Multicast DNS Domain is a single DNS zone, however its server is + implemented as a distributed process running on a cluster of loosely + cooperating CPUs rather than as a single process running on a single + CPU. + + No delegation is performed within Multicast DNS Domains. Because the + cluster of loosely coordinated CPUs is cooperating to administer a + single zone, delegation is neither necessary nor desirable. Just + because a particular host on the network may answer queries for a + particular record type with the name "example.local." does not imply + anything about whether that host will answer for the name + "child.example.local.", or indeed for other record types with the + name "example.local." + + Multicast DNS Zones have no SOA record. A conventional DNS zone's + SOA record contains information such as the email address of the zone + administrator and the monotonically increasing serial number of the + last zone modification. There is no single human administrator for + any given Multicast DNS Zone, so there is no email address. Because + the hosts managing any given Multicast DNS Zone are only loosely + coordinated, there is no readily available monotonically increasing + serial number to determine whether or not the zone contents have + + +Expires 14th August 2004 Cheshire & Krochmal [Page 23] + +Internet Draft Multicast DNS 14th February 2004 + + + changed. A host holding part of the shared zone could crash or be + disconnected from the network at any time without informing the other + hosts. There is no reliable way to provide a zone serial number that + would, whenever such a crash or disconnection occurred, immediately + change to indicate that the contents of the shared zone had changed. + + Zone transfers are not possible for any Multicast DNS Zone. + + +12. Multicast DNS for Service Discovery + + This document does not describe using Multicast DNS for network + browsing or service discovery. However, the mechanisms this document + describes are compatible with (and support) the browsing and service + discovery mechanisms proposed in "DNS-Based Service Discovery" + [DNS-SD]. + + This document places few limitations on what DNS record types may be + looked up using local multicast. One particular kind of Multicast DNS + query that might be useful is a query for the SRV record named + "_domain._udp.local.", yielding the port number and IP address of a + conventional DNS server willing to perform general recursive DNS + lookups. This could solve a particular problem facing the IPv6 + community, which is that IPv6 is able to self-configure almost all of + the information it needs to operate [RFC 2462], except for the + address of the DNS server. Bringing in all of the mechanisms of DHCP + just for that one little additional piece of information is not an + attractive solution. Using DNS-format messages and DNS-format + resource records to find the address of the DNS server has an elegant + self-sufficiency about it. Any host that needs to know the address of + the DNS server must already have code to generate and parse DNS + packets, so using that same code and those same packets to find the + DNS server in the first place is a simple self-reliant solution that + avoids taking external dependencies on other protocols. + + +13. Resource Record TTL Values and Cache Coherency + + The recommended TTL value for Multicast DNS resource records is + 120 minutes. + + A client with an active outstanding query will issue a query packet + when one or more of the resource record(s) in its cache is (are) 80% + of the way to expiry. If the TTL on those records is 120 minutes, + this ongoing cache maintenance process yields a steady-state query + rate of one query every 96 minutes. + + Any distributed cache needs a cache coherency protocol. If Multicast + DNS resource records follow the recommendation and have a TTL of 120 + minutes, that means that stale data could persist in the system for + up to two hours. Making the default TTL significantly lower would + + +Expires 14th August 2004 Cheshire & Krochmal [Page 24] + +Internet Draft Multicast DNS 14th February 2004 + + + reduce the lifetime of stale data, but would produce too much extra + traffic on the network. Various techniques are available to minimize + the impact of such stale data. + + +13.1 Cooperating Multicast DNS Responders + + If a Multicast DNS Responder ("A") observes some other Multicast DNS + Responder ("B") send a Multicast DNS Response packet containing a + resource record with the same name type and class as one of A's + resource records, but different rdata, then: + + o If A's resource record is intended to be a shared resource record, + then this is no conflict, and no action is required. + + o If A's resource record is intended to be a unique resource record + then this is a conflict and MUST be handled as described in Section + 10 "Conflict Resolution". + + If a Multicast DNS Responder ("A") observes some other Multicast DNS + Responder ("B") send a Multicast DNS Response packet containing a + resource record with the same name type and class as one of A's + resource records, and identical rdata, then: + + o If the TTL of B's resource record given in the packet is at least + half the true TTL from A's point of view, then no action is + required. + + o If the TTL of B's resource record given in the packet is less than + half the true TTL from A's point of view, then A MUST mark its + record to be announced via multicast. Clients receiving the record + from B would use the TTL given by B, and hence may delete the + record sooner than A expects. By sending its own multicast response + correcting the TTL, A ensures that the record will be retained for + the desired time. + + These rules allow multiple Multicast DNS Responders to offer the same + data on the network (perhaps for fault tolerance reasons) without + conflicting with each other. + + +13.2 Goodbye Packets + + In the case where a host knows that certain resource record data is + about to become invalid (for example when the host is undergoing a + clean shutdown) the host SHOULD send a gratuitous announcement mDNS + response packet, giving the same resource record name, type, class + and rdata, but an RR TTL of zero. This has the effect of updating the + TTL stored in neighbouring hosts' cache entries to zero, causing that + cache entry to be promptly deleted. + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 25] + +Internet Draft Multicast DNS 14th February 2004 + + + Clients receiving a Multicast DNS Response with a TTL of zero SHOULD + NOT immediately delete the record from the cache, but instead record + a TTL of 1 and then delete the record one second later. In the case + of multiple Multicast DNS Responders on the network described in + Section 13.1 above, if one of the Responders shuts down and + incorrectly sends goodbye packets for its records, it gives the other + cooperating Responders one second to send out their own response to + "rescue" the records before they expire and are deleted. + + Generally speaking, it is more important to send goodbye packets for + shared records than unique records. A given shared record name (such + as a PTR record used for DNS Service Discovery [DNS-SD]) by its + nature often has many representatives from many different hosts, and + tends to be the subject of long-lived ongoing queries. Those + long-lived queries are often concerned not just about being informed + when records appear, but also about being informed if those records + vanish again. In contrast, a unique record set (such as an SRV + record, or a host address record), by its nature, often has far fewer + members than a shared record set, and is usually the subject of + one-shot queries which simply retrieve the data and then cease + querying once they have the answer they are seeking. Therefore, + sending a goodbye packet for a unique record set is likely to offer + less benefit, because it is likely at any given moment that no one + has an active query running for that record set. One example where + goodbye packets for SRV and address records are useful is when + transferring control to a Sleep Proxy Server (see Section 16. + "Multicast DNS and Power Management"). + + +13.3 Announcements to Flush Outdated Cache Entries + + Whenever a host has a resource record with potentially new data (e.g. + after rebooting, waking from sleep, connecting to a new network link, + changing IP address, etc.), the host MUST send a series of gratuitous + announcements to update cache entries in its neighbour hosts. In + these gratuitous announcements, if the record is one that is intended + to be unique, the host sets the most significant bit of the rrclass + field of the resource record. This bit, the "cache flush" bit, tells + neighbouring hosts that this is not a shared record type. Instead of + merging this new record additively into the cache in addition to any + previous records with the same name, type and class, all old records + with that name, type and class that were received more than one + second ago are declared invalid, and marked to expire from the cache + in one second. + + The semantics of the cache flush bit are as follows: Normally when a + resource record appears in the answer section of the DNS Response, it + means, "This is an assertion that this information is true." When a + resource record appears in the answer section of the DNS Response + with the "cache flush" bit set, it means, "This is an assertion that + this information is the truth and the whole truth, and anything you + + +Expires 14th August 2004 Cheshire & Krochmal [Page 26] + +Internet Draft Multicast DNS 14th February 2004 + + + may have heard more than a second ago regarding records of this + name/type/class is no longer valid". + + To accommodate the case where the set of records from one host + constituting a single unique RRSet is too large to fit in a single + packet, only cache records that are more than one second old are + flushed. This allows the announcing host to generate a quick burst of + packets back-to-back on the wire containing all the members + of the RRSet. When receiving records with the "cache flush" bit set, + all records older than one second are marked to be deleted one second + in the future. One second after the end of the little packet burst, + any records not represented within that packet burst will then be + expired from all peer caches. + + Any time a host sends a response packet containing some members of a + unique RRSet, it SHOULD send the entire RRSet, preferably in a single + packet, or if the entire RRSet will not fit in a single packet, in a + quick burst of packets sent as close together as possible. The host + SHOULD set the cache flush bit on all members of the unique RRSet. + In the event that for some reason the host chooses not to send the + entire unique RRSet in a single packet or a rapid packet burst, + it MUST NOT set the cache flush bit on any of those records. + + The reason for waiting one second before deleting stale records from + the cache is to accommodate bridged networks. For example, a host's + address record announcement on a wireless interface may be bridged + onto a wired Ethernet, and cause that same host's Ethernet address + records to be flushed from peer caches. The one-second delay gives + the host the chance to see its own announcement arrive on the wired + Ethernet, and immediately re-announce its Ethernet address records + so that both sets remain valid and live in peer caches. + + These rules apply regardless of *why* the response packet is being + generated. They apply to startup announcements as described in + Section 9.3, and to responses generated as a result of receiving + query packets. + + The "cache flush" bit is only set in Multicast DNS responses sent to + UDP port 5353. The "cache flush" bit MUST NOT be set in any resource + records in a response packet sent in legacy unicast responses to UDP + ports other than 5353. + + The "cache flush" bit MUST NOT be set in any resource records in the + known-answer list of any query packet. + + The "cache flush" bit MUST NOT ever be set in any shared resource + record. To do so would cause all the other shared versions of this + resource record with different rdata from different Responders to be + immediately deleted from all the caches on the network. + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 27] + +Internet Draft Multicast DNS 14th February 2004 + + + Note that the "cache flush" bit is NOT part of the resource record + class. The "cache flush" bit is the most significant bit of the + second 16-bit word of a resource record in an mDNS packet (the field + conventionally referred to as the rrclass field), and the actual + resource record class is the least-significant fifteen bits of this + field. There is no mDNS resource record class 0x8001. The value + 0x8001 in the rrclass field of a resource record in an mDNS response + packet indicates a resource record with class 1, with the "cache + flush" bit set. When receiving a resource record with the "cache + flush" bit set, implementations should take care to mask off that bit + before storing the resource record in memory. + + +13.4 Cache Flush on Topology change + + If the hardware on a given host is able to indicate physical changes + of connectivity, then when the hardware indicates such a change, the + host should take this information into account in its mDNS cache + management strategy. For example, a host may choose to immediately + flush all cache records received on a particular interface when that + cable is disconnected. Alternatively, a host may choose to adjust the + remaining TTL on all those records to a few seconds so that if the + cable is not reconnected quickly, those records will expire from the + cache. + + Likewise, when a host reboots, or wakes from sleep, or undergoes some + other similar discontinuous state change, the cache management + strategy should take that information into account. + + +13.5 Cache Flush on Failure Indication + + Sometimes a cache record can be determined to be stale when a client + attempts to use the rdata it contains, and finds that rdata to be + incorrect. + + For example, the rdata in an address record can be determined to be + incorrect if attempts to contact that host fail, either because + ARP/ND requests for that address go unanswered (for an address on a + local subnet) or because a router returns an ICMP "Host Unreachable" + error (for an address on a remote subnet). + + The rdata in an SRV record can be determined to be incorrect if + attempts to communicate with the indicated service at the host and + port number indicated are not successful. + + The rdata in a DNS-SD PTR record can be determined to be incorrect if + attempts to look up the SRV record it references are not successful. + + In any such case, the software implementing the mDNS resource record + cache should provide a mechanism so that clients detecting stale + rdata can inform the cache. + +Expires 14th August 2004 Cheshire & Krochmal [Page 28] + +Internet Draft Multicast DNS 14th February 2004 + + + When the cache receives this hint that it should reconfirm some + record, it MUST issue two or more queries for the resource record in + question. If no response is received in a reasonable amount of time, + then, even though its TTL may indicate that it is not yet due to + expire, that record SHOULD be promptly flushed from the cache. + + The end result of this is that if a printer suffers a sudden power + failure or other abrupt disconnection from the network, its name may + continue to appear in DNS-SD browser lists displayed on users' + screens. Eventually that entry will expire from the cache naturally, + but if a user tries to access the printer before that happens, the + failure to successfully contact the printer will trigger the more + hasty demise of its cache entries. This is a sensible trade-off + between good user-experience and good network efficiency. If we were + to insist that printers should disappear from the printer list within + 30 seconds of becoming unavailable, for all failure modes, the only + way to achieve this would be for the client to poll the printer at + least every 30 seconds, or for the printer to announce its presence + at least every 30 seconds, both of which would be an unreasonable + burden on most networks. + + +13.6 Passive Observation of Failures + + A host observes the multicast queries issued by the other hosts on + the network. One of the major benefits of also sending responses + using multicast is that it allows all hosts to see the responses (or + lack thereof) to those queries. + + If a host sees queries, for which a record in its cache would be + expected to be given as an answer in a multicast response, but no + such answer is seen, then the host may take this as an indication + that the record may no longer be valid. + + After seeing two or more of these queries, and seeing no multicast + response containing the expected answer within a reasonable amount of + time, then even though its TTL may indicate that it is not yet due to + expire, that record MAY be flushed from the cache. The host SHOULD + NOT perform its own queries to re-confirm that the record is truly + gone. If every host on a large network were to do this, it would + cause a lot of unnecessary multicast traffic. If host A sends + multicast queries that remain unanswered, then there is no reason to + suppose that host B or any other host is likely to be any more + successful. + + The previous section, "Cache Flush on Failure Indication", describes + a situation where a user trying to print discovers that the printer + is no longer available. By implementing the passive observation + described here, when one user fails to contact the printer, all hosts + on the network observe that failure and update their caches + accordingly. + + +Expires 14th August 2004 Cheshire & Krochmal [Page 29] + +Internet Draft Multicast DNS 14th February 2004 + + +14. Enabling and Disabling Multicast DNS + + The option to fail-over to Multicast DNS for names not ending in + ".local." SHOULD be a user-configured option, and SHOULD + be disabled by default because of the possible security issues + related to unintended local resolution of apparently global names. + + The option to lookup unqualified (relative) names by appending + ".local." (or not) is controlled by whether ".local." appears + (or not) in the client's DNS search list. + + No special control is needed for enabling and disabling Multicast DNS + for names explicitly ending with ".local." as entered by the user. + The user doesn't need a way to disable Multicast DNS for names ending + with ".local.", because if the user doesn't want to use Multicast + DNS, they can achieve this by simply not using those names. If a user + *does* enter a name ending in ".local.", then we can safely assume + the user's intention was probably that it should work. Having user + configuration options that can be (intentionally or unintentionally) + set so that local names don't work is just one more way of + frustrating the user's ability to perform the tasks they want, + perpetuating the view that, "IP networking is too complicated to + configure and too hard to use." This in turn perpetuates the + continued use of protocols like AppleTalk. If we want to retire + AppleTalk, NetBIOS, etc., we need to offer users equivalent IP + functionality that they can rely on to, "always work, like + AppleTalk." A little Multicast DNS traffic may be a burden on the + network, but it is an insignificant burden compared to continued + widespread use of AppleTalk. + + +15. Considerations for Multiple Interfaces + + A host should defend its host name (FQDN) on all active interfaces on + which it is answering Multicast DNS queries. + + In the event of a name conflict on *any* interface, a host should + configure a new host name, if it wishes to maintain uniqueness of its + host name. + + When answering a Multicast DNS query, a multi-homed host with a + link-local address (or addresses) should take care to ensure that + any address going out in a Multicast DNS response is valid for use + on the interface on which the response is going out. + + Just as the same link-local IP address may validly be in use + simultaneously on different links by different hosts, the same + link-local host name may validly be in use simultaneously on + different links, and this is not an error. A multi-homed host with + connections to two different links may be able to communicate with + two different hosts that are validly using the same name. While this + + +Expires 14th August 2004 Cheshire & Krochmal [Page 30] + +Internet Draft Multicast DNS 14th February 2004 + + + kind of name duplication should be rare, it means that a host that + wants to fully support this case needs network programming APIs that + allow applications to specify on what interface to perform a + link-local Multicast DNS query, and to discover on what interface a + Multicast DNS response was received. + + +16. Multicast DNS and Power Management + + Many modern network devices have the ability to go into a low-power + mode where only a small part of the Ethernet hardware remains + powered, and the device can be woken up by sending a specially + formatted Ethernet frame which the device's power-management hardware + recognizes. + + To make use of this in conjunction with Multicast DNS, the device + first uses DNS-SD to determine if Sleep Proxy Service is available on + the local network. In some networks there may be more than one piece + of hardware implementing Sleep Proxy Service, for fault-tolerance + reasons. + + If the device finds the network has Sleep Proxy Service, the device + transmits two or more gratuitous mDNS announcements setting the TTL + of its relevant resource records to zero, to delete them from + neighbouring caches. The relevant resource records include address + records and SRV records, and other resource records as may apply to a + particular device. The device then communicates all of its remaining + active records, plus the names, types and classes of the deleted + records, to the Sleep Proxy Service(s), along with a copy of the + specific "magic packet" required to wake the device up. + + When a Sleep Proxy Service sees an mDNS query for one of the + device's active records (e.g. a DNS-SD PTR record), it answers on + behalf of the device without waking it up. When a Sleep Proxy Service + sees an mDNS query for one of the device's deleted resource + records, it deduces that some client on the network needs to make an + active connection to the device, and sends the specified "magic + packet" to wake the device up. The device then wakes up, reactivates + its deleted resource records, and re-announces them to the network. + The client waiting to connect sees the announcements, learns the + current IP address and port number of the desired service on the + device, and proceeds to connect to it. + + The connecting client does not need to be aware of how Sleep Proxy + Service works. Only devices that implement low power mode and wish to + make use of Sleep Proxy Service need to be aware of how that protocol + works. + + The reason that a device using a Sleep Proxy Service should send more + than one goodbye packet is that the wakeup message is caused by the + Sleep Proxy Service seeing queries for the device's SRV and/or + address records, and those queries are in turn caused by the records + +Expires 14th August 2004 Cheshire & Krochmal [Page 31] + +Internet Draft Multicast DNS 14th February 2004 + + + being absent from peer caches. If the records are not deleted from + peer caches, then those peers may use the cached value directly + without querying, and no wakeup message would be generated. + + The full specification of mDNS / DNS-SD Sleep Proxy Service + is described in another document [not yet published]. + + +17. Multicast DNS Character Set + + Unicast DNS has been plagued by the lack of any support for non-US + characters. Indeed, conventional DNS is usually limited to just + letters, digits and hyphens, with no spaces or other punctuation. + Attempts to remedy this have made slow progress because of the need + to accommodate old buggy legacy implementations. + + Multicast DNS is a new protocol and doesn't (yet) have old buggy + legacy implementations to constrain the design choices. Accordingly, + it adopts the obvious simple solution: all names in Multicast DNS are + encoded using UTF-8 [RFC 2279]. For names that are restricted to + letters, digits and hyphens, the UTF-8 encoding is identical to the + US-ASCII encoding, so this is entirely compatible with existing host + names. For characters outside the US-ASCII range, UTF-8 encoding is + used. + + Multicast DNS implementations MUST NOT use any other encodings apart + from UTF-8 (US-ASCII being considered a compatible subset of UTF-8). + + This point bears repeating: There are various baroque representations + of international text being proposed for Unicast DNS. None of these + representations may be used in Multicast DNS packets. Any text being + represented internally in some other representation MUST be converted + to canonical UTF-8 before being placed in any Multicast DNS packet. + + The simple rules for case-insensitivity in Unicast DNS also apply in + Multicast DNS; that is to say, in name comparisons, the lower-case + letters "a" to "z" match their upper-case equivalents "A" to "Z". + Hence, if a client issues a query for an address record with the name + "stuartcheshire.local", then a responder having an address record + with the name "StuartCheshire.local" should issue a response. + + No other automatic character equivalence is defined in Multicast DNS. + For example, accented characters are not defined to be automatically + equivalent to their unaccented counterparts. Where automatic + equivalences are desired, this may be achieved through the use of + programmatically-generated CNAME records. For example, if a responder + has an address record for an accented name Y, and a client issues a + query for a name X, where X is the same as Y with all the accents + removed, then the responder may issue a response containing two + resource records: A CNAME record "X CNAME Y", asserting that the + requested name X (unaccented) is an alias for the true (accented) + name Y, followed by the address record for Y. + +Expires 14th August 2004 Cheshire & Krochmal [Page 32] + +Internet Draft Multicast DNS 14th February 2004 + + +18. Multicast DNS Message Size + + RFC 1035 restricts DNS Messages carried by UDP to no more than 512 + bytes (not counting the IP or UDP headers). For UDP packets carried + over the wide-area Internet in 1987, this was appropriate. For + link-local multicast packets on today's networks, there is no reason + to retain this restriction. Given that the packets are by definition + link-local, there are no Path MTU issues to consider. + + Multicast DNS Messages carried by UDP may be up to the IP MTU of the + physical interface, less the space required for the IP header (20 + bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes). + + In the case of a single mDNS Resource Record which is too large to + fit in a single MTU-sized multicast response packet, a Multicast DNS + Responder SHOULD send the Resource Record alone, in a single IP + datagram, sent using multiple IP fragments. Resource Records this + large SHOULD be avoided, except in the very rare cases where they + really are the appropriate solution to the problem at hand. + Implementers should be aware that many simple devices do not + re-assemble fragmented IP datagrams, so large Resource Records SHOULD + only be used in specialized cases where the implementer knows that + all receivers implement reassembly. + + A Multicast DNS packet larger than the interface MTU, which is sent + using fragments, MUST NOT contain more than one Resource Record. + + Even when fragmentation is used, a Multicast DNS packet, including IP + and UDP headers, MUST NOT exceed 9000 bytes. + + +19. Multicast DNS Message Format + + This section describes specific restrictions on the allowable + values for the header fields of a Multicast DNS message. + +19.1. ID (Query Identifier) + + Multicast DNS clients SHOULD listen for gratuitous responses + issued by hosts booting up (or waking up from sleep or otherwise + joining the network). Since these gratuitous responses may contain a + useful answer to a question for which the client is currently + awaiting an answer, Multicast DNS clients SHOULD examine all received + Multicast DNS response messages for useful answers, without regard to + the contents of the ID field or the question section. In Multicast + DNS, knowing which particular query message (if any) is responsible + for eliciting a particular response message is less interesting than + knowing whether the response message contains useful information. + + Multicast DNS clients MAY cache any or all Multicast DNS response + messages they receive, for possible future use, providing of course + that normal TTL aging is performed on these cashed resource records. + +Expires 14th August 2004 Cheshire & Krochmal [Page 33] + +Internet Draft Multicast DNS 14th February 2004 + + + In multicast query messages, the Query ID SHOULD be set to zero on + transmission. + + In multicast responses, including gratuitous multicast responses, the + Query ID MUST be set to zero on transmission, and MUST be ignored on + reception. + + In unicast response messages generated specifically in response to a + particular (unicast or multicast) query, the Query ID MUST match the + ID from the query message. + + +19.2. QR (Query/Response) Bit + + In query messages, MUST be zero. + + In response messages, MUST be one. + + +19.3. OPCODE + + In both multicast query and multicast response messages, MUST be zero + (only standard queries are currently supported over multicast, unless + other queries are allowed by future IETF Standards Action). + + +19.4. AA (Authoritative Answer) Bit + + In query messages, the Authoritative Answer bit MUST be zero on + transmission, and MUST be ignored on reception. + + In response messages for Multicast Domains, the Authoritative Answer + bit MUST be set to one (not setting this bit implies there's some + other place where "better" information may be found) and MUST be + ignored on reception. + + +19.5. TC (Truncated) Bit + + In query messages, if the TC bit is set, it means that additional + Known Answer records may be following shortly. A responder MAY choose + to record this fact, and wait for those additional Known Answer + records, before deciding whether to respond. If the TC bit is clear, + it means that the querying host has no additional Known Answers. + + In multicast response messages, the TC bit MUST be zero on + transmission, and MUST be ignored on reception. + + In legacy unicast response messages, the TC bit has the same meaning + as in conventional unicast DNS: it means that the response was too + large to fit in a single packet, so the client SHOULD re-issue its + query using TCP in order to receive the larger response. + +Expires 14th August 2004 Cheshire & Krochmal [Page 34] + +Internet Draft Multicast DNS 14th February 2004 + + +19.6. RD (Recursion Desired) Bit + + In both multicast query and multicast response messages, the + Recursion Desired bit SHOULD be zero on transmission, and MUST be + ignored on reception. + + +19.7. RA (Recursion Available) Bit + + In both multicast query and multicast response messages, the + Recursion Available bit MUST be zero on transmission, and MUST be + ignored on reception. + + +19.8. Z (Zero) Bit + + In both query and response messages, the Zero bit MUST be zero on + transmission, and MUST be ignored on reception. + + +19.9. AD (Authentic Data) Bit [RFC 2535] + + In query messages the Authentic Data bit MUST be zero on + transmission, and MUST be ignored on reception. + + In response messages, the Authentic Data bit MAY be set. Resolvers + receiving response messages with the AD bit set MUST NOT trust the AD + bit unless they trust the source of the message and either have a + secure path to it or use DNS transaction security. + + +19.10. CD (Checking Disabled) Bit [RFC 2535] + + In query messages, a resolver willing to do cryptography SHOULD set + the Checking Disabled bit to permit it to impose its own policies. + + In response messages, the Checking Disabled bit MUST be zero on + transmission, and MUST be ignored on reception. + + +19.11. RCODE (Response Code) + + In both multicast query and multicast response messages, the Response + Code MUST be zero on transmission. Multicast DNS messages received + with non-zero Response Codes MUST be silently ignored. + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 35] + +Internet Draft Multicast DNS 14th February 2004 + + +20. Choice of UDP Port Number + + Arguments were made for and against using Multicast on UDP port 53. + The final decision was to use UDP port 5353. Some of the arguments + for and against are given below. + + +20.1 Arguments for using UDP port 53: + + * This is "just DNS", so it should be the same port. + + * There is less work to be done updating old clients to do simple + mDNS queries. Only the destination address need be changed. + In some cases, this can be achieved without any code changes, + just by adding the address 224.0.0.251 to a configuration file. + + +20.2 Arguments for using a different port (UDP port 5353): + + * This is not "just DNS". This is a DNS-like protocol, but different. + + * Changing client code to use a different port number is not hard. + + * Using the same port number makes it hard to run an mDNS Responder + and a conventional unicast DNS server on the same machine. If a + conventional unicast DNS server wishes to implement mDNS as well, + it can still do that, by opening two sockets. Having two different + port numbers is important to allow this flexibility. + + * Some VPN software hijacks all outgoing traffic to port 53 and + redirects it to a special DNS server set up to serve those VPN + clients while they are connected to the corporate network. It is + questionable whether this is the right thing to do, but it is + common, and redirecting link-local multicast DNS packets to a + remote server rarely produces any useful results. It does mean, for + example, that the user becomes unable to access their local network + printer sitting on their desk right next to their computer. Using + a different UDP port eliminates this particular problem. + + * On many operating systems, unprivileged clients may not send or + receive packets on low-numbered ports. This means that any client + sending or receiving mDNS packets on port 53 would have to run as + "root", which is an undesirable security risk. Using a higher- + numbered UDP port eliminates this particular problem. + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 36] + +Internet Draft Multicast DNS 14th February 2004 + + +21. Summary of Differences Between Multicast DNS and Unicast DNS + + The value of Multicast DNS is that it shares, as much as possible, + the familiar APIs, naming syntax, resource record types, etc., of + Unicast DNS. There are of course necessary differences by virtue of + it using Multicast, and by virtue of it operating in a community of + cooperating peers, rather than a precisely defined authoritarian + hierarchy controlled by a strict chain of formal delegations from the + top. These differences are listed below: + + Multicast DNS... + * uses multicast + * uses UDP port 5353 instead of port 53 + * operates in well-defined parts of the DNS namespace + * uses UTF-8, and only UTF-8, to encode resource record names + * defines a clear limit on the maximum legal domain name (255 bytes) + * allows larger UDP packets + * allows more than one question in a query packet + * uses the Answer Section of a query to list Known Answers + * uses the TC bit in a query to indicate additional Known Answers + * uses the Authority Section of a query for probe tie-breaking + * ignores the Query ID field (except for generating legacy responses) + * doesn't require the question to be repeated in the response packet + * uses gratuitous responses to announce new records to the peer group + * defines a "unicast response" bit in the rrclass of query questions + * defines a "cache flush" bit in the rrclass of responses + * uses DNS TTL 0 to indicate that a record has been deleted + * uses IP TTL 255 to verify that answers originated on the local link + * monitors queries to perform Duplicate Question Suppression + * monitors responses to perform Duplicate Answer Suppression... + * ... and Ongoing Conflict Detection + * ... and Opportunistic Caching + + + + + + + + + + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 37] + +Internet Draft Multicast DNS 14th February 2004 + + +22. Benefits of Multicast Responses + + Some people have argued that sending responses via multicast is + inefficient on the network. In fact the benefits of using multicast + responses result in a net lowering of overall multicast traffic, for + a variety of reasons. + + * One multicast response can update the cache on all machines on the + network. If another machine later wants to issue the same query, it + already has the answer in its cache, so it may not need to even + transmit that multicast query on the network at all. + + * When more than one machine has the same ongoing long-lived query + running, every machine does not have to transmit its own + independent query. When one machine transmits a query, all the + other hosts see the answers, so they can suppress their own + queries. + + * When a host sees a multicast query, but does not see the + corresponding multicast response, it can use this information to + promptly delete stale data from its cache. To achieve the same + level of user-interface quality and responsiveness without + multicast responses would require lower cache lifetimes and more + frequent network polling, resulting in a significantly higher + packet rate. + + * Multicast responses allow passive conflict detection. Without this + ability, some other conflict detection mechanism would be needed, + imposing its own additional burden on the network. + + * When using delayed responses to reduce network collisions, clients + need to maintain a list recording to whom each answer should be + sent. The option of multicast responses allows clients with limited + storage, which cannot store an arbitrarily long list of response + addresses, to choose to fail-over to a single multicast response in + place of multiple unicast respones, when appropriate. + + + + + + + + + + + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 38] + +Internet Draft Multicast DNS 14th February 2004 + + +23. IPv6 Considerations + + An IPv4-only host and an IPv6-only host behave as "ships that pass in + the night". Even if they are on the same Ethernet, neither is aware + of the other's traffic. For this reason, each physical link may have + *two* unrelated ".local." zones, one for IPv4 and one for IPv6. + Since for practical purposes, a group of IPv4-only hosts and a group + of IPv6-only hosts on the same Ethernet act as if they were on two + entirely separate Ethernet segments, it is unsurprising that their + use of the ".local." zone should occur exactly as it would if + they really were on two entirely separate Ethernet segments. + + A dual-stack (v4/v6) host can participate in both ".local." + zones, and should register its name(s) and perform its lookups both + using IPv4 and IPv6. This enables it to reach, and be reached by, + both IPv4-only and IPv6-only hosts. In effect this acts like a + multi-homed host, with one connection to the logical "IPv4 Ethernet + segment", and a connection to the logical "IPv6 Ethernet segment". + +23.1 IPv6 Multicast Addresses by Hashing + + Some discovery protocols use a range of multicast addresses, and + determine the address to be used by a hash function of the name being + sought. Queries are sent via multicast to the address as indicated by + the hash function, and responses are returned to the querier via + unicast. Particularly in IPv6, where multicast addresses are + extremely plentiful, this approach is frequently advocated. + + There are some problems with this: + + * When a host has a large number of records with different names, the + host may have to join a large number of multicast groups. This can + place undue burden on the Ethernet hardware, which typically + supports a limited number of multicast addresses efficiently. When + this number is exceeded, the Ethernet hardware may have to resort + to receiving all multicasts and passing them up to the host + software for filtering, thereby defeating the point of using a + multicast address range in the first place. + + * Multiple questions cannot be placed in one packet if they don't all + hash to the same multicast address. + + * Duplicate Question Suppression doesn't work if queriers are not + seeing each other's queries. + + * Duplicate Answer Suppression doesn't work if responders are not + seeing each other's responses. + + * Opportunistic Caching doesn't work. + + * Ongoing Conflict Detection doesn't work. + + +Expires 14th August 2004 Cheshire & Krochmal [Page 39] + +Internet Draft Multicast DNS 14th February 2004 + + +24. Security Considerations + + The algorithm for detecting and resolving name conflicts is, by its + very nature, an algorithm that assumes cooperating participants. Its + purpose is to allow a group of hosts to arrive at a mutually disjoint + set of host names and other DNS resource record names, in the absence + of any central authority to coordinate this or mediate disputes. In + the absence of any higher authority to resolve disputes, the only + alternative is that the participants must work together cooperatively + to arrive at a resolution. + + In an environment where the participants are mutually antagonistic + and unwilling to cooperate, other mechanisms are appropriate, like + manually administered DNS. + + In an environment where there is a group of cooperating participants, + but there may be other antagonistic participants on the same physical + link, the cooperating participants need to use IPSEC signatures + and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS + messages from trusted participants (which they process as usual) from + mDNS messages from untrusted participants (which they silently + discard). + + When DNS queries for *global* DNS names are sent to the mDNS + multicast address (during network outages which disrupt communication + with the greater Internet) it is *especially* important to use + DNSSEC, because the user may have the impression that he or she is + communicating with some authentic host, when in fact he or she is + really communicating with some local host that is merely masquerading + as that name. This is less critical for names ending with ".local.", + because the user should be aware that those names have only local + significance and no global authority is implied. + + Most computer users neglect to type the trailing dot at the end of a + fully qualified domain name, making it a relative domain name (e.g. + "www.example.com"). In the event of network outage, attempts to + positively resolve the name as entered will fail, resulting in + application of the search list, including ".local.", if present. + A malicious host could masquerade as "www.example.com" by answering + the resulting Multicast DNS query for "www.example.com.local." + To avoid this, a host MUST NOT append the search suffix + ".local.", if present, to any relative (partially qualified) + domain name containing two or more labels. Appending ".local." to + single-label relative domain names is acceptable, since the user + should have no expectation that a single-label domain name will + resolve as-is. + + + + + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 40] + +Internet Draft Multicast DNS 14th February 2004 + + +25. IANA Considerations + + The IANA has allocated the IPv4 link-local multicast address + 224.0.0.251 for the use described in this document. + + The IANA has allocated the IPv6 multicast address set FF0X::FB + for the use described in this document. + + When this document is published, IANA should designate a list + of domains which are deemed to have only link-local significance, + as described in this document. + + No other IANA services are required by this document. + + +26. Acknowledgements + + The concepts described in this document have been explored and + developed with help from Erik Guttman, Paul Vixie, Bill Woodcock, + and others. + + +27. Copyright + + Copyright (C) The Internet Society January 2004. + 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 + 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. + + + +Expires 14th August 2004 Cheshire & Krochmal [Page 41] + +Internet Draft Multicast DNS 14th February 2004 + + +28. Normative References + + [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. + + +29. Informative References + + [dotlocal] + + [djbdl] + + [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service + Discovery", Internet-Draft (work in progress), + draft-cheshire-dnsext-dns-sd-02.txt, February 2004. + + [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: + Overview and Architecture. + Institute of Electrical and Electronic Engineers, + IEEE Standard 802, 1990. + + [NBP] Cheshire, S., and M. Krochmal, + "Requirements for a Protocol to Replace AppleTalk NBP", + Internet-Draft (work in progress), + draft-cheshire-dnsext-nbp-03.txt, February 2004. + + [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name + System (DNS UPDATE)", RFC 2136, April 1997. + + [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", + Internet-Draft (work in progress), + draft-ietf-zeroconf-ipv4-linklocal-11.txt, January 2004. + + [ZC] Williams, A., "Requirements for Automatic Configuration + of IP Hosts", Internet-Draft (work in progress), + draft-ietf-zeroconf-reqts-12.txt, September 2002. + +Expires 14th August 2004 Cheshire & Krochmal [Page 42] + +Internet Draft Multicast DNS 14th February 2004 + + +30. Author's 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 14th August 2004 Cheshire & Krochmal [Page 43] \ No newline at end of file diff --git a/specs/draft-cheshire-dnsext-multicastdns-05.txt b/specs/draft-cheshire-dnsext-multicastdns-05.txt new file mode 100644 index 0000000..0e2be99 --- /dev/null +++ b/specs/draft-cheshire-dnsext-multicastdns-05.txt @@ -0,0 +1,2640 @@ +Document: draft-cheshire-dnsext-multicastdns-05.txt Stuart Cheshire +Category: Standards Track Apple Computer, Inc. +Expires 7th December 2005 Marc Krochmal + Apple Computer, Inc. + 7th June 2005 + + Multicast DNS + + + + +Status of this Memo + + By submitting this Internet-Draft, each author represents + that any applicable patent or other IPR claims of which he or she is + aware have been or will be disclosed, and any of which he or she + become aware will be disclosed, in accordance with RFC 3979. + + 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. + + +Abstract + + As networked devices become smaller, more portable, and more + ubiquitous, the ability to operate with less configured + infrastructure is increasingly important. In particular, the ability + to look up DNS resource record data types (including, but not limited + to, host names) in the absence of a conventional managed DNS server, + is becoming essential. + + Multicast DNS (mDNS) provides the ability to do DNS-like operations + on the local link in the absence of any conventional unicast DNS + server. In addition, mDNS designates a portion of the DNS namespace + to be free for local use, without the need to pay any annual fee, and + without the need to set up delegations or otherwise configure a + conventional DNS server to answer for those names. + + The primary benefits of mDNS names are that (i) they require little + or no administration or configuration to set them up, (ii) they work + when no infrastructure is present, and (iii) they work during + infrastructure failures. + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 1] + +Internet Draft Multicast DNS 7th June 2005 + + +Table of Contents + + 1. Introduction...................................................3 + 2. Conventions and Terminology Used in this Document..............4 + 3. Multicast DNS Names............................................5 + 4. Source Address Check...........................................8 + 5. Reverse Address Mapping........................................9 + 6. Querying.......................................................9 + 7. Duplicate Suppression.........................................13 + 8. Responding....................................................15 + 9. Probing and Announcing on Startup.............................18 + 10. Conflict Resolution...........................................22 + 11. Resource Record TTL Values and Cache Coherency................23 + 12. Special Characteristics of Multicast DNS Domains..............28 + 13. Multicast DNS for Service Discovery...........................30 + 14. Enabling and Disabling Multicast DNS..........................30 + 15. Considerations for Multiple Interfaces........................30 + 16. Multicast DNS and Power Management............................31 + 17. Multicast DNS Character Set...................................32 + 18. Multicast DNS Message Size....................................34 + 19. Multicast DNS Message Format..................................34 + 20. Choice of UDP Port Number.....................................37 + 21. Summary of Differences Between Multicast DNS and Unicast DNS..38 + 22. Benefits of Multicast Responses...............................38 + 23. IPv6 Considerations...........................................39 + 24. Security Considerations.......................................40 + 25. IANA Considerations...........................................41 + 26. Acknowledgments...............................................42 + 27. Copyright.....................................................42 + 28. Normative References..........................................42 + 29. Informative References........................................43 + 30. Authors' Addresses............................................44 + + + + + + + + + + + + + + + + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 2] + +Internet Draft Multicast DNS 7th June 2005 + + +1. Introduction + + When reading this document, familiarity with the concepts of Zero + Configuration Networking [ZC] and automatic link-local addressing + [RFC 2462] [RFC 3927] is helpful. + + This document proposes no change to the structure of DNS messages, + and no new operation codes, response codes, or resource record types. + This document simply discusses what needs to happen if DNS clients + start sending DNS queries to a multicast address, and how a + collection of hosts can cooperate to collectively answer those + queries in a useful manner. + + There has been discussion of how much burden Multicast DNS might + impose on a network. It should be remembered that whenever IPv4 hosts + communicate, they broadcast ARP packets on the network on a regular + basis, and this is not disastrous. The approximate amount of + multicast traffic generated by hosts making conventional use of + Multicast DNS is anticipated to be roughly the same order of + magnitude as the amount of broadcast ARP traffic those hosts already + generate. + + New applications making new use of Multicast DNS capabilities for + unconventional purposes may generate more traffic. If some of those + new applications are "chatty", then work will be needed to help them + become less chatty. When performing any analysis, it is important to + make a distinction between the application behavior and the + underlying protocol behavior. If a chatty application uses UDP, that + doesn't mean that UDP is chatty, or that IP is chatty, or that + Ethernet is chatty. What it means is that the application is chatty. + The same applies to any future applications that may decide to layer + increasing portions of their functionality over Multicast DNS. + + + + + + + + + + + + + + + + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 3] + +Internet Draft Multicast DNS 7th June 2005 + + +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]. + + This document uses the term "host name" in the strict sense to mean a + fully qualified domain name that has an address record. It does not + use the term "host name" in the commonly used but incorrect sense to + mean just the first DNS label of a host's fully qualified domain + name. + + A DNS (or mDNS) packet contains an IP TTL in the IP header, which + is effectively a hop-count limit for the packet, to guard against + routing loops. Each Resource Record also contains a TTL, which is + the number of seconds for which the Resource Record may be cached. + + In any place where there may be potential confusion between these two + types of TTL, the term "IP TTL" is used to refer to the IP header TTL + (hop limit), and the term "RR TTL" is used to refer to the Resource + Record TTL (cache lifetime). + + When this document uses the term "Multicast DNS", it should be taken + to mean: "Clients performing DNS-like queries for DNS-like resource + records by sending DNS-like UDP query and response packets over IP + Multicast to UDP port 5353." + + This document uses the terms "shared" and "unique" when referring to + resource record sets. + + A "shared" resource record set is one where several Multicast DNS + responders may have records with that name, rrtype, and rrclass, and + several responders may respond to a particular query. + + A "unique" resource record set is one where all the records with that + name, rrtype, and rrclass are under the control or ownership of a + single responder, and at most one responder should respond to any + given query. Before claiming ownership of a unique resource record + set, a responder MUST probe to verify that no other responder + already claims ownership of that set, as described in Section 9.1 + "Probing". + + Strictly speaking the terms "shared" and "unique" apply to resource + record sets, not to individual resource records, but it is sometimes + convenient to talk of "shared resource records" and "unique resource + records". When used this way, the terms should be understood to mean + a record that is a member of a "shared" or "unique" resource record + set, respectively. + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 4] + +Internet Draft Multicast DNS 7th June 2005 + + +3. Multicast DNS Names + + This document proposes that the DNS top-level domain ".local." be + designated a special domain with special semantics, namely that any + fully-qualified name ending in ".local." is link-local, and names + within this domain are meaningful only on the link where they + originate. This is analogous to IPv4 addresses in the 169.254/16 + prefix, which are link-local and meaningful only on the link where + they originate. + + Any DNS query for a name ending with ".local." MUST be sent + to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent + FF02::FB). + + It is unimportant whether a name ending with ".local." occurred + because the user explicitly typed in a fully qualified domain name + ending in ".local.", or because the user entered an unqualified + domain name and the host software appended the suffix ".local." + because that suffix appears in the user's search list. The ".local." + suffix could appear in the search list because the user manually + configured it, or because it was received in a DHCP option, or via + any other valid mechanism for configuring the DNS search list. In + this respect the ".local." suffix is treated no differently to any + other search domain that might appear in the DNS search list. + + DNS queries for names that do not end with ".local." MAY be sent to + the mDNS multicast address, if no other conventional DNS server is + available. This can allow hosts on the same link to continue + communicating using each other's globally unique DNS names during + network outages which disrupt communication with the greater + Internet. When resolving global names via local multicast, it is even + more important to use DNSSEC or other security mechanisms to ensure + that the response is trustworthy. Resolving global names via local + multicast is a contentious issue, and this document does not discuss + it in detail, instead concentrating on the issue of resolving local + names using DNS packets sent to a multicast address. + + A host which belongs to an organization or individual who has control + over some portion of the DNS namespace can be assigned a globally + unique name within that portion of the DNS namespace, for example, + "cheshire.apple.com." For those of us who have this luxury, this + works very well. However, the majority of home customers do not have + easy access to any portion of the global DNS namespace within which + they have the authority to create names as they wish. This leaves the + majority of home computers effectively anonymous for practical + purposes. + + To remedy this problem, this document allows any computer user to + elect to give their computers link-local Multicast DNS host names of + the form: "single-dns-label.local." For example, a laptop computer + may answer to the name "cheshire.local." Any computer user is granted + the authority to name their computer this way, provided that the + chosen host name is not already in use on that link. Having named + + +Expires 7th December 2005 Cheshire & Krochmal [Page 5] + +Internet Draft Multicast DNS 7th June 2005 + + + their computer this way, the user has the authority to continue using + that name until such time as a name conflict occurs on the link which + is not resolved in the user's favour. If this happens, the computer + (or its human user) SHOULD cease using the name, and may choose to + attempt to allocate a new unique name for use on that link. These + conflicts are expected to be relatively rare for people who choose + reasonably imaginative names, but it is still important to have a + mechanism in place to handle them when they happen. + + The point made in the previous paragraph is very important and bears + repeating. It is easy for those of us in the IETF community who run + our own name servers at home to forget that the majority of computer + users do not run their own name server and have no easy way to create + their own host names. When these users wish to transfer files between + two laptop computers, they are frequently reduced to typing in + dotted-decimal IP addresses because they simply have no other way for + one host to refer to the other by name. This is a sorry state of + affairs. What is worse, most users don't even bother trying to use + dotted-decimal IP addresses. Most users still move data between + machines by copying it onto a floppy disk or similar removable media. + + In a world of gigabit Ethernet and ubiquitous wireless networking it + is a sad indictment of the networking community that the preferred + communication medium for most computer users is still the floppy + disk. + + Allowing ad-hoc allocation of single-label names in a single flat + ".local." namespace may seem to invite chaos. However, operational + experience with AppleTalk NBP names [NBP], which on any given link + are also effectively single-label names in a flat namespace, shows + that in practice name collisions happen extremely rarely and are not + a problem. Groups of computer users from disparate organizations + bring Macintosh laptop computers to events such as IETF Meetings, the + Mac Hack conference, the Apple World Wide Developer Conference, etc., + and complaints at these events about users suffering conflicts and + being forced to rename their machines have never been an issue. + + Enforcing uniqueness of host names (i.e. the names of DNS address + records mapping names to IP addresses) is probably desirable in the + common case, but this document does not mandate that. It is + permissible for a collection of coordinated hosts to agree to + maintain multiple DNS address records with the same name, possibly + for load balancing or fault-tolerance reasons. This document does not + take a position on whether that is sensible. It is important that + both modes of operation are supported. The Multicast DNS protocol + allows hosts to verify and maintain unique names for resource records + where that behavior is desired, and it also allows hosts to maintain + multiple resource records with a single shared name where that + behavior is desired. This consideration applies to all resource + records, not just address records (host names). In summary: It is + required that the protocol have the ability to detect and handle name + conflicts, but it is not required that this ability be used for every + record. + + +Expires 7th December 2005 Cheshire & Krochmal [Page 6] + +Internet Draft Multicast DNS 7th June 2005 + + +3.1 Governing Standards Body + + Note that this use of the ".local." suffix falls under IETF + jurisdiction, not ICANN jurisdiction. DNS is an IETF network + protocol, governed by protocol rules defined by the IETF. These IETF + protocol rules dictate character set, maximum name length, packet + format, etc. ICANN determines additional rules that apply when the + IETF's DNS protocol is used on the public Internet. In contrast, + private uses of the DNS protocol on isolated private networks are not + governed by ICANN. Since this proposed change is a change to the core + DNS protocol rules, it affects everyone, not just those machines + using the ICANN-governed Internet. Hence this change falls into the + category of an IETF protocol rule, not an ICANN usage rule. + +3.2 Private DNS Namespaces + + Note also that the special treatment of names ending in ".local." has + been implemented in Macintosh computers since the days of Mac OS 9, + and continues today in Mac OS X. There are also implementations for + Linux and other platforms [dotlocal]. Operators setting up private + internal networks ("intranets") are advised that their lives may be + easier if they avoid using the suffix ".local." in names in their + private internal DNS server. Alternative possibilities include: + + .intranet + .internal + .private + .corp + .home + + Another alternative naming scheme, advocated by Professor D. J. + Bernstein, is to use a numerical suffix, such as ".6." [djbdl]. + +3.3 Maximum Multicast DNS Name Length + + RFC 1034 says: + + "the total number of octets that represent a domain name (i.e., + the sum of all label octets and label lengths) is limited to 255." + + This text implies that the final root label at the end of every name + is included in this count (a name can't be represented without it), + but the text does not explicitly state that. Implementations of + Multicast DNS MUST include the label length byte of the final root + label at the end of every name when enforcing the rule that no name + may be longer than 255 bytes. For example, the length of the name + "apple.com." is considered to be 11, which is the number of bytes it + takes to represent that name in a packet without using name + compression: + + ------------------------------------------------------ + | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 | + ------------------------------------------------------ + + +Expires 7th December 2005 Cheshire & Krochmal [Page 7] + +Internet Draft Multicast DNS 7th June 2005 + + +4. Source Address Check + + All Multicast DNS responses (including responses sent via unicast) + SHOULD be sent with IP TTL set to 255. This is recommended to provide + backwards-compatibility with older Multicast DNS clients that check + the IP TTL on reception to determine whether the packet originated + on the local link. These older clients discard all packets with TTLs + other than 255. + + A host sending Multicast DNS queries to a link-local destination + address (including the 224.0.0.251 link-local multicast address) + MUST only accept responses to that query that originate from the + local link, and silently discard any other response packets. Without + this check, it could be possible for remote rogue hosts to send + spoof answer packets (perhaps unicast to the victim host) which the + receiving machine could misinterpret as having originated on the + local link. + + The test for whether a response originated on the local link + is done in two ways: + + * All responses sent to the link-local multicast address 224.0.0.251 + are necessarily deemed to have originated on the local link, + regardless of source IP address. This is essential to allow devices + to work correctly and reliably in unusual configurations, such as + multiple logical IP subnets overlayed on a single link, or in cases + of severe misconfiguration, where devices are physically connected + to the same link, but are currently misconfigured with completely + unrelated IP addresses and subnet masks. + + * For responses sent to a unicast destination address, the source IP + address in the packet is checked to see if it is an address on a + local subnet. An address is determined to be on a local subnet if, + for (one of) the address(es) configured on the interface receiving + the packet, (I & M) == (P & M), where I and M are the interface + address and subnet mask respectively, P is the source IP address + from the packet, '&' represents the bitwise logical 'and' + operation, and '==' represents a bitwise equality test. + + Since queriers will ignore responses apparently originating outside + the local subnet, responders SHOULD avoid generating responses that + it can reasonably predict will be ignored. This applies particularly + in the case of overlayed subnets. If a responder receives a query + addressed to the link-local multicast address 224.0.0.251, from a + source address not apparently on the same subnet as the responder, + then even if the query indicates that a unicast response is preferred + (see Section 6.5, "Questions Requesting Unicast Responses"), the + responder SHOULD elect to respond by multicast anyway, since it can + reasonably predict that a unicast response with an apparently + non-local source address will probably be ignored. + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 8] + +Internet Draft Multicast DNS 7th June 2005 + + +5. Reverse Address Mapping + + Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also + defined to be link-local. + + Any DNS query for a name ending with "254.169.in-addr.arpa." MUST + be sent to the mDNS multicast address 224.0.0.251. Since names under + this domain correspond to IPv4 link-local addresses, it is logical + that the local link is the best place to find information pertaining + to those names. As an optimization, these queries MAY be first + unicast directly to the address in question, but if this query is not + answered, the query MUST also be sent via multicast, to accommodate + the case where the machine in question is not answering for itself + (for example, because it is currently sleeping). + + Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa." + MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB, + with or without an optional initial query unicast directly to the + address in question. + + +6. Querying + + There are three kinds of Multicast DNS Queries, one-shot queries of + the kind made by today's conventional DNS clients, one-shot queries + accumulating multiple responses made by multicast-aware DNS clients, + and continuous ongoing Multicast DNS Queries used by IP network + browser software. + + A Multicast DNS Responder that is offering records that are intended + to be unique on the local link MUST also implement a Multicast DNS + Querier so that it can first verify the uniqueness of those records + before it begins answering queries for them. + + +6.1 One-Shot Queries + + An unsophisticated DNS client may simply send its DNS queries + blindly to the 224.0.0.251 multicast address, without necessarily + even being aware what a multicast address is. + + Such an unsophisticated DNS client may not get ideal behavior. Such + a client may simply take the first response it receives and fail to + wait to see if there are more, but in many instances this may not be + a serious problem. If a user types "http://cheshire.local." into + their Web browser and gets to see the page they were hoping for, + then the protocol has met the user's needs in this case. + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 9] + +Internet Draft Multicast DNS 7th June 2005 + + +6.2 One-Shot Queries, Accumulating Multiple Responses + + A more sophisticated DNS client should understand that Multicast DNS + is not exactly the same as unicast DNS, and should modify its + behavior in some simple ways. + + As described above, there are some cases, such as looking up the + address associated with a unique host name, where a single response + is sufficient, and moreover may be all that is expected. However, + there are other DNS queries where more than one response is + possible, and for these queries a more sophisticated Multicast DNS + client should include the ability to wait for an appropriate period + of time to collect multiple responses. + + A naive DNS client retransmits its query only so long as it has + received no response. A more sophisticated Multicast DNS client is + aware that having received one response is not necessarily an + indication that it might not receive others, and has the ability to + retransmit its query an appropriate number of times at appropriate + intervals until it is satisfied with the collection of responses it + has gathered. + + A more sophisticated Multicast DNS client that is retransmitting + a query for which it has already received some responses, MUST + implement Known Answer Suppression, as described below in Section + 7.1. This indicates to responders who have already replied that their + responses have been received, and they don't need to send them again + in response to this repeated query. In addition, the interval between + the first two queries SHOULD be one second, and the intervals between + subsequent queries SHOULD double. + + +6.3 Continuous Querying + + In One-Shot Queries, with either a single or multiple responses, + the underlying assumption is that the transaction begins when the + application issues a query, and ends when all the desired responses + have been received. There is another type of operation which is more + akin to continuous monitoring. + + Macintosh users are accustomed to opening the "Chooser" window, + selecting a desired printer, and then closing the Chooser window. + However, when the desired printer does not appear in the list, the + user will typically leave the "Chooser" window open while they go and + check to verify that the printer is plugged in, powered on, connected + to the Ethernet, etc. While the user jiggles the wires, hits the + Ethernet hub, and so forth, they keep an eye on the Chooser window, + and when the printer name appears, they know they have fixed whatever + the problem was. This can be a useful and intuitive troubleshooting + technique, but a user who goes home for the weekend leaving the + Chooser window open places a non-trivial burden on the network. + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 10] + +Internet Draft Multicast DNS 7th June 2005 + + + With continuous querying, multiple queries are sent over a long + period of time, until the user terminates the operation. It is + important that an IP network browser window displaying live + information from the network using Multicast DNS, if left running + for an extended period of time, should generate significantly less + multicast traffic on the network than the old AppleTalk Chooser. + Therefore, the interval between the first two queries SHOULD be one + second, the intervals between subsequent queries SHOULD double, and + the querier MUST implement Known Answer Suppression, as described + below in Section 7.1. When the interval between queries reaches or + exceeds 60 minutes, a querier MAY cap the interval to a maximum of 60 + minutes, and perform subsequent queries at a steady-state rate of one + query per hour. + + When a Multicast DNS Querier receives an answer, the answer contains + a TTL value that indicates for how many seconds this answer is valid. + After this interval has passed, the answer will no longer be valid + and SHOULD be deleted from the cache. Before this time is reached, a + Multicast DNS Querier with an ongoing interest in that record SHOULD + re-issue its query to determine whether the record is still valid, + and if so update its expiry time. + + To perform this cache maintenance, a Multicast DNS Querier should + plan to re-query for records after at least 50% of the record + lifetime has elapsed. This document recommends the following + specific strategy: + + The Querier should plan to issue a query at 80% of the record + lifetime, and then if no answer is received, at 85%, 90% and 95%. If + an answer is received, then the remaining TTL is reset to the value + given in the answer, and this process repeats for as long as the + Multicast DNS Querier has an ongoing interest in the record. If after + four queries no answer is received, the record is deleted when it + reaches 100% of its lifetime. + + To avoid the case where multiple Multicast DNS Queriers on a network + all issue their queries simultaneously, a random variation of 2% of + the record TTL should be added, so that queries are scheduled to be + performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL. + + +6.4 Multiple Questions per Query + + Multicast DNS allows a querier to place multiple questions in the + Question Section of a single Multicast DNS query packet. + + The semantics of a Multicast DNS query packet containing multiple + questions is identical to a series of individual DNS query packets + containing one question each. Combining multiple questions into a + single packet is purely an efficiency optimization, and has no other + semantic significance. + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 11] + +Internet Draft Multicast DNS 7th June 2005 + + + A useful technique for adaptively combining multiple questions into a + single query is to use a Nagle-style algorithm: When a client issues + its first question, a Query packet is immediately built and sent, + without delay. If the client then continues issuing a rapid series of + questions they are held until either the first query receives at + least one answer, or 100ms has passed, or there are enough questions + to fill the Question Section of a Multicast DNS query packet. At this + time, all the held questions are placed into a Multicast DNS query + packet and sent. + +6.5 Questions Requesting Unicast Responses + + Sending Multicast DNS responses via multicast has the benefit that + all the other hosts on the network get to see those responses, and + can keep their caches up to date, and detect conflicting responses. + + However, there are situations where all the other hosts on the + network don't need to see every response. One example is a laptop + computer waking from sleep. At that instant it is a brand new + participant on a new network. Its Multicast DNS cache is empty, and + it has no knowledge of its surroundings. It may have a significant + number of queries that it wants answered right away to discover + information about its new surroundings and present that information + to the user. As a new participant on the network, it has no idea + whether the exact same questions may have been asked and answered + just seconds ago. In this case, trigging a large sudden flood of + multicast responses may impose an unreasonable burden on the network. + To avoid this, the Multicast DNS Querier SHOULD set the top bit in + the class field of its DNS question(s), to indicate that it is + willing to accept unicast responses instead of the usual multicast + responses. These questions requesting unicast responses are referred + to as "QU" questions, to distinguish them from the more usual + questions requesting multicast responses ("QM" questions). + + When retransmitting a question more than once, the 'unicast response' + bit SHOULD be set only for the first question of the series. After + the first question has received its responses, the querier should + have a large known-answer list (see "Known Answer Suppression" below) + so that subsequent queries should elicit few, if any, further + responses. Reverting to multicast responses as soon as possible is + important because of the benefits that multicast responses provide + (see "Benefits of Multicast Responses" below). + + When receiving a question with the 'unicast response' bit set, a + responder SHOULD usually respond with a unicast packet directed back + to the querier. If the responder has not multicast that record + recently (within one quarter of its TTL), then the responder SHOULD + instead multicast the response so as to keep all the peer caches up + to date, and to permit passive conflict detection. + + Unicast replies are subject to all the same packet generation rules + as multicast replies, including the cache flush bit (see Section + 11.3, "Announcements to Flush Outdated Cache Entries") and randomized + delays to reduce network collisions (see Section 8, "Responding"). + +Expires 7th December 2005 Cheshire & Krochmal [Page 12] + +Internet Draft Multicast DNS 7th June 2005 + + +6.6 Suppressing Initial Query + + If a query is issued for which there already exist one or more + records in the local cache, and those record(s) were received with + the cache flush bit set (see Section 11.3, "Announcements to Flush + Outdated Cache Entries"), indicating that they form a unique RRSet, + then the host SHOULD suppress its initial "QU" query, and proceed to + issue a "QM" query. To avoid the situation where a group of hosts + are synchronized by some external event and all perform the same + query simultaneously, a host suppressing its initial "QU" query + SHOULD impose a random delay from 500-1000ms before transmitting its + first "QM" query for this question. This means that when the first + host (selected randomly by this algorithm) transmits its "QM" query, + all the other hosts that were about to transmit the same query can + suppress their superfluous query, as described in "Duplicate + Question Suppression" below. + +7. Duplicate Suppression + + A variety of techniques are used to reduce the amount of redundant + traffic on the network. + +7.1 Known Answer Suppression + + When a Multicast DNS Querier sends a query to which it already knows + some answers, it populates the Answer Section of the DNS message with + those answers. + + A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if + the answer it would give is already included in the Answer Section + with an RR TTL at least half the correct value. If the RR TTL of the + answer as given in the Answer Section is less than half of the true + RR TTL as known by the Multicast DNS Responder, the responder MUST + send an answer so as to update the Querier's cache before the record + becomes in danger of expiration. + + Because a Multicast DNS Responder will respond if the remaining TTL + given in the known answer list is less than half the true TTL, it is + superfluous for the Querier to include such records in the known + answer list. Therefore a Multicast DNS Querier SHOULD NOT include + records in the known answer list whose remaining TTL is less than + half their original TTL. Doing so would simply consume space in the + packet without achieving the goal of suppressing responses, and would + therefore be a pointless waste of network bandwidth. + + A Multicast DNS Querier MUST NOT cache resource records observed in + the Known Answer Section of other Multicast DNS Queries. The Answer + Section of Multicast DNS Queries is not authoritative. By placing + information in the Answer Section of a Multicast DNS Query the + querier is stating that it *believes* the information to be true. + It is not asserting that the information *is* true. Some of those + records may have come from other hosts that are no longer on the + network. Propagating that stale information to other Multicast DNS + Queriers on the network would not be helpful. + +Expires 7th December 2005 Cheshire & Krochmal [Page 13] + +Internet Draft Multicast DNS 7th June 2005 + + +7.2 Multi-Packet Known Answer Suppression + + Sometimes a Multicast DNS Querier will already have too many answers + to fit in the Known Answer Section of its query packets. In this + case, it should issue a Multicast DNS Query containing a question and + as many Known Answer records as will fit. It MUST then set the TC + (Truncated) bit in the header before sending the Query. It MUST then + immediately follow the packet with another query packet containing no + questions, and as many more Known Answer records as will fit. If + there are still too many records remaining to fit in the packet, it + again sets the TC bit and continues until all the Known Answer + records have been sent. + + A Multicast DNS Responder seeing a Multicast DNS Query with the TC + bit set defers its response for a time period randomly selected in + the interval 400-500ms. This gives the Multicast DNS Querier time to + send additional Known Answer packets before the Responder responds. + If the Responder sees any of its answers listed in the Known Answer + lists of subsequent packets from the querying host, it SHOULD delete + that answer from the list of answers it is planning to give, provided + that no other host on the network is also waiting to receive the same + answer record. + + Previous versions of this draft specified a delay of 20-120ms before + answering queries with multi-packet Known Answer lists. However, + operational experience showed that, while this works well on + Ethernet, on very busy 802.11 networks, it is not uncommon to observe + consecutively sent packets arriving separated by as much as + 200-400ms. + + +7.3 Duplicate Question Suppression + + If a host is planning to send a query, and it sees another host on + the network send a query containing the same question, and the Known + Answer Section of that query does not contain any records which this + host would not also put in its own Known Answer Section, then this + host should treat its own query as having been sent. When multiple + clients on the network are querying for the same resource records, + there is no need for them to all be repeatedly asking the same + question. + + +7.4 Duplicate Answer Suppression + + If a host is planning to send an answer, and it sees another host on + the network send a response packet containing the same answer record, + and the TTL in that record is not less than the TTL this host would + have given, then this host should treat its own answer as having been + sent. When multiple responders on the network have the same data, + there is no need for all of them to respond. + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 14] + +Internet Draft Multicast DNS 7th June 2005 + + + This feature is particularly useful when multiple Sleep Proxy Servers + are deployed (see Section 16, "Multicast DNS and Power Management"). + In the future it is possible that every general-purpose OS (Mac, + Windows, Linux, etc.) will implement Sleep Proxy Service as a matter + of course. In this case there could be a large number of Sleep Proxy + Servers on any given network, which is good for reliability and + fault-tolerance, but would be bad for the network if every Sleep + Proxy Server were to answer every query. + + +8. Responding + + When a Multicast DNS Responder constructs and sends a Multicast DNS + response packet, the Answer Section of that packet must contain only + records for which that Responder is explicitly authoritative. These + answers may be generated because the record answers a question + received in a Multicast DNS query packet, or at certain other times + that the responder determines than an unsolicited announcement is + warranted. A Multicast DNS Responder MUST NOT place records from its + cache, which have been learned from other responders on the network, + in the Answer Section of outgoing response packets. Only an + authoritative source for a given record is allowed to issue responses + containing that record. + + The determination of whether a given record answers a given question + is done using the standard DNS rules: The record name must match the + question name, the record rrtype must match the question qtype + (unless the qtype is "ANY"), and the record rrclass must match the + question qclass (unless the qclass is "ANY"). + + A Multicast DNS Responder MUST only respond when it has a positive + non-null response to send. Error responses must never be sent. The + non-existence of any name in a Multicast DNS Domain is ascertained by + the failure of any machine to respond to the Multicast DNS query, not + by NXDOMAIN errors. + + Multicast DNS Responses MUST NOT contain any questions in the + Question Section. Any questions in the Question Section of a received + Multicast DNS Response MUST be silently ignored. Multicast DNS + Queriers receiving Multicast DNS Responses do not care what question + elicited the response; they care only that the information in the + response is true and accurate. + + A Multicast DNS Responder on Ethernet [IEEE802] and similar shared + multiple access networks SHOULD have the capability of delaying its + responses by up to 500ms, as determined by the rules described below. + If multiple Multicast DNS Responders were all to respond immediately + to a particular query, a collision would be virtually guaranteed. By + imposing a small random delay, the number of collisions is + dramatically reduced. On a full-sized Ethernet using the maximum + cable lengths allowed and the maximum number of repeaters allowed, an + Ethernet frame is vulnerable to collisions during the transmission of + its first 256 bits. On 10Mb/s Ethernet, this equates to a vulnerable + + +Expires 7th December 2005 Cheshire & Krochmal [Page 15] + +Internet Draft Multicast DNS 7th June 2005 + + + time window of 25.6us. On higher-speed variants of Ethernet, the + vulnerable time window is shorter. + + In the case where a Multicast DNS Responder has good reason to + believe that it will be the only responder on the link with a + positive non-null response, it SHOULD NOT impose any random delay + before responding, and SHOULD normally generate its response within + at most 10ms. In particular, this applies to responding to probe + queries. Since receiving a probe query gives a clear indication that + some other Responder is planning to start using this name in the very + near future, answering such probe queries to defend a unique record + is a high priority and needs to be done immediately, without delay. A + probe query can be distinguished from a normal query by the fact that + a probe query contains a proposed record in the Authority Section + which answers the question in the Question Section (for more details, + see Section 9.1, "Probing"). + + To generate immediate responses safely, it MUST have previously + verified that the requested name, rrtype and rrclass in the DNS query + are unique on this link. Responding immediately without delay is + appropriate for things like looking up the address record for a + particular host name, when the host name has been previously verified + unique. Responding immediately without delay is *not* appropriate for + things like looking up PTR records used for DNS Service Discovery + [DNS-SD], where a large number of responses may be anticipated. + + In any case where there may be multiple responses, such as queries + where the answer is a member of a shared resource record set, each + responder SHOULD delay its response by a random amount of time + selected with uniform random distribution in the range 20-120ms. + + In the case where the query has the TC (truncated) bit set, + indicating that subsequent known answer packets will follow, + responders SHOULD delay their responses by a random amount of time + selected with uniform random distribution in the range 400-500ms, + to allow enough time for all the known answer packets to arrive. + + Except when a unicast reply has been explicitly requested via the + "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port + 5353 (the well-known port assigned to mDNS) on the 224.0.0.251 + multicast address (or its IPv6 equivalent FF02::FB). Operating in a + Zeroconf environment requires constant vigilance. Just because a name + has been previously verified unique does not mean it will continue to + be so indefinitely. By allowing all Multicast DNS Responders to + constantly monitor their peers' responses, conflicts arising out of + network topology changes can be promptly detected and resolved. + + Sending all responses by multicast also facilitates opportunistic + caching by other hosts on the network. + + To protect the network against excessive packet flooding due to + software bugs or malicious attack, a Multicast DNS Responder MUST NOT + multicast a given record on a given interface if it has previously + + +Expires 7th December 2005 Cheshire & Krochmal [Page 16] + +Internet Draft Multicast DNS 7th June 2005 + + + multicast that record on that interface within the last second. A + legitimate client on the network should have seen the previous + transmission and cached it. A client that did not receive and cache + the previous transmission will retry its request and receive a + subsequent response. Under no circumstances is there any legitimate + reason for a Multicast DNS Responder to multicast a given record more + than once per second on any given interface. + + +8.1 Legacy Unicast Responses + + If the source UDP port in a received Multicast DNS Query is not port + 5353, this indicates that the client originating the query is a + simple client that does not fully implement all of Multicast DNS. In + this case, the Multicast DNS Responder MUST send a UDP response + directly back to the client, via unicast, to the query packet's + source IP address and port. This unicast response MUST be a + conventional unicast response as would be generated by a conventional + unicast DNS server; for example, it MUST repeat the query ID and the + question given in the query packet. + + The resource record TTL given in a legacy unicast response SHOULD NOT + be greater than ten seconds, even if the true TTL of the Multicast + DNS resource record is higher. This is because Multicast DNS + Responders that fully participate in the protocol use the cache + coherency mechanisms described in Section 13 to update and invalidate + stale data. Were unicast responses sent to legacy clients to use the + same high TTLs, these legacy clients, which do not implement these + cache coherency mechanisms, could retain stale cached resource record + data long after it is no longer valid. + + Having sent this unicast response, if the Responder has not sent this + record in any multicast response recently, it SHOULD schedule the + record to be sent via multicast as well, to facilitate passive + conflict detection. "Recently" in this context means "if the time + since the record was last sent via multicast is less than one quarter + of the record's TTL". + + +8.2 Multi-Question Queries + + Multicast DNS Responders MUST correctly handle DNS query packets + containing more than one question, by answering any or all of the + questions to which they have answers. Any (non-defensive) answers + generated in response to query packets containing more than one + question SHOULD be randomly delayed in the range 20-120ms, or + 400-500ms if the TC (truncated) bit is set, as described above. + (Answers defending a name, in response to a probe for that name, + are not subject to this delay rule and are still sent immediately.) + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 17] + +Internet Draft Multicast DNS 7th June 2005 + + +8.3 Response Aggregation + + When possible, a responder SHOULD, for the sake of network + efficiency, aggregate as many responses as possible into a single + Multicast DNS response packet. For example, when a responder has + several responses it plans to send, each delayed by a different + interval, then earlier responses SHOULD be delayed by up to an + additional 500ms if that will permit them to be aggregated with + other responses scheduled to go out a little later. + + +9. Probing and Announcing on Startup + + Typically a Multicast DNS Responder should have, at the very least, + address records for all of its active interfaces. Creating and + advertising an HINFO record on each interface as well can be useful + to network administrators. + + Whenever a Multicast DNS Responder starts up, wakes up from sleep, + receives an indication of an Ethernet "Link Change" event, or has any + other reason to believe that its network connectivity may have + changed in some relevant way, it MUST perform the two startup steps + below. + + +9.1 Probing + + The first startup step is that for all those resource records that a + Multicast DNS Responder desires to be unique on the local link, it + MUST send a Multicast DNS Query asking for those resource records, to + see if any of them are already in use. The primary example of this is + its address record which maps its unique host name to its unique IP + address. All Probe Queries SHOULD be done using the desired resource + record name and query type T_ANY (255), to elicit answers for all + types of records with that name. This allows a single question to be + used in place of several questions, which is more efficient on the + network. It also allows a host to verify exclusive ownership of a + name, which is desirable in most cases. It would be confusing, for + example, if one host owned the "A" record for "myhost.local.", but a + different host owned the HINFO record for that name. + + The ability to place more than one question in a Multicast DNS Query + is useful here, because it can allow a host to use a single packet + for all of its resource records instead of needing a separate packet + for each. For example, a host can simultaneously probe for uniqueness + of its "A" record and all its SRV records [DNS-SD] in the same query + packet. + + When ready to send its mDNS probe packet(s) the host should first + wait for a short random delay time, uniformly distributed in the + range 0-250ms. This random delay is to guard against the case where a + group of devices are powered on simultaneously, or a group of devices + are connected to an Ethernet hub which is then powered on, or some + + +Expires 7th December 2005 Cheshire & Krochmal [Page 18] + +Internet Draft Multicast DNS 7th June 2005 + + + other external event happens that might cause a group of hosts to all + send synchronized probes. + + 250ms after the first query the host should send a second, then + 250ms after that a third. If, by 250ms after the third probe, no + conflicting Multicast DNS responses have been received, the host may + move to the next step, announcing. (Note that this is the one + exception from the normal rule that there should be at least one + second between repetitions of the same question, and the interval + between subsequent repetitions should double.) + + If any conflicting Multicast DNS responses are received, then the + probing host MUST defer to the existing host, and MUST choose new + names for some or all of its resource records as appropriate, to + avoid conflict with pre-existing hosts on the network. In the case + of a host probing using query type T_ANY as recommended above, any + answer containing a record with that name, of any type, MUST be + considered a conflicting response and handled accordingly. + + If fifteen failures occur within any ten-second period, then the host + MUST wait at least five seconds before each successive additional + probe attempt. This is to help ensure that in the event of software + bugs or other unanticipated problems, errant hosts do not flood the + network with a continuous stream of multicast traffic. For very + simple devices, a valid way to comply with this requirement is to + always wait five seconds after any failed probe attempt. + + If a responder knows by other means, with absolute certainty, that + its unique resource record set name, rrtype and rrclass cannot + already be in use by any other responder on the network, then it MAY + skip the probing step for that resource record set. For example, when + creating the reverse address mapping PTR records, the host can + reasonably assume that no other host will be trying to create those + same PTR records, since that would imply that the two hosts were + trying to use the same IP address, and if that were the case, the two + hosts would be suffering communication problems beyond the scope of + what Multicast DNS is designed to solve. + + +9.2 Simultaneous Probe Tie-Breaking + + The astute reader will observe that there is a race condition + inherent in the previous description. If two hosts are probing for + the same name simultaneously, neither will receive any response to + the probe, and the hosts could incorrectly conclude that they may + both proceed to use the name. To break this symmetry, each host + populates the Authority Section of its queries with records giving + the rdata that it would be proposing to use, should its probing be + successful. The Authority Section is being used here in a way + analogous to the Update Section of a DNS Update packet [RFC 2136]. + + When a host that is probing for a record sees another host issue a + query for the same record, it consults the Authority Section of that + + +Expires 7th December 2005 Cheshire & Krochmal [Page 19] + +Internet Draft Multicast DNS 7th June 2005 + + + query. If it finds any resource record there which answers the query, + then it compares the data of that resource record with its own + tentative data. The lexicographically later data wins. This means + that if the host finds that its own data is lexicographically later, + it simply ignores the other host's probe. If the host finds that its + own data is lexicographically earlier, then it treats this exactly + as if it had received a positive answer to its query, and concludes + that it may not use the desired name. + + The determination of 'lexicographically later' is performed by first + comparing the record class, then the record type, then raw comparison + of the binary content of the rdata without regard for meaning or + structure. If the record classes differ, then the numerically greater + class is considered 'lexicographically later'. Otherwise, if the + record types differ, then the numerically greater type is considered + 'lexicographically later'. If the rrtype and rrclass both match then + the rdata is compared. + + In the case of resource records containing rdata that is subject to + name compression, the names MUST be uncompressed before comparison. + (The details of how a particular name is compressed is an artifact of + how and where the record is written into the DNS message; it is not + an intrinsic property of the resource record itself.) + + The bytes of the raw uncompressed rdata are compared in turn, + interpreting the bytes as eight-bit UNSIGNED values, until a byte + is found whose value is greater than that of its counterpart (in + which case the rdata whose byte has the greater value is deemed + lexicographically later) or one of the resource records runs out + of rdata (in which case the resource record which still has + remaining data first is deemed lexicographically later). + + The following is an example of a conflict: + + cheshire.local. A 169.254.99.200 + cheshire.local. A 169.254.200.50 + + In this case 169.254.200.50 is lexicographically later (the third + byte, with value 200, is greater than its counterpart with value 99), + so it is deemed the winner. + + Note that it is vital that the bytes are interpreted as UNSIGNED + values, or the wrong outcome may result. In the example above, if + the byte with value 200 had been incorrectly interpreted as a + signed value then it would be interpreted as value -56, and the + wrong address record would be deemed the winner. + + +9.3 Announcing + + The second startup step is that the Multicast DNS Responder MUST send + a gratuitous Multicast DNS Response containing, in the Answer + Section, all of its resource records (both shared records, and unique + + +Expires 7th December 2005 Cheshire & Krochmal [Page 20] + +Internet Draft Multicast DNS 7th June 2005 + + + records that have completed the probing step). If there are too many + resource records to fit in a single packet, multiple packets should + be used. + + In the case of shared records (e.g. the PTR records used by DNS + Service Discovery [DNS-SD]), the records are simply placed as-is + into the Answer Section of the DNS Response. + + In the case of records that have been verified to be unique in the + previous step, they are placed into the Answer Section of the DNS + Response with the most significant bit of the rrclass set to one. + The most significant bit of the rrclass for a record in the Answer + Section of a response packet is the mDNS "cache flush" bit and is + discussed in more detail below in Section 11.3 "Announcements to + Flush Outdated Cache Entries". + + The Multicast DNS Responder MUST send at least two gratuitous + responses, one second apart. A Responder MAY send up to ten + gratuitous Responses, provided that the interval between gratuitous + responses doubles with every response sent. + + A Multicast DNS Responder SHOULD NOT continue sending gratuitous + Responses for longer than the TTL of the record. The purpose of + announcing new records via gratuitous Responses is to ensure that + peer caches are up to date. After a time interval equal to the TTL of + the record has passed, it is very likely that old stale copies of + that record in peer caches will have expired naturally, so subsequent + announcements serve little purpose. + + A Multicast DNS Responder MUST NOT send announcements in the absence + of information that its network connectivity may have changed in some + relevant way. In particular, a Multicast DNS Responder MUST NOT send + regular periodic announcements as a matter of course. + + Whenever a Multicast DNS Responder receives any Multicast DNS + response (gratuitous or otherwise) containing a conflicting resource + record, the conflict MUST be resolved as described below in "Conflict + Resolution". + +9.4 Updating + + At any time, if the rdata of any of a host's Multicast DNS records + changes, the host MUST repeat the Announcing step described above to + update neighboring caches. For example, if any of a host's IP + addresses change, it MUST re-announce those address records. + + In the case of shared records, a host MUST send a 'goodbye' + announcement with TTL zero (see Section 11.2 "Goodbye Packets") + for the old rdata, to cause it to be deleted from peer caches, + before announcing the new rdata. In the case of unique records, + a host SHOULD omit the 'goodbye' announcement, since the cache + flush bit on the newly announced records will cause old rdata + to be flushed from peer caches anyway. + + +Expires 7th December 2005 Cheshire & Krochmal [Page 21] + +Internet Draft Multicast DNS 7th June 2005 + + + A host may update the contents of any of its records at any time, + though a host SHOULD NOT update records more frequently than ten + times per minute. Frequent rapid updates impose a burden on the + network. If a host has information to disseminate which changes more + frequently than ten times per minute, then it may be more appropriate + to design a protocol for that specific purpose. + + +10. Conflict Resolution + + A conflict occurs when a Multicast DNS Responder has a unique record + for which it is authoritative, and it receives, in the Answer Section + of a Multicast DNS response another record with the same name, rrtype + and rrclass, but inconsistent rdata. What may be considered + inconsistent is context sensitive, except that resource records with + identical rdata are never considered inconsistent, even if they + originate from different hosts. This is to permit use of proxies and + other fault-tolerance mechanisms that may cause more than one + responder to be capable of issuing identical answers on the network. + + A common example of a resource record type that is intended to be + unique, not shared between hosts, is the address record that maps a + host's name to its IP address. Should a host witness another host + announce an address record with the same name but a different IP + address, then that is considered inconsistent, and that address + record is considered to be in conflict. + + Whenever a Multicast DNS Responder receives any Multicast DNS + response (gratuitous or otherwise) containing a conflicting resource + record in the Answer Section, the Multicast DNS Responder MUST + immediately reset its conflicted unique record to probing state, and + go through the startup steps described above in Section 9. "Probing + and Announcing on Startup". The protocol used in the Probing phase + will determine a winner and a loser, and the loser MUST cease using + the name, and reconfigure. + + It is very important that any host receiving a resource record that + conflicts with one of its own MUST take action as described above. + In the case of two hosts using the same host name, where one has been + configured to require a unique host name and the other has not, the + one that has not been configured to require a unique host name will + not perceive any conflict, and will not take any action. By reverting + to Probing state, the host that desires a unique host name will go + through the necessary steps to ensure that a unique host is obtained. + + The recommended course of action after probing and failing is as + follows: + + o Programmatically change the resource record name in an attempt to + find a new name that is unique. This could be done by adding some + further identifying information (e.g. the model name of the + hardware) if it is not already present in the name, appending the + digit "2" to the name, or incrementing a number at the end of the + name if one is already present. + +Expires 7th December 2005 Cheshire & Krochmal [Page 22] + +Internet Draft Multicast DNS 7th June 2005 + + + o Probe again, and repeat until a unique name is found. + + o Record this newly chosen name in persistent storage so that the + device will use the same name the next time it is power-cycled. + + o Display a message to the user or operator informing them of the + name change. For example: + + The name "Bob's Music" is in use by another iTunes music + server on the network. Your music has been renamed to + "Bob's Music (G4 Cube)". If you want to change this name, + use [describe appropriate menu item or preference dialog]. + + How the user or operator is informed depends on context. A desktop + computer with a screen might put up a dialog box. A headless server + in the closet may write a message to a log file, or use whatever + mechanism (email, SNMP trap, etc.) it uses to inform the + administrator of other error conditions. On the other hand a headless + server in the closet may not inform the user at all -- if the user + cares, they will notice the name has changed, and connect to the + server in the usual way (e.g. via Web Browser) to configure a new + name. + + The examples in this section focus on address records (i.e. host + names), but the same considerations apply to all resource records + where uniqueness (or maintenance of some other defined constraint) + is desired. + + + +11. Resource Record TTL Values and Cache Coherency + + As a general rule, the recommended TTL value for Multicast DNS + resource records with a host name as the resource record's name + (e.g. A, AAAA, HINFO, etc.) or contained within the resource record's + rdata (e.g. SRV, reverse mapping PTR record, etc.) is 120 seconds. + + The recommended TTL value for other Multicast DNS resource records + is 75 minutes. + + A client with an active outstanding query will issue a query packet + when one or more of the resource record(s) in its cache is (are) 80% + of the way to expiry. If the TTL on those records is 75 minutes, + this ongoing cache maintenance process yields a steady-state query + rate of one query every 60 minutes. + + Any distributed cache needs a cache coherency protocol. If Multicast + DNS resource records follow the recommendation and have a TTL of 75 + minutes, that means that stale data could persist in the system for + a little over an hour. Making the default TTL significantly lower + would reduce the lifetime of stale data, but would produce too much + extra traffic on the network. Various techniques are available to + minimize the impact of such stale data. + + +Expires 7th December 2005 Cheshire & Krochmal [Page 23] + +Internet Draft Multicast DNS 7th June 2005 + + +11.1 Cooperating Multicast DNS Responders + + If a Multicast DNS Responder ("A") observes some other Multicast DNS + Responder ("B") send a Multicast DNS Response packet containing a + resource record with the same name, rrtype and rrclass as one of A's + resource records, but different rdata, then: + + o If A's resource record is intended to be a shared resource record, + then this is no conflict, and no action is required. + + o If A's resource record is intended to be a member of a unique + resource record set owned solely by that responder, then this + is a conflict and MUST be handled as described in Section 10 + "Conflict Resolution". + + If a Multicast DNS Responder ("A") observes some other Multicast DNS + Responder ("B") send a Multicast DNS Response packet containing a + resource record with the same name, rrtype and rrclass as one of A's + resource records, and identical rdata, then: + + o If the TTL of B's resource record given in the packet is at least + half the true TTL from A's point of view, then no action is + required. + + o If the TTL of B's resource record given in the packet is less than + half the true TTL from A's point of view, then A MUST mark its + record to be announced via multicast. Clients receiving the record + from B would use the TTL given by B, and hence may delete the + record sooner than A expects. By sending its own multicast response + correcting the TTL, A ensures that the record will be retained for + the desired time. + + These rules allow multiple Multicast DNS Responders to offer the same + data on the network (perhaps for fault tolerance reasons) without + conflicting with each other. + + +11.2 Goodbye Packets + + In the case where a host knows that certain resource record data is + about to become invalid (for example when the host is undergoing a + clean shutdown) the host SHOULD send a gratuitous announcement mDNS + response packet, giving the same resource record name, rrtype, + rrclass and rdata, but an RR TTL of zero. This has the effect of + updating the TTL stored in neighboring hosts' cache entries to zero, + causing that cache entry to be promptly deleted. + + Clients receiving a Multicast DNS Response with a TTL of zero SHOULD + NOT immediately delete the record from the cache, but instead record + a TTL of 1 and then delete the record one second later. In the case + of multiple Multicast DNS Responders on the network described in + Section 11.1 above, if one of the Responders shuts down and + incorrectly sends goodbye packets for its records, it gives the other + + +Expires 7th December 2005 Cheshire & Krochmal [Page 24] + +Internet Draft Multicast DNS 7th June 2005 + + + cooperating Responders one second to send out their own response to + "rescue" the records before they expire and are deleted. + + Generally speaking, it is more important to send goodbye packets for + shared records than unique records. A given shared record name (such + as a PTR record used for DNS Service Discovery [DNS-SD]) by its + nature often has many representatives from many different hosts, and + tends to be the subject of long-lived ongoing queries. Those + long-lived queries are often concerned not just about being informed + when records appear, but also about being informed if those records + vanish again. In contrast, a unique record set (such as an SRV + record, or a host address record), by its nature, often has far fewer + members than a shared record set, and is usually the subject of + one-shot queries which simply retrieve the data and then cease + querying once they have the answer they are seeking. Therefore, + sending a goodbye packet for a unique record set is likely to offer + less benefit, because it is likely at any given moment that no one + has an active query running for that record set. One example where + goodbye packets for SRV and address records are useful is when + transferring control to a Sleep Proxy Server (see Section 16, + "Multicast DNS and Power Management"). + + +11.3 Announcements to Flush Outdated Cache Entries + + Whenever a host has a resource record with potentially new data (e.g. + after rebooting, waking from sleep, connecting to a new network link, + changing IP address, etc.), the host MUST send a series of gratuitous + announcements to update cache entries in its neighbor hosts. In + these gratuitous announcements, if the record is one that is intended + to be unique, the host sets the most significant bit of the rrclass + field of the resource record. This bit, the "cache flush" bit, tells + neighboring hosts that this is not a shared record type. Instead of + merging this new record additively into the cache in addition to any + previous records with the same name, rrtype and rrclass, all old + records with that name, type and class that were received more than + one second ago are declared invalid, and marked to expire from the + cache in one second. + + The semantics of the cache flush bit are as follows: Normally when a + resource record appears in the Answer Section of the DNS Response, it + means, "This is an assertion that this information is true." When a + resource record appears in the Answer Section of the DNS Response + with the "cache flush" bit set, it means, "This is an assertion that + this information is the truth and the whole truth, and anything you + may have heard more than a second ago regarding records of this + name/rrtype/rrclass is no longer valid". + + To accommodate the case where the set of records from one host + constituting a single unique RRSet is too large to fit in a single + packet, only cache records that are more than one second old are + flushed. This allows the announcing host to generate a quick burst of + packets back-to-back on the wire containing all the members + + +Expires 7th December 2005 Cheshire & Krochmal [Page 25] + +Internet Draft Multicast DNS 7th June 2005 + + + of the RRSet. When receiving records with the "cache flush" bit set, + all records older than one second are marked to be deleted one second + in the future. One second after the end of the little packet burst, + any records not represented within that packet burst will then be + expired from all peer caches. + + Any time a host sends a response packet containing some members of a + unique RRSet, it SHOULD send the entire RRSet, preferably in a single + packet, or if the entire RRSet will not fit in a single packet, in a + quick burst of packets sent as close together as possible. The host + SHOULD set the cache flush bit on all members of the unique RRSet. + In the event that for some reason the host chooses not to send the + entire unique RRSet in a single packet or a rapid packet burst, + it MUST NOT set the cache flush bit on any of those records. + + The reason for waiting one second before deleting stale records from + the cache is to accommodate bridged networks. For example, a host's + address record announcement on a wireless interface may be bridged + onto a wired Ethernet, and cause that same host's Ethernet address + records to be flushed from peer caches. The one-second delay gives + the host the chance to see its own announcement arrive on the wired + Ethernet, and immediately re-announce its Ethernet interface's + address records so that both sets remain valid and live in peer + caches. + + These rules apply regardless of *why* the response packet is being + generated. They apply to startup announcements as described in + Section 9.3, and to responses generated as a result of receiving + query packets. + + The "cache flush" bit is only set in records in the Answer Section of + Multicast DNS responses sent to UDP port 5353. The "cache flush" bit + MUST NOT be set in any resource records in a response packet sent in + legacy unicast responses to UDP ports other than 5353. + + The "cache flush" bit MUST NOT be set in any resource records in the + known-answer list of any query packet. + + The "cache flush" bit MUST NOT ever be set in any shared resource + record. To do so would cause all the other shared versions of this + resource record with different rdata from different Responders to be + immediately deleted from all the caches on the network. + + The "cache flush" bit does apply to questions listed in the Question + Section of a Multicast DNS packet. The top bit of the rrclass field + in questions is used for an entirely different purpose (see Section + 6.5, "Questions Requesting Unicast Responses"). + + Note that the "cache flush" bit is NOT part of the resource record + class. The "cache flush" bit is the most significant bit of the + second 16-bit word of a resource record in the Answer Section of + an mDNS packet (the field conventionally referred to as the rrclass + field), and the actual resource record class is the least-significant + + +Expires 7th December 2005 Cheshire & Krochmal [Page 26] + +Internet Draft Multicast DNS 7th June 2005 + + + fifteen bits of this field. There is no mDNS resource record class + 0x8001. The value 0x8001 in the rrclass field of a resource record in + an mDNS response packet indicates a resource record with class 1, + with the "cache flush" bit set. When receiving a resource record with + the "cache flush" bit set, implementations should take care to mask + off that bit before storing the resource record in memory. + + +11.4 Cache Flush on Topology change + + If the hardware on a given host is able to indicate physical changes + of connectivity, then when the hardware indicates such a change, the + host should take this information into account in its mDNS cache + management strategy. For example, a host may choose to immediately + flush all cache records received on a particular interface when that + cable is disconnected. Alternatively, a host may choose to adjust the + remaining TTL on all those records to a few seconds so that if the + cable is not reconnected quickly, those records will expire from the + cache. + + Likewise, when a host reboots, or wakes from sleep, or undergoes some + other similar discontinuous state change, the cache management + strategy should take that information into account. + + +11.5 Cache Flush on Failure Indication + + Sometimes a cache record can be determined to be stale when a client + attempts to use the rdata it contains, and finds that rdata to be + incorrect. + + For example, the rdata in an address record can be determined to be + incorrect if attempts to contact that host fail, either because + ARP/ND requests for that address go unanswered (for an address on a + local subnet) or because a router returns an ICMP "Host Unreachable" + error (for an address on a remote subnet). + + The rdata in an SRV record can be determined to be incorrect if + attempts to communicate with the indicated service at the host and + port number indicated are not successful. + + The rdata in a DNS-SD PTR record can be determined to be incorrect if + attempts to look up the SRV record it references are not successful. + + In any such case, the software implementing the mDNS resource record + cache should provide a mechanism so that clients detecting stale + rdata can inform the cache. + + When the cache receives this hint that it should reconfirm some + record, it MUST issue two or more queries for the resource record in + question. If no response is received in a reasonable amount of time, + then, even though its TTL may indicate that it is not yet due to + expire, that record SHOULD be promptly flushed from the cache. + + +Expires 7th December 2005 Cheshire & Krochmal [Page 27] + +Internet Draft Multicast DNS 7th June 2005 + + + The end result of this is that if a printer suffers a sudden power + failure or other abrupt disconnection from the network, its name may + continue to appear in DNS-SD browser lists displayed on users' + screens. Eventually that entry will expire from the cache naturally, + but if a user tries to access the printer before that happens, the + failure to successfully contact the printer will trigger the more + hasty demise of its cache entries. This is a sensible trade-off + between good user-experience and good network efficiency. If we were + to insist that printers should disappear from the printer list within + 30 seconds of becoming unavailable, for all failure modes, the only + way to achieve this would be for the client to poll the printer at + least every 30 seconds, or for the printer to announce its presence + at least every 30 seconds, both of which would be an unreasonable + burden on most networks. + + +11.6 Passive Observation of Failures + + A host observes the multicast queries issued by the other hosts on + the network. One of the major benefits of also sending responses + using multicast is that it allows all hosts to see the responses (or + lack thereof) to those queries. + + If a host sees queries, for which a record in its cache would be + expected to be given as an answer in a multicast response, but no + such answer is seen, then the host may take this as an indication + that the record may no longer be valid. + + After seeing two or more of these queries, and seeing no multicast + response containing the expected answer within a reasonable amount of + time, then even though its TTL may indicate that it is not yet due to + expire, that record MAY be flushed from the cache. The host SHOULD + NOT perform its own queries to re-confirm that the record is truly + gone. If every host on a large network were to do this, it would + cause a lot of unnecessary multicast traffic. If host A sends + multicast queries that remain unanswered, then there is no reason to + suppose that host B or any other host is likely to be any more + successful. + + The previous section, "Cache Flush on Failure Indication", describes + a situation where a user trying to print discovers that the printer + is no longer available. By implementing the passive observation + described here, when one user fails to contact the printer, all hosts + on the network observe that failure and update their caches + accordingly. + + +12. Special Characteristics of Multicast DNS Domains + + Unlike conventional DNS names, names that end in ".local.", + "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local + significance. Conventional DNS seeks to provide a single unified + namespace, where a given DNS query yields the same answer no matter + + +Expires 7th December 2005 Cheshire & Krochmal [Page 28] + +Internet Draft Multicast DNS 7th June 2005 + + + where on the planet it is performed or to which recursive DNS server + the query is sent. (However, split views, firewalls, intranets and + the like have somewhat interfered with this goal of DNS representing + a single universal truth.) In contrast, each IP link has its own + private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa." + namespaces, and the answer to any query for a name within those + domains depends on where that query is asked. + + Multicast DNS Domains are not delegated from their parent domain via + use of NS records. There are no NS records anywhere in Multicast DNS + Domains. Instead, all Multicast DNS Domains are delegated to the IP + addresses 224.0.0.251 and FF02::FB by virtue of the individual + organizations producing DNS client software deciding how to handle + those names. It would be extremely valuable for the industry if this + special handling were ratified and recorded by IANA, since otherwise + the special handling provided by each vendor is likely to be + inconsistent. + + The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The + IPv6 name server for a Multicast DNS Domain is FF02::FB. These are + multicast addresses; therefore they identify not a single host but a + collection of hosts, working in cooperation to maintain some + reasonable facsimile of a competently managed DNS zone. Conceptually + a Multicast DNS Domain is a single DNS zone, however its server is + implemented as a distributed process running on a cluster of loosely + cooperating CPUs rather than as a single process running on a single + CPU. + + No delegation is performed within Multicast DNS Domains. Because the + cluster of loosely coordinated CPUs is cooperating to administer a + single zone, delegation is neither necessary nor desirable. Just + because a particular host on the network may answer queries for a + particular record type with the name "example.local." does not imply + anything about whether that host will answer for the name + "child.example.local.", or indeed for other record types with the + name "example.local." + + Multicast DNS Zones have no SOA record. A conventional DNS zone's + SOA record contains information such as the email address of the zone + administrator and the monotonically increasing serial number of the + last zone modification. There is no single human administrator for + any given Multicast DNS Zone, so there is no email address. Because + the hosts managing any given Multicast DNS Zone are only loosely + coordinated, there is no readily available monotonically increasing + serial number to determine whether or not the zone contents have + changed. A host holding part of the shared zone could crash or be + disconnected from the network at any time without informing the other + hosts. There is no reliable way to provide a zone serial number that + would, whenever such a crash or disconnection occurred, immediately + change to indicate that the contents of the shared zone had changed. + + Zone transfers are not possible for any Multicast DNS Zone. + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 29] + +Internet Draft Multicast DNS 7th June 2005 + + +13. Multicast DNS for Service Discovery + + This document does not describe using Multicast DNS for network + browsing or service discovery. However, the mechanisms this document + describes are compatible with (and support) the browsing and service + discovery mechanisms proposed in "DNS-Based Service Discovery" + [DNS-SD]. + + +14. Enabling and Disabling Multicast DNS + + The option to fail-over to Multicast DNS for names not ending in + ".local." SHOULD be a user-configured option, and SHOULD + be disabled by default because of the possible security issues + related to unintended local resolution of apparently global names. + + The option to lookup unqualified (relative) names by appending + ".local." (or not) is controlled by whether ".local." appears + (or not) in the client's DNS search list. + + No special control is needed for enabling and disabling Multicast DNS + for names explicitly ending with ".local." as entered by the user. + The user doesn't need a way to disable Multicast DNS for names ending + with ".local.", because if the user doesn't want to use Multicast + DNS, they can achieve this by simply not using those names. If a user + *does* enter a name ending in ".local.", then we can safely assume + the user's intention was probably that it should work. Having user + configuration options that can be (intentionally or unintentionally) + set so that local names don't work is just one more way of + frustrating the user's ability to perform the tasks they want, + perpetuating the view that, "IP networking is too complicated to + configure and too hard to use." This in turn perpetuates the + continued use of protocols like AppleTalk. If we want to retire + AppleTalk, NetBIOS, etc., we need to offer users equivalent IP + functionality that they can rely on to, "always work, like + AppleTalk." A little Multicast DNS traffic may be a burden on the + network, but it is an insignificant burden compared to continued + widespread use of AppleTalk. + + +15. Considerations for Multiple Interfaces + + A host should defend its host name (FQDN) on all active interfaces on + which it is answering Multicast DNS queries. + + In the event of a name conflict on *any* interface, a host should + configure a new host name, if it wishes to maintain uniqueness of its + host name. + + A host may choose to use the same name for all of its address records + on all interfaces, or it may choose to manage its Multicast DNS host + name(s) independently on each interface, potentially answering to + different names on different interfaces. + + +Expires 7th December 2005 Cheshire & Krochmal [Page 30] + +Internet Draft Multicast DNS 7th June 2005 + + + When answering a Multicast DNS query, a multi-homed host with a + link-local address (or addresses) should take care to ensure that + any address going out in a Multicast DNS response is valid for use + on the interface on which the response is going out. + + Just as the same link-local IP address may validly be in use + simultaneously on different links by different hosts, the same + link-local host name may validly be in use simultaneously on + different links, and this is not an error. A multi-homed host with + connections to two different links may be able to communicate with + two different hosts that are validly using the same name. While this + kind of name duplication should be rare, it means that a host that + wants to fully support this case needs network programming APIs that + allow applications to specify on what interface to perform a + link-local Multicast DNS query, and to discover on what interface a + Multicast DNS response was received. + + +16. Multicast DNS and Power Management + + Many modern network devices have the ability to go into a low-power + mode where only a small part of the Ethernet hardware remains + powered, and the device can be woken up by sending a specially + formatted Ethernet frame which the device's power-management hardware + recognizes. + + To make use of this in conjunction with Multicast DNS, we propose a + network power management service called Sleep Proxy Service. A device + that wishes to enter low-power mode first uses DNS-SD to determine if + Sleep Proxy Service is available on the local network. In some + networks there may be more than one piece of hardware implementing + Sleep Proxy Service, for fault-tolerance reasons. + + If the device finds the network has Sleep Proxy Service, the device + transmits two or more gratuitous mDNS announcements setting the TTL + of its relevant resource records to zero, to delete them from + neighboring caches. The relevant resource records include address + records and SRV records, and other resource records as may apply to a + particular device. The device then communicates all of its remaining + active records, plus the names, rrtypes and rrclasses of the deleted + records, to the Sleep Proxy Service(s), along with a copy of the + specific "magic packet" required to wake the device up. + + When a Sleep Proxy Service sees an mDNS query for one of the + device's active records (e.g. a DNS-SD PTR record), it answers on + behalf of the device without waking it up. When a Sleep Proxy Service + sees an mDNS query for one of the device's deleted resource + records, it deduces that some client on the network needs to make an + active connection to the device, and sends the specified "magic + packet" to wake the device up. The device then wakes up, reactivates + its deleted resource records, and re-announces them to the network. + The client waiting to connect sees the announcements, learns the + current IP address and port number of the desired service on the + device, and proceeds to connect to it. + +Expires 7th December 2005 Cheshire & Krochmal [Page 31] + +Internet Draft Multicast DNS 7th June 2005 + + + The connecting client does not need to be aware of how Sleep Proxy + Service works. Only devices that implement low power mode and wish to + make use of Sleep Proxy Service need to be aware of how that protocol + works. + + The reason that a device using a Sleep Proxy Service should send more + than one goodbye packet is to ensure deletion of the resource records + from all peer caches. If resource records were to inadvertently + remain in some peer caches, then those peers may not issue any query + packets for those records when attempting to access the sleeping + device, so the Sleep Proxy Service would not receive any queries for + the device's SRV and/or address records, and the necessary wake-up + message would not be triggered. + + The full specification of mDNS / DNS-SD Sleep Proxy Service + is described in another document [not yet published]. + + +17. Multicast DNS Character Set + + Unicast DNS has been plagued by the lack of any support for non-US + characters. Indeed, conventional DNS is usually limited to just + letters, digits and hyphens, with no spaces or other punctuation. + Attempts to remedy this for unicast DNS have been badly constrained + by the need to accommodate old buggy legacy DNS implementations. + In reality, the DNS specification actually imposes no limits on what + characters may be used in names, and good DNS implementations handle + any arbitrary eight-bit data without trouble. However, the old rules + for ARPANET host names back in the 1980s required names to be just + letters, digits, and hyphens [RFC 1034], and since the predominant + use of DNS is to store host address records, many have assumed that + the DNS protocol itself suffers from the same limitation. It would be + more accurate to say that certain bad implementations may not handle + eight-bit data correctly, not that the protocol doesn't support it. + + Multicast DNS is a new protocol and doesn't (yet) have old buggy + legacy implementations to constrain the design choices. Accordingly, + it adopts the simple obvious elegant solution: all names in Multicast + DNS are encoded using precomposed UTF-8 [RFC 3629]. The + characters SHOULD conform to Unicode Normalization Form C (NFC): Use + precomposed characters instead of combining sequences where possible, + e.g. use U+00C4 ("Latin capital letter A with diaeresis") instead of + U+0041 U+0308 ("Latin capital letter A", "combining diaeresis"). + + For names that are restricted to letters, digits and hyphens, the + UTF-8 encoding is identical to the US-ASCII encoding, so this is + entirely compatible with existing host names. For characters outside + the US-ASCII range, UTF-8 encoding is used. + + Multicast DNS implementations MUST NOT use any other encodings apart + from precomposed UTF-8 (US-ASCII being considered a compatible subset + of UTF-8). + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 32] + +Internet Draft Multicast DNS 7th June 2005 + + + This point bears repeating: After many years of debate, as a result + of the need to accommodate certain DNS implementations that + apparently couldn't handle any character that's not a letter, digit + or hyphen (and apparently never will be updated to remedy this + limitation) the unicast DNS community settled on an extremely baroque + encoding called "Punycode" [RFC 3492]. Punycode is a remarkably + ingenious encoding solution, but it is complicated, hard to + understand, and hard to implement, using sophisticated techniques + including insertion unsort coding, generalized variable-length + integers, and bias adaptation. The resulting encoding is remarkably + compact given the constraints, but it's still not as good as simple + straightforward UTF-8, and it's hard even to predict whether a given + input string will encode to a Punycode string that fits within DNS's + 63-byte limit, except by simply trying the encoding and seeing + whether it fits. Indeed, the encoded size depends not only on the + input characters, but on the order they appear, so the same set of + characters may or may not encode to a legal Punycode string that fits + within DNS's 63-byte limit, depending on the order the characters + appear. This is extremely hard to present in a user interface that + explains to users why one name is allowed, but another name + containing the exact same characters is not. Neither Punycode nor any + other of the "Ascii Compatible Encodings" proposed for Unicast DNS + may be used in Multicast DNS packets. Any text being represented + internally in some other representation MUST be converted to + canonical precomposed UTF-8 before being placed in any Multicast DNS + packet. + + The simple rules for case-insensitivity in Unicast DNS also apply in + Multicast DNS; that is to say, in name comparisons, the lower-case + letters "a" to "z" (0x61 to 0x7A) match their upper-case equivalents + "A" to "Z" (0x41 to 0x5A). Hence, if a client issues a query for an + address record with the name "cheshire.local", then a responder + having an address record with the name "Cheshire.local" should + issue a response. No other automatic equivalences should be assumed. + In particular all UTF-8 multi-byte characters (codes 0x80 and higher) + are compared by simple binary comparison of the raw byte values. + + No other automatic character equivalence is defined in Multicast DNS. + For example, accented characters are not defined to be automatically + equivalent to their unaccented counterparts. Where automatic + equivalences are desired, this may be achieved through the use of + programmatically-generated CNAME records. For example, if a responder + has an address record for an accented name Y, and a client issues a + query for a name X, where X is the same as Y with all the accents + removed, then the responder may issue a response containing two + resource records: A CNAME record "X CNAME Y", asserting that the + requested name X (unaccented) is an alias for the true (accented) + name Y, followed by the address record for Y. + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 33] + +Internet Draft Multicast DNS 7th June 2005 + + +18. Multicast DNS Message Size + + RFC 1035 restricts DNS Messages carried by UDP to no more than 512 + bytes (not counting the IP or UDP headers). For UDP packets carried + over the wide-area Internet in 1987, this was appropriate. For + link-local multicast packets on today's networks, there is no reason + to retain this restriction. Given that the packets are by definition + link-local, there are no Path MTU issues to consider. + + Multicast DNS Messages carried by UDP may be up to the IP MTU of the + physical interface, less the space required for the IP header (20 + bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes). + + In the case of a single mDNS Resource Record which is too large to + fit in a single MTU-sized multicast response packet, a Multicast DNS + Responder SHOULD send the Resource Record alone, in a single IP + datagram, sent using multiple IP fragments. Resource Records this + large SHOULD be avoided, except in the very rare cases where they + really are the appropriate solution to the problem at hand. + Implementers should be aware that many simple devices do not + re-assemble fragmented IP datagrams, so large Resource Records SHOULD + NOT be used except in specialized cases where the implementer knows + that all receivers implement reassembly. + + A Multicast DNS packet larger than the interface MTU, which is sent + using fragments, MUST NOT contain more than one Resource Record. + + Even when fragmentation is used, a Multicast DNS packet, including IP + and UDP headers, MUST NOT exceed 9000 bytes. + + +19. Multicast DNS Message Format + + This section describes specific restrictions on the allowable + values for the header fields of a Multicast DNS message. + +19.1. ID (Query Identifier) + + Multicast DNS clients SHOULD listen for gratuitous responses + issued by hosts booting up (or waking up from sleep or otherwise + joining the network). Since these gratuitous responses may contain a + useful answer to a question for which the client is currently + awaiting an answer, Multicast DNS clients SHOULD examine all received + Multicast DNS response messages for useful answers, without regard to + the contents of the ID field or the Question Section. In Multicast + DNS, knowing which particular query message (if any) is responsible + for eliciting a particular response message is less interesting than + knowing whether the response message contains useful information. + + Multicast DNS clients MAY cache any or all Multicast DNS response + messages they receive, for possible future use, provided of course + that normal TTL aging is performed on these cached resource records. + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 34] + +Internet Draft Multicast DNS 7th June 2005 + + + In multicast query messages, the Query ID SHOULD be set to zero on + transmission. + + In multicast responses, including gratuitous multicast responses, the + Query ID MUST be set to zero on transmission, and MUST be ignored on + reception. + + In unicast response messages generated specifically in response to a + particular (unicast or multicast) query, the Query ID MUST match the + ID from the query message. + + +19.2. QR (Query/Response) Bit + + In query messages, MUST be zero. + + In response messages, MUST be one. + + +19.3. OPCODE + + In both multicast query and multicast response messages, MUST be zero + (only standard queries are currently supported over multicast, unless + other queries are allowed by future IETF Standards Action). + + +19.4. AA (Authoritative Answer) Bit + + In query messages, the Authoritative Answer bit MUST be zero on + transmission, and MUST be ignored on reception. + + In response messages for Multicast Domains, the Authoritative Answer + bit MUST be set to one (not setting this bit implies there's some + other place where "better" information may be found) and MUST be + ignored on reception. + + +19.5. TC (Truncated) Bit + + In query messages, if the TC bit is set, it means that additional + Known Answer records may be following shortly. A responder MAY choose + to record this fact, and wait for those additional Known Answer + records, before deciding whether to respond. If the TC bit is clear, + it means that the querying host has no additional Known Answers. + + In multicast response messages, the TC bit MUST be zero on + transmission, and MUST be ignored on reception. + + In legacy unicast response messages, the TC bit has the same meaning + as in conventional unicast DNS: it means that the response was too + large to fit in a single packet, so the client SHOULD re-issue its + query using TCP in order to receive the larger response. + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 35] + +Internet Draft Multicast DNS 7th June 2005 + + +19.6. RD (Recursion Desired) Bit + + In both multicast query and multicast response messages, the + Recursion Desired bit SHOULD be zero on transmission, and MUST be + ignored on reception. + + +19.7. RA (Recursion Available) Bit + + In both multicast query and multicast response messages, the + Recursion Available bit MUST be zero on transmission, and MUST be + ignored on reception. + + +19.8. Z (Zero) Bit + + In both query and response messages, the Zero bit MUST be zero on + transmission, and MUST be ignored on reception. + + +19.9. AD (Authentic Data) Bit [RFC 2535] + + In query messages the Authentic Data bit MUST be zero on + transmission, and MUST be ignored on reception. + + In response messages, the Authentic Data bit MAY be set. Resolvers + receiving response messages with the AD bit set MUST NOT trust the AD + bit unless they trust the source of the message and either have a + secure path to it or use DNS transaction security. + + +19.10. CD (Checking Disabled) Bit [RFC 2535] + + In query messages, a resolver willing to do cryptography SHOULD set + the Checking Disabled bit to permit it to impose its own policies. + + In response messages, the Checking Disabled bit MUST be zero on + transmission, and MUST be ignored on reception. + + +19.11. RCODE (Response Code) + + In both multicast query and multicast response messages, the Response + Code MUST be zero on transmission. Multicast DNS messages received + with non-zero Response Codes MUST be silently ignored. + + +19.12. Repurposing of top bit of qclass in Question Section + + In the Question Section of a Multicast DNS Query, the top bit of the + qclass field is used to indicate that unicast responses are preferred + for this particular question. + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 36] + +Internet Draft Multicast DNS 7th June 2005 + + +19.12. Repurposing of top bit of rrclass in Answer Section + + In the Answer Section of a Multicast DNS Response, the top bit of the + rrclass field is used to indicate that the record is a member of a + unique RRSet, and the entire RRSet has been sent together (in the + same packet, or in consecutive packets if there are too many records + to fit in a single packet). + + +20. Choice of UDP Port Number + + Arguments were made for and against using Multicast on UDP port 53. + The final decision was to use UDP port 5353. Some of the arguments + for and against are given below. + + +20.1 Arguments for using UDP port 53: + + * This is "just DNS", so it should be the same port. + + * There is less work to be done updating old clients to do simple + mDNS queries. Only the destination address need be changed. + In some cases, this can be achieved without any code changes, + just by adding the address 224.0.0.251 to a configuration file. + + +20.2 Arguments for using a different port (UDP port 5353): + + * This is not "just DNS". This is a DNS-like protocol, but different. + + * Changing client code to use a different port number is not hard. + + * Using the same port number makes it hard to run an mDNS Responder + and a conventional unicast DNS server on the same machine. If a + conventional unicast DNS server wishes to implement mDNS as well, + it can still do that, by opening two sockets. Having two different + port numbers is important to allow this flexibility. + + * Some VPN software hijacks all outgoing traffic to port 53 and + redirects it to a special DNS server set up to serve those VPN + clients while they are connected to the corporate network. It is + questionable whether this is the right thing to do, but it is + common, and redirecting link-local multicast DNS packets to a + remote server rarely produces any useful results. It does mean, for + example, that the user becomes unable to access their local network + printer sitting on their desk right next to their computer. Using + a different UDP port eliminates this particular problem. + + * On many operating systems, unprivileged clients may not send or + receive packets on low-numbered ports. This means that any client + sending or receiving mDNS packets on port 53 would have to run as + "root", which is an undesirable security risk. Using a higher- + numbered UDP port eliminates this particular problem. + + +Expires 7th December 2005 Cheshire & Krochmal [Page 37] + +Internet Draft Multicast DNS 7th June 2005 + + + Continuing the previous point, since using an unprivileged port + allows normal user-level code to bind, a given machine may have more + than one such user-level application running at a time. Because of + this, any code binding to UDP port 5353 MUST use the SO_REUSEPORT + option, so as to be a good citizen and not block other clients on the + machine from also binding to that port. + + +21. Summary of Differences Between Multicast DNS and Unicast DNS + + The value of Multicast DNS is that it shares, as much as possible, + the familiar APIs, naming syntax, resource record types, etc., of + Unicast DNS. There are of course necessary differences by virtue of + it using Multicast, and by virtue of it operating in a community of + cooperating peers, rather than a precisely defined authoritarian + hierarchy controlled by a strict chain of formal delegations from the + top. These differences are listed below: + + Multicast DNS... + * uses multicast + * uses UDP port 5353 instead of port 53 + * operates in well-defined parts of the DNS namespace + * uses UTF-8, and only UTF-8, to encode resource record names + * defines a clear limit on the maximum legal domain name (255 bytes) + * allows larger UDP packets + * allows more than one question in a query packet + * uses the Answer Section of a query to list Known Answers + * uses the TC bit in a query to indicate additional Known Answers + * uses the Authority Section of a query for probe tie-breaking + * ignores the Query ID field (except for generating legacy responses) + * doesn't require the question to be repeated in the response packet + * uses gratuitous responses to announce new records to the peer group + * defines a "unicast response" bit in the rrclass of query questions + * defines a "cache flush" bit in the rrclass of response answers + * uses DNS TTL 0 to indicate that a record has been deleted + * monitors queries to perform Duplicate Question Suppression + * monitors responses to perform Duplicate Answer Suppression... + * ... and Ongoing Conflict Detection + * ... and Opportunistic Caching + + +22. Benefits of Multicast Responses + + Some people have argued that sending responses via multicast is + inefficient on the network. In fact the benefits of using multicast + responses result in a net lowering of overall multicast traffic, for + a variety of reasons. + + * One multicast response can update the cache on all machines on the + network. If another machine later wants to issue the same query, it + already has the answer in its cache, so it may not need to even + transmit that multicast query on the network at all. + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 38] + +Internet Draft Multicast DNS 7th June 2005 + + + * When more than one machine has the same ongoing long-lived query + running, every machine does not have to transmit its own + independent query. When one machine transmits a query, all the + other hosts see the answers, so they can suppress their own + queries. + + * When a host sees a multicast query, but does not see the + corresponding multicast response, it can use this information to + promptly delete stale data from its cache. To achieve the same + level of user-interface quality and responsiveness without + multicast responses would require lower cache lifetimes and more + frequent network polling, resulting in a significantly higher + packet rate. + + * Multicast responses allow passive conflict detection. Without this + ability, some other conflict detection mechanism would be needed, + imposing its own additional burden on the network. + + * When using delayed responses to reduce network collisions, clients + need to maintain a list recording to whom each answer should be + sent. The option of multicast responses allows clients with limited + storage, which cannot store an arbitrarily long list of response + addresses, to choose to fail-over to a single multicast response in + place of multiple unicast responses, when appropriate. + + * In the case of overlayed subnets and other misconfigurations, + multicast responses allow a receiver to know with certainty that + a response originated on the local link, even when its source + address may apparently suggest otherwise. This can be extremely + helpful when diagnosing and rectifying network problems, since + it facilitates a direct communication channel between client and + server that works without reliance on ARP, IP routing tables, etc. + Being able to discover what IP address a device has (or thinks it + has) is frequently a very valuable first step in diagnosing why + it unable to communicate on the local network. + + +23. IPv6 Considerations + + An IPv4-only host and an IPv6-only host behave as "ships that pass in + the night". Even if they are on the same Ethernet, neither is aware + of the other's traffic. For this reason, each physical link may have + *two* unrelated ".local." zones, one for IPv4 and one for IPv6. + Since for practical purposes, a group of IPv4-only hosts and a group + of IPv6-only hosts on the same Ethernet act as if they were on two + entirely separate Ethernet segments, it is unsurprising that their + use of the ".local." zone should occur exactly as it would if + they really were on two entirely separate Ethernet segments. + + A dual-stack (v4/v6) host can participate in both ".local." + zones, and should register its name(s) and perform its lookups both + using IPv4 and IPv6. This enables it to reach, and be reached by, + both IPv4-only and IPv6-only hosts. In effect this acts like a + + +Expires 7th December 2005 Cheshire & Krochmal [Page 39] + +Internet Draft Multicast DNS 7th June 2005 + + + multi-homed host, with one connection to the logical "IPv4 Ethernet + segment", and a connection to the logical "IPv6 Ethernet segment". + +23.1 IPv6 Multicast Addresses by Hashing + + Some discovery protocols use a range of multicast addresses, and + determine the address to be used by a hash function of the name being + sought. Queries are sent via multicast to the address as indicated by + the hash function, and responses are returned to the querier via + unicast. Particularly in IPv6, where multicast addresses are + extremely plentiful, this approach is frequently advocated. + + There are some problems with this: + + * When a host has a large number of records with different names, the + host may have to join a large number of multicast groups. This can + place undue burden on the Ethernet hardware, which typically + supports a limited number of multicast addresses efficiently. When + this number is exceeded, the Ethernet hardware may have to resort + to receiving all multicasts and passing them up to the host + software for filtering, thereby defeating the point of using a + multicast address range in the first place. + + * Multiple questions cannot be placed in one packet if they don't all + hash to the same multicast address. + + * Duplicate Question Suppression doesn't work if queriers are not + seeing each other's queries. + + * Duplicate Answer Suppression doesn't work if responders are not + seeing each other's responses. + + * Opportunistic Caching doesn't work. + + * Ongoing Conflict Detection doesn't work. + + +24. Security Considerations + + The algorithm for detecting and resolving name conflicts is, by its + very nature, an algorithm that assumes cooperating participants. Its + purpose is to allow a group of hosts to arrive at a mutually disjoint + set of host names and other DNS resource record names, in the absence + of any central authority to coordinate this or mediate disputes. In + the absence of any higher authority to resolve disputes, the only + alternative is that the participants must work together cooperatively + to arrive at a resolution. + + In an environment where the participants are mutually antagonistic + and unwilling to cooperate, other mechanisms are appropriate, like + manually administered DNS. + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 40] + +Internet Draft Multicast DNS 7th June 2005 + + + In an environment where there is a group of cooperating participants, + but there may be other antagonistic participants on the same physical + link, the cooperating participants need to use IPSEC signatures + and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS + messages from trusted participants (which they process as usual) from + mDNS messages from untrusted participants (which they silently + discard). + + When DNS queries for *global* DNS names are sent to the mDNS + multicast address (during network outages which disrupt communication + with the greater Internet) it is *especially* important to use + DNSSEC, because the user may have the impression that he or she is + communicating with some authentic host, when in fact he or she is + really communicating with some local host that is merely masquerading + as that name. This is less critical for names ending with ".local.", + because the user should be aware that those names have only local + significance and no global authority is implied. + + Most computer users neglect to type the trailing dot at the end of a + fully qualified domain name, making it a relative domain name (e.g. + "www.example.com"). In the event of network outage, attempts to + positively resolve the name as entered will fail, resulting in + application of the search list, including ".local.", if present. + A malicious host could masquerade as "www.example.com" by answering + the resulting Multicast DNS query for "www.example.com.local." + To avoid this, a host MUST NOT append the search suffix + ".local.", if present, to any relative (partially qualified) + domain name containing two or more labels. Appending ".local." to + single-label relative domain names is acceptable, since the user + should have no expectation that a single-label domain name will + resolve as-is. + + +25. IANA Considerations + + IANA has allocated the IPv4 link-local multicast address 224.0.0.251 + for the use described in this document. + + IANA has allocated the IPv6 multicast address set FF0X::FB for the + use described in this document. Only address FF02::FB (Link-Local + Scope) is currently in use by deployed software, but it is possible + that in future implementers may experiment with Multicast DNS using + larger-scoped addresses, such as FF05::FB (Site-Local Scope). + + When this document is published, IANA should designate a list of + domains which are deemed to have only link-local significance, as + described in Section 12 of this document ("Special Characteristics of + Multicast DNS Domains"). + + The re-use of the top bit of the rrclass field in the Question and + Answer Sections means that Multicast DNS can only carry DNS records + with classes in the range 0-32767. Classes in the range 32768 to + 65535 are incompatible with Multicast DNS. However, since to-date + + +Expires 7th December 2005 Cheshire & Krochmal [Page 41] + +Internet Draft Multicast DNS 7th June 2005 + + + only three DNS classes have been assigned by IANA (1, 3 and 4), + and only one (1, "Internet") is actually in widespread use, this + limitation is likely to remain a purely theoretical one. + + No other IANA services are required by this document. + + +26. Acknowledgments + + The concepts described in this document have been explored, developed + and implemented with help from Freek Dijkstra, Erik Guttman, Paul + Vixie, Bill Woodcock, and others. + + Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, + Roger Pantos and Kiren Sekar for their significant contributions. + + +27. 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 + 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. + + +28. Normative References + + [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. + +Expires 7th December 2005 Cheshire & Krochmal [Page 42] + +Internet Draft Multicast DNS 7th June 2005 + + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 3629, November 2003. + + +29. Informative References + + [dotlocal] + + [djbdl] + + [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service + Discovery", Internet-Draft (work in progress), + draft-cheshire-dnsext-dns-sd-03.txt, June 2005. + + [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: + Overview and Architecture. + Institute of Electrical and Electronic Engineers, + IEEE Standard 802, 1990. + + [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 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name + System (DNS UPDATE)", RFC 2136, April 1997. + + [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC 3492] Costello, A., "Punycode: A Bootstring encoding of + Unicode for use with Internationalized Domain Names + in Applications (IDNA)", RFC 3492, March 2003. + + [RFC 3927] Cheshire, S., B. Aboba, and E. Guttman, + "Dynamic Configuration of IPv4 Link-Local Addresses", + RFC 3927, May 2005. + + [ZC] Williams, A., "Requirements for Automatic Configuration + of IP Hosts", Internet-Draft (work in progress), + draft-ietf-zeroconf-reqts-12.txt, September 2002. + + + + + + + + +Expires 7th December 2005 Cheshire & Krochmal [Page 43] + +Internet Draft Multicast DNS 7th June 2005 + + +30. 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 44] -- cgit