draft-ietf-dnsext-mdns-33.txt

bind 9.3结合mysql数据库

DNSEXT Working Group                                        Levon Esibov
INTERNET-DRAFT                                             Bernard Aboba
Category: Standards Track                                    Dave Thaler
<draft-ietf-dnsext-mdns-33.txt>                                Microsoft
18 July 2004


              Linklocal Multicast Name Resolution (LLMNR)

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society 2004.  All rights reserved.

Abstract

   Today, with the rise of home networking, there are an increasing
   number of ad-hoc networks operating without a Domain Name System
   (DNS) server.  The goal of Link-Local Multicast Name Resolution
   (LLMNR) is to enable name resolution in scenarios in which
   conventional DNS name resolution is not possible.  LLMNR supports all
   current and future DNS formats, types and classes, while operating on
   a separate port from DNS, and with a distinct resolver cache.  Since
   LLMNR only operates on the local link, it cannot be considered a
   substitute for DNS.




Esibov, Aboba & Thaler       Standards Track                    [Page 1]





INTERNET-DRAFT                    LLMNR                     18 July 2004


Table of Contents

1.     Introduction ..........................................    3
   1.1       Requirements ....................................    4
   1.2       Terminology .....................................    4
2.     Name resolution using LLMNR ...........................    4
   2.1       LLMNR packet format .............................    6
   2.2       Sender behavior .................................    8
   2.3       Responder behavior ..............................    8
   2.4       Unicast queries .................................   11
   2.5       Off-link detection ..............................   11
   2.6       Responder responsibilities ......................   12
   2.7       Retransmission and jitter .......................   13
   2.8       DNS TTL .........................................   13
   2.9       Use of the authority and additional sections ....   14
3.     Usage model ...........................................   14
   3.1       LLMNR configuration .............................   15
4.     Conflict resolution ...................................   16
   4.1       Considerations for multiple interfaces ..........   18
   4.2       API issues ......................................   19
5.     Security considerations ...............................   20
   5.1       Scope restriction ...............................   20
   5.2       Usage restriction ...............................   21
   5.3       Cache and port separation .......................   22
   5.4       Authentication ..................................   22
6.     IANA considerations ...................................   22
7.     References ............................................   22
   7.1       Normative References ............................   22
   7.2       Informative References ..........................   23
Acknowledgments ..............................................   24
Authors' Addresses ...........................................   25
Intellectual Property Statement ..............................   25
Disclaimer of Validity .......................................   26
Full Copyright Statement .....................................   26

















Esibov, Aboba & Thaler       Standards Track                    [Page 2]





INTERNET-DRAFT                    LLMNR                     18 July 2004


1.  Introduction

   This document discusses Link Local Multicast Name Resolution (LLMNR),
   which utilizes the DNS packet format and supports all current and
   future DNS formats, types and classes.  LLMNR operates on a separate
   port from the Domain Name System (DNS), with a distinct resolver
   cache.

   The goal of LLMNR is to enable name resolution in scenarios in which
   conventional DNS name resolution is not possible.  These include
   scenarios in which hosts are not configured with the address of a DNS
   server, where configured DNS servers do not reply to a query, or
   where they respond with errors, as described in Section 2.  Since
   LLMNR only operates on the local link, it cannot be considered a
   substitute for DNS.

   Link-scope multicast addresses are used to prevent propagation of
   LLMNR traffic across routers, potentially flooding the network.
   LLMNR queries can also be sent to a unicast address, as described in
   Section 2.4.

   Propagation of LLMNR packets on the local link is considered
   sufficient to enable name resolution in small networks.  The
   assumption is that if a network has a gateway, then the network is
   able to provide DNS server configuration.   Configuration issues are
   discussed in Section 3.1.

   In the future, it may be desirable to consider use of multicast name
   resolution with multicast scopes beyond the link-scope.  This could
   occur if LLMNR deployment is successful, the need arises for
   multicast name resolution beyond the link-scope, or multicast routing
   becomes ubiquitous.  For example, expanded support for multicast name
   resolution might be required for mobile ad-hoc networking scenarios,
   or where no DNS server is available that is authoritative for the
   names of local hosts, and can support dynamic DNS, such as in
   wireless hotspots.

   Once we have experience in LLMNR deployment in terms of
   administrative issues, usability and impact on the network, it will
   be possible to reevaluate which multicast scopes are appropriate for
   use with multicast name resolution.

   Service discovery in general, as well as discovery of DNS servers
   using LLMNR in particular, is outside of the scope of this document,
   as is name resolution over non-multicast capable media.






