draft-ietf-dnsext-mdns-43.txt

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

   As an example, a host configured to respond to LLMNR queries for the
   name "foo.example.com."  is authoritative for the name
   "foo.example.com.".  On receiving an LLMNR query for an A RR with the
   name "foo.example.com." the host authoritatively responds with A
   RR(s) that contain IP address(es) in the RDATA of the resource
   record.  If the responder has a AAAA RR, but no A RR, and an A RR
   query is received, the responder would respond with RCODE=0 and an
   empty answer section.

   In conventional DNS terminology a DNS server authoritative for a zone
   is authoritative for all the domain names under the zone apex except
   for the branches delegated into separate zones.  Contrary to
   conventional DNS terminology, an LLMNR responder is authoritative
   only for the zone apex.



Aboba, Thaler & Esibov       Standards Track                   [Page 11]





INTERNET-DRAFT                    LLMNR                   29 August 2005


   For example the host "foo.example.com." is not authoritative for the
   name "child.foo.example.com." unless the host is configured with
   multiple names, including "foo.example.com."  and
   "child.foo.example.com.".  As a result, "foo.example.com." cannot
   reply to an LLMNR query for "child.foo.example.com." with RCODE=3
   (authoritative name error).  The purpose of limiting the name
   authority scope of a responder is to prevent complications that could
   be caused by coexistence of two or more hosts with the names
   representing child and parent (or grandparent) nodes in the DNS tree,
   for example, "foo.example.com." and "child.foo.example.com.".

   Without the restriction on authority an LLMNR query for an A resource
   record for the name "child.foo.example.com." would result in two
   authoritative responses: RCODE=3 (authoritative name error) received
   from "foo.example.com.", and a requested A record - from
   "child.foo.example.com.".  To prevent this ambiguity, LLMNR enabled
   hosts could perform a dynamic update of the parent (or grandparent)
   zone with a delegation to a child zone;  for example a host
   "child.foo.example.com." could send a dynamic update for the NS and
   glue A record to "foo.example.com.".  However, this approach
   significantly complicates implementation of LLMNR and would not be
   acceptable for lightweight hosts.

2.4.  Unicast Queries and Responses

   Unicast queries SHOULD be sent when:

   [a] A sender repeats a query after it received a response
       with the TC bit set to the previous LLMNR multicast query, or

   [b] The sender queries for a PTR RR of a fully formed IP address
       within the "in-addr.arpa" or "ip6.arpa" zones.

   Unicast LLMNR queries MUST be done using TCP and the responses MUST
   be sent using the same TCP connection as the query.  Senders MUST
   support sending TCP queries, and responders MUST support listening
   for TCP queries. If the sender of a TCP query receives a response to
   that query not using TCP, the response MUST be silently discarded.

   Unicast UDP queries MUST be silently discarded.

   If TCP connection setup cannot be completed in order to send a
   unicast TCP query, this is treated as a response that no records of
   the specified type and class exist for the specified name (it is
   treated the same as a response with RCODE=0 and an empty answer
   section).





Aboba, Thaler & Esibov       Standards Track                   [Page 12]





INTERNET-DRAFT                    LLMNR                   29 August 2005


2.5.  "Off link" Detection

   A sender MUST select a source address for LLMNR queries that is
   assigned on the interface on which the query is sent.  The
   destination address of an LLMNR query MUST be a link-scope multicast
   address or a unicast address.

   A responder MUST select a source address for responses that is
   assigned on the interface on which the query was received.  The
   destination address of an LLMNR response MUST be a unicast address.

   On receiving an LLMNR query, the responder MUST check whether it was
   sent to a LLMNR multicast addresses defined in Section 2.  If it was
   sent to another multicast address, then the query MUST be silently
   discarded.

   Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
   composing an LLMNR query using TCP, the sender MUST set the Hop Limit
   field in the IPv6 header and the TTL field in the IPv4 header of the
   response to one (1).  The responder SHOULD set the TTL or Hop Limit
   settings on the TCP listen socket to one (1) so that SYN-ACK packets
   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
   prevents an incoming connection from off-link since the sender will
   not receive a SYN-ACK from the responder.

   For UDP queries and responses, the Hop Limit field in the IPv6 header
   and the TTL field in the IPV4 header MAY be set to any value.
   However, it is RECOMMENDED that the value 255 be used for
   compatibility with Apple Bonjour [Bonjour].

   Implementation note:

      In the sockets API for IPv4 [POSIX], the IP_TTL and
      IP_MULTICAST_TTL socket options are used to set the TTL of
      outgoing unicast and multicast packets. The IP_RECVTTL socket
      option is available on some platforms to retrieve the IPv4 TTL of
      received packets with recvmsg().  [RFC2292] specifies similar
      options for setting and retrieving the IPv6 Hop Limit.

2.6.  Responder Responsibilities

   It is the responsibility of the responder to ensure that RRs returned
   in LLMNR responses MUST only include values that are valid on the
   local interface, such as IPv4 or IPv6 addresses valid on the local
   link or names defended using the mechanism described in Section 4.
   IPv4 Link-Local addresses are defined in [RFC3927].  IPv6 Link-Local
   addresses are defined in [RFC2373].  In particular:




Aboba, Thaler & Esibov       Standards Track                   [Page 13]





INTERNET-DRAFT                    LLMNR                   29 August 2005


   [a] If a link-scope IPv6 address is returned in a AAAA RR,
       that address MUST be valid on the local link over which
       LLMNR is used.

   [b] If an IPv4 address is returned, it MUST be reachable
       through the link over which LLMNR is used.

   [c] If a name is returned (for example in a CNAME, MX
       or SRV RR), the name MUST be resolvable on the local
       link over which LLMNR is used.

   Where multiple addresses represent valid responses to a query, the
   order in which the addresses are returned is as follows:

   [d] If the source address of the query is a link-scope address,
       then the responder SHOULD include a link-scope address first
       in the response, if available.

   [e] If the source address of the query is a routable address,
       then the responder MUST include a routable address first
       in the response, if available.

