翻译成中文,只做翻译: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.