draft-ietf-dnsext-mdns-43.txt

bind 源码 最新实现 linux/unix/windows平台

   [c]  A responder responds to this query only if it is authoritative
        for the domain name in the query.  A responder responds to a
        multicast query by sending a unicast UDP response to the sender.
        Unicast queries are responded to as indicated in Section 2.4.

   [d]  Upon reception of the response, the sender processes it.

   The sections that follow provide further details on sender and
   responder behavior.

2.1.  LLMNR Packet Format

   LLMNR is based on the DNS packet format defined in [RFC1035] Section
   4 for both queries and responses.  LLMNR implementations SHOULD send
   UDP queries and responses only as large as are known to be
   permissible without causing fragmentation.  When in doubt a maximum
   packet size of 512 octets SHOULD be used.  LLMNR implementations MUST
   accept UDP queries and responses as large as the smaller of the link
   MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
   octets for the header, VLAN tag and CRC).

2.1.1.  LLMNR Header Format

   LLMNR queries and responses utilize the DNS header format defined in
   [RFC1035] with exceptions noted below:











Aboba, Thaler & Esibov       Standards Track                    [Page 6]





INTERNET-DRAFT                    LLMNR                   29 August 2005


                                   1  1  1  1  1  1
     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                      ID                       |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |QR|   Opcode  | C|TC| T| Z| Z| Z| Z|   RCODE   |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    QDCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    ANCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    NSCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    ARCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

ID   A 16 bit identifier assigned by the program that generates any kind
     of query.  This identifier is copied from the query to the response
     and can be used by the sender to match responses to outstanding
     queries. The ID field in a query SHOULD be set to a pseudo-random
     value.  For advice on generation of pseudo-random values, please
     consult [RFC1750].

QR   Query/Response.  A one bit field, which if set indicates that the
     message is an LLMNR response; if clear then the message is an LLMNR
     query.

OPCODE
     A four bit field that specifies the kind of query in this message.
     This value is set by the originator of a query and copied into the
     response.  This specification defines the behavior of standard
     queries and responses (opcode value of zero).  Future
     specifications may define the use of other opcodes with LLMNR.
     LLMNR senders and responders MUST support standard queries (opcode
     value of zero).  LLMNR queries with unsupported OPCODE values MUST
     be silently discarded by responders.

C    Conflict.  When set within a request, the 'C'onflict bit indicates
     that a sender has received multiple LLMNR responses to this query.
     In an LLMNR response, if the name is considered UNIQUE, then the
     'C' bit is clear, otherwise it is set.  LLMNR senders do not
     retransmit queries with the 'C' bit set.  Responders MUST NOT
     respond to LLMNR queries with the 'C' bit set, but may start the
     uniqueness verification process, as described in Section 4.2.





Aboba, Thaler & Esibov       Standards Track                    [Page 7]





INTERNET-DRAFT                    LLMNR                   29 August 2005


TC   TrunCation - specifies that this message was truncated due to
     length greater than that permitted on the transmission channel.
     The TC bit MUST NOT be set in an LLMNR query and if set is ignored
     by an LLMNR responder.  If the TC bit is set in an LLMNR response,
     then the sender SHOULD discard the response and resend the LLMNR
     query over TCP using the unicast address of the responder as the
     destination address.  See  [RFC2181] and Section 2.4 of this
     specification for further discussion of the TC bit.

T    Tentative.  The 'T'entative bit is set in a response if the
     responder is authoritative for the name, but has not yet verified
     the uniqueness of the name.  A responder MUST ignore the 'T' bit in
     a query, if set.  A response with the 'T' bit set is silently
     discarded by the sender, except if it is a uniqueness query, in
     which case a conflict has been detected and a responder MUST
     resolve the conflict as described in Section 4.1.

Z    Reserved for future use.  Implementations of this specification
     MUST set these bits to zero in both queries and responses.  If
     these bits are set in a LLMNR query or response, implementations of
     this specification MUST ignore them.  Since reserved bits could
     conceivably be used for different purposes than in DNS,
     implementors are advised not to enable processing of these bits in
     an LLMNR implementation starting from a DNS code base.

RCODE
     Response code -- this 4 bit field is set as part of LLMNR
     responses.  In an LLMNR query, the sender MUST set RCODE to zero;
     the responder ignores the RCODE and assumes it to be zero.  The
     response to a multicast LLMNR query MUST have RCODE set to zero.  A
     sender MUST silently discard an LLMNR response with a non-zero
     RCODE sent in response to a multicast query.

     If an LLMNR responder is authoritative for the name in a multicast
     query, but an error is encountered, the responder SHOULD send an
     LLMNR response with an RCODE of zero, no RRs in the answer section,
     and the TC bit set.  This will cause the query to be resent using
     TCP, and allow the inclusion of a non-zero RCODE in the response to
     the TCP query.  Responding with the TC bit set is preferable to not
     sending a response, since it enables errors to be diagnosed.
     Errors include those defined in [RFC2845], such as BADSIG(16),
     BADKEY(17) and BADTIME(18).

     Since LLMNR responders only respond to LLMNR queries for names for
     which they are authoritative, LLMNR responders MUST NOT respond
     with an RCODE of 3; instead, they should not respond at all.

     LLMNR implementations MUST support EDNS0 [RFC2671] and extended



