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.
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.
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). Section 8.1) and Announcing (Section 8.3).
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.
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.
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. 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".
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.
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.
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. 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.
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 220.127.116.11 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 18.104.22.168, 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.
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 22.214.171.124: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.