7.  Traffic Reduction

   A variety of techniques are used to reduce the amount of 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 query
   message with those answers.

   Generally, this applies only to Shared records, not Unique records,
   since if a Multicast DNS querier already has at least one Unique
   record in its cache then it should not be expecting further different
   answers to this question, since the Unique record(s) it already has
   comprise the complete answer, so it has no reason to be sending the
   query at all.  In contrast, having some Shared records in its cache
   does not necessarily imply that a Multicast DNS querier will not

   receive further answers to this query, and it is in this case that it
   is beneficial to use the Known-Answer list to suppress repeated
   sending of redundant answers that the querier already knows.

   A Multicast DNS responder MUST 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 of their original TTL.  Doing so would simply consume space in
   the message without achieving the goal of suppressing responses and
   would, therefore, be a pointless waste of network capacity.

   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.  Multipacket 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
   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-500 ms.  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
   MUST delete that answer from the list of answers it is planning to
   give (provided that no other host on the network has also issued a
   query for that record and is waiting to receive an answer).

   If the responder receives additional Known-Answer packets with the TC
   bit set, it SHOULD extend the delay as necessary to ensure a pause of
   400-500 ms after the last such packet before it sends its answer.
   This opens the potential risk that a continuous stream of Known-
   Answer packets could, theoretically, prevent a responder from
   answering indefinitely.  In practice, answers are never actually
   delayed significantly, and should a situation arise where significant
   delays did happen, that would be a scenario where the network is so
   overloaded that it would be desirable to err on the side of caution.
   The consequence of delaying an answer may be that it takes a user
   longer than usual to discover all the services on the local network;
   in contrast, the consequence of incorrectly answering before all the
   Known-Answer packets have been received would be wasted capacity
   sending unnecessary answers on an already overloaded network.  In
   this (rare) situation, sacrificing speed to preserve reliable network
   operation is the right trade-off.

7.3.  Duplicate Question Suppression

   If a host is planning to transmit (or retransmit) a query, and it
   sees another host on the network send a query containing the same
   "QM" question, and the Known-Answer Section of that query does not
   contain any records that 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 queriers 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 message 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, and not also send an identical answer itself.  When
   multiple responders on the network have the same data, there is no
   need for all of them to respond.

   The opportunity for duplicate answer suppression occurs when a host
   has received a query, and is delaying its response for some pseudo-
   random interval up to 500 ms, as described elsewhere in this
   document, and then, before the host sends its response, it sees some
   other host on the network send a response message containing the same
   answer record.

   This feature is particularly useful when Multicast DNS Proxy Servers
   are in use, where there could be more than one proxy on the network
   giving Multicast DNS answers on behalf of some other host (e.g.,
   because that other host is currently asleep and is not itself
   responding to queries).

8.  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 a network interface "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: Probing (Section 8.1) and Announcing (Section 8.3).

8.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 a host's address records, which map its unique host name to its
   unique IPv4 and/or IPv6 addresses.  All probe queries SHOULD be done
   using the desired resource record name and class (usually class 1,
   "Internet"), and query type "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 for all rrtypes, 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 "AAAA" 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 message
   to probe for all of its resource records instead of needing a
   separate message for each.  For example, a host can simultaneously
   probe for uniqueness of its "A" record and all its SRV records
   [RFC6763] in the same query message.

   When ready to send its Multicast DNS probe packet(s) the host should
   first wait for a short random delay time, uniformly distributed in
   the range 0-250 ms.  This random delay is to guard against the case
   where several devices are powered on simultaneously, or several
   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.

   250 ms after the first query, the host should send a second; then,
   250 ms after that, a third.  If, by 250 ms after the third probe, no
   conflicting Multicast DNS responses have been received, the host may
   move to the next step, announcing.  (Note that probing 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 at least double.)

   When sending probe queries, a host MUST NOT consult its cache for
   potential answers.  Only conflicting Multicast DNS responses received
   "live" from the network are considered valid for the purposes of
   determining whether probing has succeeded or failed.

   In order to allow services to announce their presence without
   unreasonable delay, the time window for probing is intentionally set
   quite short.  As a result of this, from the time the first probe
   packet is sent, another device on the network using that name has
   just 750 ms to respond to defend its name.  On networks that are
   slow, or busy, or both, it is possible for round-trip latency to
   account for a few hundred milliseconds, and software delays in slow
   devices can add additional delay.  Hence, it is important that when a
   device receives a probe query for a name that it is currently using,
   it SHOULD generate its response to defend that name immediately and
   send it as quickly as possible.  The usual rules about random delays
   before responding, to avoid sudden bursts of simultaneous answers
   from different hosts, do not apply here since normally at most one
   host should ever respond to a given probe question.  Even when a
   single DNS query message contains multiple probe questions, it would
   be unusual for that message to elicit a defensive response from more
   than one other host.  Because of the mDNS multicast rate-limiting

   rules, the probes SHOULD be sent as "QU" questions with the unicast-
   response bit set, to allow a defending host to respond immediately
   via unicast, instead of potentially having to wait before replying
   via multicast.

   During probing, from the time the first probe packet is sent until
   250 ms after the third probe, if any conflicting Multicast DNS
   response is received, then the probing host MUST defer to the
   existing host, and SHOULD choose new names for some or all of its
   resource records as appropriate.  Apparently conflicting Multicast
   DNS responses received *before* the first probe packet is sent MUST
   be silently ignored (see discussion of stale probe packets in Section
   8.2, "Simultaneous Probe Tiebreaking", below).  In the case of a host
   probing using query type "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 conflicts 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 before
   trying again.

   If a responder knows by other means that its unique resource record
   set name, rrtype, and rrclass cannot already be in use by any other
   responder on the network, then it SHOULD 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.  Similarly, if a responder is acting as a proxy,
   taking over from another Multicast DNS responder that has already
   verified the uniqueness of the record, then the proxy SHOULD NOT
   repeat the probing step for those records.