Aboba, Thaler & Esibov       Standards Track                    [Page 8]





INTERNET-DRAFT                    LLMNR                   29 August 2005


     RCODE values.

QDCOUNT
     An unsigned 16 bit integer specifying the number of entries in the
     question section.  A sender MUST place only one question into the
     question section of an LLMNR query.  LLMNR responders MUST silently
     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders
     MUST silently discard LLMNR responses with QDCOUNT not equal to
     one.

ANCOUNT
     An unsigned 16 bit integer specifying the number of resource
     records in the answer section.  LLMNR responders MUST silently
     discard LLMNR queries with ANCOUNT not equal to zero.

NSCOUNT
     An unsigned 16 bit integer specifying the number of name server
     resource records in the authority records section.  Authority
     record section processing is described in Section 2.9.  LLMNR
     responders MUST silently discard LLMNR queries with NSCOUNT not
     equal to zero.

ARCOUNT
     An unsigned 16 bit integer specifying the number of resource
     records in the additional records section.  Additional record
     section processing is described in Section 2.9.

2.2.  Sender Behavior

   A sender MAY send an LLMNR query for any legal resource record  type
   (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
   As described in Section 2.4, a sender MAY also send a unicast query.

   The sender MUST anticipate receiving no replies to some LLMNR
   queries, in the event that no responders are available within the
   link-scope.  If no response is received, a resolver treats it as a
   response that the name does not exist (RCODE=3 is returned).  A
   sender can handle duplicate responses by discarding responses with a
   source IP address and ID field that duplicate a response already
   received.

   When multiple valid LLMNR responses are received with the 'C' bit
   set, they SHOULD be concatenated and treated in the same manner that
   multiple RRs received from the same DNS server would be.  However,
   responses with the 'C' bit set SHOULD NOT be concatenated with
   responses with the 'C' bit clear; instead, only the responses with
   the 'C' bit set SHOULD be returned.  If valid LLMNR response(s) are
   received along with error response(s), then the error responses are



Aboba, Thaler & Esibov       Standards Track                    [Page 9]





INTERNET-DRAFT                    LLMNR                   29 August 2005


   silently discarded.

   If error responses are received from both DNS and LLMNR, then the
   lowest RCODE value should be returned. For example, if either DNS or
   LLMNR receives a response with RCODE=0, then this should returned to
   the caller.

   Since the responder may order the RRs in the response so as to
   indicate preference, the sender SHOULD preserve ordering in the
   response to the querying application.

2.3.  Responder Behavior

   An LLMNR response MUST be sent to the sender via unicast.

   Upon configuring an IP address, responders typically will synthesize
   corresponding A, AAAA and PTR RRs so as to be able to respond to
   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
   responder has another RR in addition to the SOA RR;  the SOA RR MUST
   NOT be the only RR that a responder has.  However, in general whether
   RRs are manually or automatically created is an implementation
   decision.

   For example, a host configured to have computer name "host1" and to
   be a member of the "example.com" domain, and with IPv4 address
   192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
   authoritative for the following records:

   host1. IN A 192.0.2.1
          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6

   host1.example.com. IN A 192.0.2.1
          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6

   1.2.0.192.in-addr.arpa. IN PTR host1.
          IN PTR host1.example.com.

   6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
   ip6.arpa IN PTR host1.  (line split for formatting reasons)
            IN PTR host1.example.com.

   An LLMNR responder might be further manually configured with the name
   of a local mail server with an MX RR included in the "host1." and
   "host1.example.com." records.

   In responding to queries:





Aboba, Thaler & Esibov       Standards Track                   [Page 10]





INTERNET-DRAFT                    LLMNR                   29 August 2005


[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
     address(es) defined in Section 2, and on UDP and TCP port 5355 on
     the unicast address(es) that could be set as the source address(es)
     when the responder responds to the LLMNR query.

[b]  Responders MUST direct responses to the port from which the query
     was sent.  When queries are received via TCP this is an inherent
     part of the transport protocol.  For queries received by UDP the
     responder MUST take note of the source port and use that as the
     destination port in the response.  Responses MUST always be sent
     from the port to which they were directed.

[c]  Responders MUST respond to LLMNR queries for names and addresses
     they are authoritative for.  This applies to both forward and
     reverse lookups, with the exception of queries with the 'C' bit
     set, which do not elicit a response.

[d]  Responders MUST NOT respond to LLMNR queries for names they are not
     authoritative for.

[e]  Responders MUST NOT respond using data from the LLMNR or DNS
     resolver cache.

[f]  If a DNS server is running on a host that supports LLMNR, the DNS
     server MUST respond to LLMNR queries only for the RRSets relating
     to the host on which the server is running, but MUST NOT respond
     for other records for which the server is authoritative.  DNS
     servers also MUST NOT send LLMNR queries in order to resolve DNS
     queries.

[g]  If a responder is authoritative for a name, it MUST respond with
     RCODE=0 and an empty answer section, if the type of query does not
     match a RR that the responder has.