2.7.  Retransmission and Jitter

   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
   when to retransmit an LLMNR query.  An LLMNR sender SHOULD either
   estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
   high initial timeout.  Suggested constants are described in Section
   7.

   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
   then a sender SHOULD repeat the transmission of the query in order to
   assure that it was received by a host capable of responding to it,
   while increasing the value of LLMNR_TIMEOUT exponentially.  An LLMNR
   query SHOULD NOT be sent more than three times.

   Where LLMNR queries are sent using TCP, retransmission is handled by
   the transport layer.  Queries with the 'C' bit set MUST be sent using
   multicast UDP and MUST NOT be retransmitted.

   An LLMNR sender cannot know in advance if a query sent using
   multicast will receive no response, one response, or more than one
   response.  An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
   has been received, or if it is necessary to collect all potential
   responses, such as if a uniqueness verification query is being made.
   Otherwise an LLMNR sender SHOULD consider a multicast query answered
   after the first response is received, if that response has the 'C'
   bit clear.



Aboba, Thaler & Esibov       Standards Track                   [Page 14]





INTERNET-DRAFT                    LLMNR                   29 August 2005


   However, if the first response has the 'C' bit set, then the sender
   SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
   responses.  When multiple valid answers are received, they may first
   be concatenated, and then treated in the same manner that multiple
   RRs received from the same DNS server would.  A unicast query sender
   considers the query answered after the first response is received, so
   that it only waits for LLMNR_TIMEOUT if no response has been
   received.

   Since it is possible for a response with the 'C' bit clear to be
   followed by a response with the 'C' bit set, an LLMNR sender SHOULD
   be prepared to process additional responses for the purposes of
   conflict detection and LLMNR_TIMEOUT estimation, even after it has
   considered a query answered.

   In order to avoid synchronization, the transmission of each LLMNR
   query and response SHOULD delayed by a time randomly selected from
   the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
   responders responding with names which they have previously
   determined to be UNIQUE (see Section 4 for details).

2.8.  DNS TTL

   The responder should insert a pre-configured TTL value in the records
   returned in an LLMNR response.  A default value of 30 seconds is
   RECOMMENDED.  In highly dynamic environments (such as mobile ad-hoc
   networks), the TTL value may need to be reduced.

   Due to the TTL minimalization necessary when caching an RRset, all
   TTLs in an RRset MUST be set to the same value.

2.9.  Use of the Authority and Additional Sections

   Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
   concept of delegation.  In LLMNR, the NS resource record type may be
   stored and queried for like any other type, but it has no special
   delegation semantics as it does in the DNS.  Responders MAY have NS
   records associated with the names for which they are authoritative,
   but they SHOULD NOT include these NS records in the authority
   sections of responses.

   Responders SHOULD insert an SOA record into the authority section of
   a negative response, to facilitate negative caching as specified in
   [RFC2308]. The TTL of this record is set from the minimum of the
   MINIMUM field of the SOA record and the TTL of the SOA itself, and
   indicates how long a resolver may cache the negative answer.  The
   owner name of the SOA record (MNAME) MUST be set to the query name.
   The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored



Aboba, Thaler & Esibov       Standards Track                   [Page 15]





INTERNET-DRAFT                    LLMNR                   29 August 2005


   by senders.  Negative responses without SOA records SHOULD NOT be
   cached.

   In LLMNR, the additional section is primarily intended for use by
   EDNS0, TSIG and SIG(0).  As a result, unless the 'C' bit is set,
   senders MAY only include pseudo RR-types in the additional section of
   a query; unless the 'C' bit is set, responders MUST ignore the
   additional section of queries containing other RR types.

   In queries where the 'C' bit is set, the sender SHOULD include the
   conflicting RRs in the additional section.  Since conflict
   notifications are advisory, responders SHOULD log information from
   the additional section, but otherwise MUST ignore the additional
   section.

   Senders MUST NOT cache RRs from the authority or additional section
   of a response as answers, though they may be used for other purposes
   such as negative caching.

3.  Usage Model

   Since LLMNR is a secondary name resolution mechanism, its usage is in
   part determined by the behavior of DNS implementations.  This
   document does not specify any changes to DNS resolver behavior, such
   as searchlist processing or retransmission/failover policy.  However,
   robust DNS resolver implementations are more likely to avoid
   unnecessary LLMNR queries.

   As noted in [DNSPerf], even when DNS servers are configured, a
   significant fraction of DNS queries do not receive a response, or
   result in negative responses due to missing inverse mappings or NS
   records that point to nonexistent or inappropriate hosts.  This has
   the potential to result in a large number of unnecessary LLMNR
   queries.

   [RFC1536] describes common DNS implementation errors and fixes.  If
   the proposed fixes are implemented, unnecessary LLMNR queries will be
   reduced substantially, and so implementation of [RFC1536] is
   recommended.

   For example, [RFC1536] Section 1 describes issues with retransmission
   and recommends implementation of a retransmission policy based on
   round trip estimates, with exponential backoff.  [RFC1536] Section 4
   describes issues with failover, and recommends that resolvers try
   another server when they don't receive a response to a query.  These
   policies are likely to avoid unnecessary LLMNR queries.

   [RFC1536] Section 3 describes zero answer bugs, which if addressed



Aboba, Thaler & Esibov       Standards Track                   [Page 16]