8.2.  Simultaneous Probe Tiebreaking

   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 query message's Authority Section with the record or

   records with 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 way it is used as the "Update Section" in a DNS
   Update message [RFC2136] [RFC3007].

   When a host is probing for a group of related records with the same
   name (e.g., the SRV and TXT record describing a DNS-SD service), only
   a single question need be placed in the Question Section, since query
   type "ANY" (255) is used, which will elicit answers for all records
   with that name.  However, for tiebreaking to work correctly in all
   cases, the Authority Section must contain *all* the records and
   proposed rdata being probed for uniqueness.

   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(s) there which answers the
   query, then it compares the data of that (those) resource record(s)
   with its own tentative data.  We consider first the simple case of a
   host probing for a single record, receiving a simultaneous probe from
   another host also probing for a single record.  The two records are
   compared and 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 defers to the winning
   host by waiting one second, and then begins probing for this record
   again.  The logic for waiting one second and then trying again is to
   guard against stale probe packets on the network (possibly even stale
   probe packets sent moments ago by this host itself, before some
   configuration change, which may be echoed back after a short delay by
   some Ethernet switches and some 802.11 base stations).  If the
   winning simultaneous probe was from a real other host on the network,
   then after one second it will have completed its probing, and will
   answer subsequent probes.  If the apparently winning simultaneous
   probe was in fact just an old stale packet on the network (maybe from
   the host itself), then when it retries its probing in one second, its
   probes will go unanswered, and it will successfully claim the name.

   The determination of "lexicographically later" is performed by first
   comparing the record class (excluding the cache-flush bit described
   in Section 10.2), 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 [RFC1035], 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:

     MyPrinter.local. A 169.254.99.200
     MyPrinter.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 in the range 0-255, or the wrong outcome may result.  In the
   example above, if the byte with value 200 had been incorrectly
   interpreted as a signed eight-bit value, then it would be interpreted
   as value -56, and the wrong address record would be deemed the
   winner.

8.2.1.  Simultaneous Probe Tiebreaking for Multiple Records

   When a host is probing for a set of records with the same name, or a
   message is received containing multiple tiebreaker records answering
   a given probe question in the Question Section, the host's records
   and the tiebreaker records from the message are each sorted into
   order, and then compared pairwise, using the same comparison
   technique described above, until a difference is found.

   The records are sorted using the same lexicographical order as
   described above, that is, if the record classes differ, the record
   with the lower class number comes first.  If the classes are the same
   but the rrtypes differ, the record with the lower rrtype number comes
   first.  If the class and rrtype match, then the rdata is compared
   bytewise until a difference is found.  For example, in the common
   case of advertising DNS-SD services with a TXT record and an SRV
   record, the TXT record comes first (the rrtype value for TXT is 16)
   and the SRV record comes second (the rrtype value for SRV is 33).

   When comparing the records, if the first records match perfectly,
   then the second records are compared, and so on.  If either list of
   records runs out of records before any difference is found, then the
   list with records remaining is deemed to have won the tiebreak.  If
   both lists run out of records at the same time without any difference
   being found, then this indicates that two devices are advertising
   identical sets of records, as is sometimes done for fault tolerance,
   and there is, in fact, no conflict.