Esibov, Aboba & Thaler       Standards Track                    [Page 3]





INTERNET-DRAFT                    LLMNR                     18 July 2004


1.1.  Requirements

   In this document, several words are used to signify the requirements
   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

1.2.  Terminology

   This document assumes familiarity with DNS terminology defined in
   [RFC1035].  Other terminology used in this document includes:

Positively Resolved
     Responses with RCODE set to zero are referred to in this document
     as "positively resolved".

Routable Address
     An address other than a Link-Local address.  This includes globally
     routable addresses, as well as private addresses.

Reachable
     An address is considered reachable over a link if either an ARP or
     neighbor discovery cache entry exists for the address on the link.

Responder
     A host that listens to LLMNR queries, and responds to those for
     which it is authoritative.

Sender
     A host that sends an LLMNR query.

2.  Name resolution using LLMNR

   LLMNR is a peer-to-peer name resolution protocol that is not intended
   as a replacement for DNS.  LLMNR queries are sent to and received on
   port 5355.  IPv4 administratively scoped multicast usage is specified
   in "Administratively Scoped IP Multicast" [RFC2365].  The IPv4 link-
   scope multicast address a given responder listens to, and to which a
   sender sends queries, is 224.0.0.252.  The IPv6 link-scope multicast
   address a given responder listens to, and to which a sender sends all
   queries, is FF02:0:0:0:0:0:1:3.

   Typically a host is configured as both an LLMNR sender and a
   responder.  A host MAY be configured as a sender, but not a
   responder.  However, a host configured as a responder MUST act as a
   sender to verify the uniqueness of names as described in Section 4.
   This document does not specify how names are chosen or configured.



Esibov, Aboba & Thaler       Standards Track                    [Page 4]





INTERNET-DRAFT                    LLMNR                     18 July 2004


   This may occur via any mechanism, including DHCPv4 [RFC2131] or
   DHCPv6 [RFC3315].

   LLMNR usage MAY be configured manually or automatically on a per
   interface basis.  By default, LLMNR responders SHOULD be enabled on
   all interfaces, at all times.  Enabling LLMNR for use in situations
   where a DNS server has been configured will result in a change in
   default behavior without a simultaneous update to configuration
   information. Where this is considered undesirable, LLMNR SHOULD NOT
   be enabled by default, so that hosts will neither listen on the link-
   scope multicast address, nor will they send queries to that address.

   An LLMNR sender may send a request for any name.  However, by
   default, LLMNR requests SHOULD be sent only when one of the following
   conditions are met:

   [1] No manual or automatic DNS configuration has been
       performed.  If an interface has been configured with DNS
       server address(es),  then LLMNR SHOULD NOT be used as the
       primary name resolution mechanism on that interface, although
       it MAY be used as a name resolution mechanism of last resort.

   [2] DNS servers do not respond.

   [3] DNS servers respond to a DNS query with RCODE=3
       (Authoritative Name Error) or RCODE=0, and an empty
       answer section.

   A typical sequence of events for LLMNR usage is as follows:

   [a]  DNS servers are not configured or do not respond to a
        DNS query, or respond with RCODE=3, or RCODE=0 and an
        empty answer section.

   [b]  An LLMNR sender sends an LLMNR query to the link-scope
        multicast address(es) defined in Section 2, unless a
        unicast query is indicated.  A sender SHOULD send LLMNR
        queries for PTR RRs via unicast, as specified in Section 2.4.

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

   Further details of sender and responder behavior are provided in the
   sections that follow.



Esibov, Aboba & Thaler       Standards Track                    [Page 5]





INTERNET-DRAFT                    LLMNR                     18 July 2004


2.1.  LLMNR packet format

   LLMNR utilizes 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 permitted by the link
   MTU.

2.1.1.  LLMNR header format

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

                                   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  | Z|TC| Z| 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.

QR   A one bit field that specifies whether this message is an LLMNR
     query (0), or an LLMNR response (1).

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.



Esibov, Aboba & Thaler       Standards Track                    [Page 6]





INTERNET-DRAFT                    LLMNR                     18 July 2004


     LLMNR senders and responders MUST support standard queries (opcode
     value of zero).  LLMNR queries with unsupported OPCODE values MUST
     be silently discarded by responders.

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 an LLMNR response,
     then the sender MAY use the response if it contains all necessary
     information, or the sender MAY 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.

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