implement DBUS protocol

git-svn-id: file:///home/lennart/svn/public/avahi/trunk@171 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe

5 files changed, 11282 insertions, 0 deletions

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
+
+                 <draft-cheshire-dnsext-dns-sd-02.txt>
+
+
+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 "<Service>.<Domain>" is a
+   list of zero or more PTR records giving Service Instance Names of the
+   form:
+
+      Service Instance Name = <Instance> . <Service> . <Domain>
+
+   The <Instance> 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 <Instance> 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 <Service> 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 <Domain> 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 <Domain> 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 <Instance> portion of the name). In
+   the common case, the <Service> and <Domain> 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
+   <Service> of the discovered instance my not be exactly the same as
+   the <Service> 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 <Instance>, <Service> and <Domain> portions are internally
+   concatenated together into a single string, then care must be taken
+   with the <Instance> portion, since it is allowed to contain any
+   characters, including dots.
+
+   Any dots in the <Instance> portion should be escaped by preceeding
+   them with a backslash ("." becomes "\."). Likewise, any backslashes
+   in the <Instance> 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 = <Instance> . <Service> . <Domain>
+
+   instead of:
+
+      Service Instance Name = <Service> . <Instance> . <Domain>
+
+   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 <Service> and <Domain>, then each
+   occurrence of a Service Instance Name can be expressed using only the
+   <Instance> part followed by a two-byte compression pointer
+   referencing a previous appearance of "<Service>.<Domain>". This
+   efficiency would not be possible if the <Service> 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
+   <Service> 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 <Service> 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
+   <Service> 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.<Domain>", the Web browser issues a query for
+   "_anon._ftp._tcp.<Domain>", 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.<Domain>" 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.<domain>
+        _default._browse._dns-sd._udp.<domain>
+               _register._dns-sd._udp.<domain>
+      _default._register._dns-sd._udp.<domain>
+
+   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 <domain> 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.<Domain>" 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
+   <http://www.dns-sd.org/ServiceNames.html>. 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 <http://www.iana.org/assignments/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
+
+                 <draft-cheshire-dnsext-dns-sd-03.txt>
+
+
+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 "<Service>.<Domain>" is a
+   list of zero or more PTR records giving Service Instance Names of the
+   form:
+
+      Service Instance Name = <Instance> . <Service> . <Domain>
+
+   The <Instance> 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 <Instance> 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 <Service> 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 <Domain> 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 <Domain> 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 <Instance> portion of the name). In
+   the common case, the <Service> and <Domain> 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
+   <Service> of the discovered instance my not be exactly the same as
+   the <Service> 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 <Instance>, <Service> and <Domain> portions are internally
+   concatenated together into a single string, then care must be taken
+   with the <Instance> portion, since it is allowed to contain any
+   characters, including dots.
+
+   Any dots in the <Instance> portion should be escaped by preceding
+   them with a backslash ("." becomes "\."). Likewise, any backslashes
+   in the <Instance> 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 = <Instance> . <Service> . <Domain>
+
+   instead of:
+
+      Service Instance Name = <Service> . <Instance> . <Domain>
+
+   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 <Service> and <Domain>, then each
+   occurrence of a Service Instance Name can be expressed using only the
+   <Instance> part followed by a two-byte compression pointer
+   referencing a previous appearance of "<Service>.<Domain>". This
+   efficiency would not be possible if the <Service> 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
+   <Service> 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 <Service> 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
+   <Service> 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:
+
+      <Instance>.<app>._tcp.<servicedomain>.<parentdomain>.
+      <sub>._sub.<app>._tcp.<servicedomain>.<parentdomain>.
+
+   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 <Instance> 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 <app> 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 <parentdomain>. When used with Multicast DNS,
+   <parentdomain> 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 <servicedomain> names can help avoid overflows. If
+   the <servicedomain> and <parentdomain> 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 <parentdomain> 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.<Domain>", the Web browser issues a query for
+   "_anon._sub._ftp._tcp.<Domain>", 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.<Domain>" 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.<domain>.
+                     db._dns-sd._udp.<domain>.
+                      r._dns-sd._udp.<domain>.
+                     dr._dns-sd._udp.<domain>.
+                     lb._dns-sd._udp.<domain>.
+
+   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 <domain> 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 <domain> 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 <domain> 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.<Domain>" 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
+   <http://www.dns-sd.org/ServiceTypes.html>. 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 <http://www.iana.org/assignments/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
+
+               <draft-cheshire-dnsext-multicastdns-03.txt>
+
+
+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] <http://www.dotlocal.org/>
+
+   [djbdl]    <http://cr.yp.to/djbdns/dot-local.html>
+
+   [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
+
+               <draft-cheshire-dnsext-multicastdns-04.txt>
+
+
+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] <http://www.dotlocal.org/>
+
+   [djbdl]    <http://cr.yp.to/djbdns/dot-local.html>
+
+   [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
+
+               <draft-cheshire-dnsext-multicastdns-05.txt>
+
+
+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] <http://www.dotlocal.org/>
+
+   [djbdl]    <http://cr.yp.to/djbdns/dot-local.html>
+
+   [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]