draft-ietf-dnsext-mdns-33.txt

bind 9.3结合mysql数据库

     responses.  In an LLMNR query, the RCODE MUST be zero, and is
     ignored by the responder.  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 preferrable to
     not sending a response, since it enables errors to be diagnosed.

     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
     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



Esibov, Aboba & Thaler       Standards Track                    [Page 7]





INTERNET-DRAFT                    LLMNR                     18 July 2004


     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.

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, SRV, etc.) to the link-scope multicast address.

   As described in Section 2.4, a sender may also send a unicast query.
   Sections 2 and 3 describe the circumstances in which LLMNR queries
   may be sent.

   The sender MUST anticipate receiving no replies to some LLMNR
   queries, in the event that no responders are available within the
   link-scope or in the event no positive non-null responses exist for
   the transmitted query.  If no positive response is received, a
   resolver treats it 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).

   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



Esibov, Aboba & Thaler       Standards Track                    [Page 8]





INTERNET-DRAFT                    LLMNR                     18 July 2004


   responder has another RR as well;  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
   10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
   authoritative for the following records:

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

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

   1.1.1.10.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.
   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:

[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 SHOULD 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.

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





Esibov, Aboba & Thaler       Standards Track                    [Page 9]





INTERNET-DRAFT                    LLMNR                     18 July 2004


[e]  Responders MUST NOT respond using cached data.

[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 MAY respond with
     RCODE=0 and an empty answer section, if the type of query does not
     match a RR that the responder has.

   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.

   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.".

   In this example (unless this limitation is introduced) 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.  In this example
   a host "child.foo.example.com." would send a dynamic update for the
   NS and glue A record to "foo.example.com.", but this approach



Esibov, Aboba & Thaler       Standards Track                   [Page 10]





INTERNET-DRAFT                    LLMNR                     18 July 2004


   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).

2.5.  "Off link" detection

   For IPv4, an "on link" address is defined as a link-local address
   [IPv4Link] or an address whose prefix belongs to a subnet on the
   local link.  For IPv6 [RFC2460] an "on link" address is either a
   link-local address, defined in [RFC2373], or an address whose prefix
   belongs to a subnet on the local link.

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

   A responder MUST select a source address for responses that is "on
   link". The destination address of an LLMNR response MUST be an "on
   link" 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.




Esibov, Aboba & Thaler       Standards Track                   [Page 11]





INTERNET-DRAFT                    LLMNR                     18 July 2004


   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 Rendezvous.

   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.
   In particular:

   [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.

   Routable addresses MUST be included first in the response, if
   available.  This encourages use of routable address(es) for
   establishment of new connections.






Esibov, Aboba & Thaler       Standards Track                   [Page 12]





INTERNET-DRAFT                    LLMNR                     18 July 2004


2.7.  Retransmission and jitter

   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
   when to retransmit an LLMNR query and how long to collect responses
   to an LLMNR query.

   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
   then a sender MAY repeat the transmission of the query in order to
   assure that it was received by a host capable of responding to it.
   Retransmission of UDP queries SHOULD NOT be attempted more than 3
   times. Where LLMNR queries are sent using TCP, retransmission is
   handled by the transport layer.

   Because an LLMNR sender cannot know in advance if a query sent using
   multicast will receive no response, one response, or more than one
   response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
   collect all possible responses, rather than considering the multicast
   query answered after the first response is received. 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.

   An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
   for each transmission. It is suggested that the computation of
   LLMNR_TIMEOUT be based on the response times for earlier LLMNR
   queries sent on the same interface.

   For example, the algorithms described in RFC 2988 [RFC2988]
   (including exponential backoff) compute an RTO, which is used as the
   value of LLMNR_TIMEOUT.  Smaller values MAY be used for the initial
   RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum
   RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the
   maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).

   Recommended values are an initial RTO of 1 second, a minimum RTO of
   200ms, and a maximum RTO of 5 seconds.  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 100
   ms.  This delay MAY be avoided by responders responding with RRs
   which they have previously determined to be UNIQUE (see Section 4 for
   details).

2.8.  DNS TTL

   The responder should use a pre-configured TTL value in the records
   returned 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.



Esibov, Aboba & Thaler       Standards Track                   [Page 13]