8.3.  Announcing

   The second startup step is that the Multicast DNS responder MUST send
   an unsolicited Multicast DNS response containing, in the Answer
   Section, all of its newly registered resource records (both shared
   records, and unique 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-
   Based Service Discovery [RFC6763]), 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 message is the Multicast DNS cache-flush bit
   and is discussed in more detail below in Section 10.2, "Announcements
   to Flush Outdated Cache Entries".

   The Multicast DNS responder MUST send at least two unsolicited
   responses, one second apart.  To provide increased robustness against
   packet loss, a responder MAY send up to eight unsolicited responses,
   provided that the interval between unsolicited responses increases by
   at least a factor of two with every response sent.

   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 (solicited or otherwise) containing a conflicting resource
   record, the conflict MUST be resolved as described in Section 9,
   "Conflict Resolution".

8.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.  The
   host does not need to repeat the Probing step because it has already
   established unique ownership of that name.

   In the case of shared records, a host MUST send a "goodbye"
   announcement with RR TTL zero (see Section 10.1, "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.

   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.

9.  Conflict Resolution

   A conflict occurs when a Multicast DNS responder has a unique record
   for which it is currently authoritative, and it receives a Multicast
   DNS response message containing a 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 (solicited or otherwise) containing a conflicting resource
   record in any of the Resource Record Sections, the Multicast DNS
   responder MUST immediately reset its conflicted unique record to
   probing state, and go through the startup steps described above in

   Section 8, "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 name
   is obtained.

   The recommended course of action after probing and failing is as
   follows:

      1. 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,
         or appending the digit "2" to the name, or incrementing a
         number at the end of the name if one is already present.

      2. Probe again, and repeat as necessary until a unique name is
         found.

      3. Once an available unique name has been determined, by probing
         without receiving any conflicting response, record this newly
         chosen name in persistent storage so that the device will use
         the same name the next time it is power-cycled.

      4. 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 music server on
            the network.  Your music collection has been renamed to
            "Bob's Music (2)".  If you want to change this name, use
            [describe appropriate menu item or preference dialog here].

         The details of how the user or operator is informed of the new
         name 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
         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.

      5. After one minute of probing, if the Multicast DNS responder has
         been unable to find any unused name, it should log an error
         message to inform the user or operator of this fact.  This
         situation should never occur in normal operation.  The only
         situations that would cause this to happen would be either a
         deliberate denial-of-service attack, or some kind of very
         obscure hardware or software bug that acts like a deliberate
         denial-of-service attack.

   These considerations apply to address records (i.e., host names) and
   to all resource records where uniqueness (or maintenance of some
   other defined constraint) is desired.

10.  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) or a host name contained within the resource
   record's rdata (e.g., SRV, reverse mapping PTR record) SHOULD be 120
   seconds.

   The recommended TTL value for other Multicast DNS resource records is
   75 minutes.

   A querier with an active outstanding query will issue a query message
   when one or more of the resource records in its cache 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 RR 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, outlined in the five
   subsections below.

10.1.  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 an unsolicited Multicast DNS

   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.

   Queriers 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 6.6 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.

