翻译成中文，仅做翻译：
18. Multicast DNS Message Format
This section describes specific rules pertaining to the allowable
values for the header fields of a Multicast DNS message, and other
message format considerations.
18.1. ID (Query Identifier)
Multicast DNS implementations SHOULD listen for unsolicited responses
issued by hosts booting up (or waking up from sleep or otherwise
joining the network). Since these unsolicited responses may contain
a useful answer to a question for which the querier is currently
awaiting an answer, Multicast DNS implementations 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 implementations MAY cache data from 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.
In multicast query messages, the Query Identifier SHOULD be set to
zero on transmission.
In multicast responses, including unsolicited multicast responses,
the Query Identifier MUST be set to zero on transmission, and MUST be
ignored on reception.
In legacy unicast response messages generated specifically in
response to a particular (unicast or multicast) query, the Query
Identifier MUST match the ID from the query message.
18.2. QR (Query/Response) Bit
In query messages the QR bit MUST be zero.
In response messages the QR bit MUST be one.
18.3. OPCODE
In both multicast query and multicast response messages, the OPCODE
MUST be zero on transmission (only standard queries are currently
supported over multicast). Multicast DNS messages received with an
OPCODE other than zero MUST be silently ignored.
18.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 would imply there's some
other place where "better" information may be found) and MUST be
ignored on reception.
18.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 SHOULD
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 querier SHOULD reissue its
query using TCP in order to receive the larger response.
18.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.
18.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.
18.8. Z (Zero) Bit
In both query and response messages, the Zero bit MUST be zero on
transmission, and MUST be ignored on reception.
18.9. AD (Authentic Data) Bit
In both multicast query and multicast response messages, the
Authentic Data bit [RFC2535] MUST be zero on transmission, and MUST
be ignored on reception.
18.10. CD (Checking Disabled) Bit
In both multicast query and multicast response messages, the Checking
Disabled bit [RFC2535] MUST be zero on transmission, and MUST be
ignored on reception.
18.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.
18.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. (See Section 5.4.)
18.13. Repurposing of Top Bit of rrclass in Resource Record Sections
In the Resource Record Sections 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). (See Section 10.2.)
18.14. Name Compression
When generating Multicast DNS messages, implementations SHOULD use
name compression wherever possible to compress the names of resource
records, by replacing some or all of the resource record name with a
compact two-byte reference to an appearance of that data somewhere
earlier in the message [RFC1035].
This applies not only to Multicast DNS responses, but also to
queries. When a query contains more than one question, successive
questions in the same message often contain similar names, and
consequently name compression SHOULD be used, to save bytes. In
addition, queries may also contain Known Answers in the Answer
Section, or probe tiebreaking data in the Authority Section, and
these names SHOULD similarly be compressed for network efficiency.
In addition to compressing the *names* of resource records, names
that appear within the *rdata* of the following rrtypes SHOULD also
be compressed in all Multicast DNS messages:
NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC
Until future IETF Standards Action [RFC5226] specifying that names in
the rdata of other types should be compressed, names that appear
within the rdata of any type not listed above MUST NOT be compressed.
Implementations receiving Multicast DNS messages MUST correctly
decode compressed names appearing in the Question Section, and
compressed names of resource records appearing in other sections.
In addition, implementations MUST correctly decode compressed names
appearing within the *rdata* of the rrtypes listed above. Where
possible, implementations SHOULD also correctly decode compressed
names appearing within the *rdata* of other rrtypes known to the
implementers at the time of implementation, because such forward-
thinking planning helps facilitate the deployment of future
implementations that may have reason to compress those rrtypes. It
is possible that no future IETF Standards Action [RFC5226] will be
created that mandates or permits the compression of rdata in new
types, but having implementations designed such that they are capable
of decompressing all known types helps keep future options open.
One specific difference between Unicast DNS and Multicast DNS is that
Unicast DNS does not allow name compression for the target host in an
SRV record, because Unicast DNS implementations before the first SRV
specification in 1996 [RFC2052] may not decode these compressed
records properly. Since all Multicast DNS implementations were
created after 1996, all Multicast DNS implementations are REQUIRED to
decode compressed SRV records correctly.
In legacy unicast responses generated to answer legacy queries, name
compression MUST NOT be performed on SRV records.
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