10.2.  Announcements to Flush Outdated Cache Entries

   Whenever a host has a resource record with new data, or with what
   might potentially be new data (e.g., after rebooting, waking from
   sleep, connecting to a new network link, or changing IP address), the
   host needs to inform peers of that new data.  In cases where the host
   has not been continuously connected and participating on the network
   link, it MUST first probe to re-verify uniqueness of its unique
   records, as described above in Section 8.1, "Probing".

   Having completed the Probing step, if necessary, the host MUST then
   send a series of unsolicited announcements to update cache entries in
   its neighbor hosts.  In these unsolicited announcements, if the
   record is one that has been verified 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, rrtype,
   and rrclass 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 a Resource Record Section of the DNS
   response it means, "This is an assertion that this information is
   true".  When a resource record appears in a Resource Record 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 true".

   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 MUST 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
   MUST set the cache-flush bit on all members of the unique RRSet.

   Another 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 may 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, about when to set the cache-flush bit and about sending
   the entire rrset, apply regardless of *why* the response message is
   being generated.  They apply to startup announcements as described in
   Section 8.3, "Announcing", and to responses generated as a result of
   receiving query messages.

   The cache-flush bit is only set in records in the Resource Record
   Sections of Multicast DNS responses sent to UDP port 5353.

   The cache-flush bit MUST NOT be set in any resource records in a
   response message 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 message.

   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 *not* apply to questions listed in the
   Question Section of a Multicast DNS message.  The top bit of the
   rrclass field in questions is used for an entirely different purpose
   (see Section 5.4, "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 a Resource Record Section of a
   Multicast DNS message (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 Multicast DNS
   resource record class 0x8001.  The value 0x8001 in the rrclass field
   of a resource record in a Multicast DNS response message 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, or otherwise ensure that it is given
   the correct semantic interpretation.

   The reuse of the top bit of the rrclass field only applies to
   conventional resource record types that are subject to caching, not
   to pseudo-RRs like OPT [RFC2671], TSIG [RFC2845], TKEY [RFC2930],
   SIG0 [RFC2931], etc., that pertain only to a particular transport
   level message and not to any actual DNS data.  Since pseudo-RRs
   should never go into the Multicast DNS cache, the concept of a cache-
   flush bit for these types is not applicable.  In particular, the
   rrclass field of an OPT record encodes the sender's UDP payload size,
   and should be interpreted as a sixteen-bit length value in the range
   0-65535, not a one-bit flag and a fifteen-bit length.

10.3.  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 Multicast DNS
   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, wakes from sleep, or undergoes some
   other similar discontinuous state change, the cache management
   strategy should take that information into account.

10.4.  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 the client 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 (for
   an IPv4 address on a local subnet) ARP requests for that address go
   unanswered, because (for an IPv6 address with an on-link prefix) ND
   requests for that address go unanswered, or because (for an address
   on a remote network) a router returns an ICMP "Host Unreachable"
   error.

   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.

   The software implementing the Multicast DNS 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
   dispute.  If no response is received within ten seconds, 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.

10.5.  Passive Observation Of Failures (POOF)

   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 ten seconds, then even
   though its TTL may indicate that it is not yet due to expire, that
   record SHOULD be flushed from the cache.  The host SHOULD NOT perform
   its own queries to reconfirm 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.

11.  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 queriers
   (implementing a draft version of this document, posted in February
   2004) that check the IP TTL on reception to determine whether the
   packet originated on the local link.  These older queriers 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 and FF02::FB link-local multicast
   addresses) 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 received with a destination address in the IP
        header that is the mDNS IPv4 link-local multicast address
        224.0.0.251 or the mDNS IPv6 link-local multicast address
        FF02::FB 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 received with a unicast destination address in the
        IP header, the source IP address in the packet is checked to see
        if it is an address on a local subnet.  An IPv4 source 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.  An IPv6 source address
        is determined to be on the local link if, for any of the on-link
        IPv6 prefixes on the interface receiving the packet (learned via
        IPv6 router advertisements or otherwise configured on the host),
        the first 'n' bits of the IPv6 source address match the first
        'n' bits of the prefix address, where 'n' is the length of the
        prefix being considered.

   Since queriers will ignore responses apparently originating outside
   the local subnet, a responder 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 mDNS IPv4 link-local multicast address 224.0.0.251,
   from a source address not apparently on the same subnet as the
   responder (or, in the case of IPv6, from a source IPv6 address for
   which the responder does not have any address with the same prefix on
   that interface), then even if the query indicates that a unicast
   response is preferred (see Section 5.4, "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.

12.  Special Characteristics of Multicast DNS Domains

   Unlike conventional DNS names, names that end in ".local." have only
   local significance.  The same is true of names within the IPv4 link-
   local reverse mapping domain "254.169.in-addr.arpa." and the IPv6
   link-local reverse mapping domains "8.e.f.ip6.arpa.",
   "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.".

   These names function primarily as protocol identifiers, rather than
   as user-visible identifiers.  Even though they may occasionally be
   visible to end users, that is not their primary purpose.  As such,
   these names should be treated as opaque identifiers.  In particular,
   the string "local" should not be translated or localized into
   different languages, much as the name "localhost" is not translated
   or localized into different languages.

   Conventional Unicast 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.  In contrast, each IP link has its own private ".local.",
   "254.169.in-addr.arpa." and IPv6 link-local reverse mapping
   namespaces, and the answer to any query for a name within those
   domains depends on where that query is asked.  (This characteristic
   is not unique to Multicast DNS.  Although the original concept of DNS
   was a single global namespace, in recent years, split views,
   firewalls, intranets, DNS geolocation, and the like have increasingly
   meant that the answer to a given DNS query has become dependent on
   the location of the querier.)

   The IPv4 name server address for a Multicast DNS domain is
   224.0.0.251.  The IPv6 name server address 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.

   Multicast DNS domains are not delegated from their parent domain via
   use of NS (Name Server) records, and there is also no concept of
   delegation of subdomains within a Multicast DNS domain.  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.".

   There are no NS records anywhere in Multicast DNS domains.  Instead,
   the Multicast DNS domains are reserved by IANA, and there is
   effectively an implicit delegation of all Multicast DNS domains to
   the 224.0.0.251:5353 and [FF02::FB]:5353 multicast groups, by virtue
   of client software implementing the protocol rules specified in this
   document.

   Multicast DNS zones have no SOA (Start of Authority) 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.