draft-ietf-dnsop-ipv6-dns-issues-09.txt

bind 9.3结合mysql数据库

DNS Operations WG                                              A. Durand
Internet-Draft                                    SUN Microsystems, Inc.
Expires: February 7, 2005                                       J. Ihren
                                                              Autonomica
                                                               P. Savola
                                                               CSC/FUNET
                                                          August 9, 2004



          Operational Considerations and Issues with IPv6 DNS
                draft-ietf-dnsop-ipv6-dns-issues-09.txt


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she 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 February 7, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).  All Rights Reserved.


Abstract


   This memo presents operational considerations and issues with IPv6
   Domain Name System (DNS), including a summary of special IPv6
   addresses, documentation of known DNS implementation misbehaviour,
   recommendations and considerations on how to perform DNS naming for




Durand, et al.          Expires February 7, 2005                [Page 1]
Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004



   service provisioning and for DNS resolver IPv6 support,
   considerations for DNS updates for both the forward and reverse
   trees, and miscellaneous issues.  This memo is aimed to include a
   summary of information about IPv6 DNS considerations for those who
   have experience with IPv4 DNS.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Representing IPv6 Addresses in DNS Records . . . . . . . .  4
     1.2   Independence of DNS Transport and DNS Records  . . . . . .  4
     1.3   Avoiding IPv4/IPv6 Name Space Fragmentation  . . . . . . .  5
     1.4   Query Type '*' and A/AAAA Records  . . . . . . . . . . . .  5
   2.  DNS Considerations about Special IPv6 Addresses  . . . . . . .  5
     2.1   Limited-scope Addresses  . . . . . . . . . . . . . . . . .  6
     2.2   Temporary Addresses  . . . . . . . . . . . . . . . . . . .  6
     2.3   6to4 Addresses . . . . . . . . . . . . . . . . . . . . . .  6
     2.4   Other Transition Mechanisms  . . . . . . . . . . . . . . .  6
   3.  Observed DNS Implementation Misbehaviour . . . . . . . . . . .  7
     3.1   Misbehaviour of DNS Servers and Load-balancers . . . . . .  7
     3.2   Misbehaviour of DNS Resolvers  . . . . . . . . . . . . . .  7
   4.  Recommendations for Service Provisioning using DNS . . . . . .  8
     4.1   Use of Service Names instead of Node Names . . . . . . . .  8
     4.2   Separate vs the Same Service Names for IPv4 and IPv6 . . .  8
     4.3   Adding the Records Only when Fully IPv6-enabled  . . . . .  9
     4.4   Behaviour of Additional Data in IPv4/IPv6 Environments . . 10
       4.4.1   Description of Additional Data Scenarios . . . . . . . 10
       4.4.2   Discussion of the Problems . . . . . . . . . . . . . . 11
     4.5   The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12
     4.6   IPv6 Transport Guidelines for DNS Servers  . . . . . . . . 13
   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . . 13
     5.1   DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14
     5.2   Obtaining a List of DNS Recursive Resolvers  . . . . . . . 15
     5.3   IPv6 Transport Guidelines for Resolvers  . . . . . . . . . 16
   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 16
     6.1   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
     6.2   Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 18
     7.1   Applicability of Reverse DNS . . . . . . . . . . . . . . . 18
     7.2   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19
     7.3   DDNS with Stateless Address Autoconfiguration  . . . . . . 19
     7.4   DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20
     7.5   DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . 21
   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22
     8.1   NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . 22
     8.2   Renumbering Procedures and Applications' Use of DNS  . . . 22
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 22




Durand, et al.          Expires February 7, 2005                [Page 2]
Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004



   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 23
   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 23
   11.2  Informative References . . . . . . . . . . . . . . . . . . . 25
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
   A.  Site-local Addressing Considerations for DNS . . . . . . . . . 28
   B.  Issues about Additional Data or TTL  . . . . . . . . . . . . . 28
       Intellectual Property and Copyright Statements . . . . . . . . 30













































Durand, et al.          Expires February 7, 2005                [Page 3]
Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004



1.  Introduction


   This memo presents operational considerations and issues with IPv6
   DNS; it is meant to be an extensive summary and a list of pointers
   for more information about IPv6 DNS considerations for those with
   experience with IPv4 DNS.


   The purpose of this document is to give information about various
   issues and considerations related to DNS operations with IPv6; it is
   not meant to be a normative specification or standard for IPv6 DNS.


   The first section gives a brief overview of how IPv6 addresses and
   names are represented in the DNS, how transport protocols and
   resource records (don't) relate, and what IPv4/IPv6 name space
   fragmentation means and how to avoid it; all of these are described
   at more length in other documents.


   The second section summarizes the special IPv6 address types and how
   they relate to DNS.  The third section describes observed DNS
   implementation misbehaviours which have a varying effect on the use
   of IPv6 records with DNS.  The fourth section lists recommendations
   and considerations for provisioning services with DNS.  The fifth
   section in turn looks at recommendations and considerations about
   providing IPv6 support in the resolvers.  The sixth and seventh
   sections describe considerations with forward and reverse DNS
   updates, respectively.  The eighth section introduces several
   miscellaneous IPv6 issues relating to DNS for which no better place
   has been found in this memo.  Appendix A looks briefly at the
   requirements for site-local addressing.


1.1  Representing IPv6 Addresses in DNS Records


   In the forward zones, IPv6 addresses are represented using AAAA
   records.  In the reverse zones, IPv6 address are represented using
   PTR records in the nibble format under the ip6.arpa.  tree.  See
   [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
   for background information.


   In particular one should note that the use of A6 records in the
   forward tree or Bitlabels in the reverse tree is not recommended
   [RFC3363].  Using DNAME records is not recommended in the reverse
   tree in conjunction with A6 records; the document did not mean to
   take a stance on any other use of DNAME records [RFC3364].


1.2  Independence of DNS Transport and DNS Records


   DNS has been designed to present a single, globally unique name space
   [RFC2826].  This property should be maintained, as described here and




Durand, et al.          Expires February 7, 2005                [Page 4]
Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004



   in Section 1.3.


   The IP version used to transport the DNS queries and responses is
   independent of the records being queried: AAAA records can be queried
   over IPv4, and A records over IPv6.  The DNS servers must not make
   any assumptions about what data to return for Answer and Authority
   sections based on the underlying transport used in a query.


   However, there is some debate whether the addresses in Additional
   section could be selected or filtered using hints obtained from which
   transport was being used; this has some obvious problems because in
   many cases the transport protocol does not correlate with the
   requests, and because a "bad" answer is in a way worse than no answer
   at all (consider the case where the client is led to believe that a
   name received in the additional record does not have any AAAA records
   at all).


   As stated in [RFC3596]:


      The IP protocol version used for querying resource records is
      independent of the protocol version of the resource records; e.g.,
      IPv4 transport can be used to query IPv6 records and vice versa.



1.3  Avoiding IPv4/IPv6 Name Space Fragmentation


   To avoid the DNS name space from fragmenting into parts where some
   parts of DNS are only visible using IPv4 (or IPv6) transport, the
   recommendation is to always keep at least one authoritative server
   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
   See DNS IPv6 transport guidelines
   [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information.


1.4  Query Type '*' and A/AAAA Records


   QTYPE=* is typically only used for debugging or management purposes;
   it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
   any available RRsets, not *all* the RRsets, because the caches do not
   necessarily have all the RRsets and have no way of guaranteeing that
   they have all the RRsets.  Therefore, to get both A and AAAA records
   reliably, two separate queries must be made.


2.  DNS Considerations about Special IPv6 Addresses


   There are a couple of IPv6 address types which are somewhat special;
   these are considered here.






Durand, et al.          Expires February 7, 2005                [Page 5]
Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004



2.1  Limited-scope Addresses


   The IPv6 addressing architecture [RFC3513] includes two kinds of
   local-use addresses: link-local (fe80::/10) and site-local (fec0::/
   10).  The site-local addresses have been deprecated
   [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in
   Appendix A.


   Link-local addresses should never be published in DNS (whether in
   forward or reverse tree), because they have only local (to the
   connected link) significance
   [I-D.ietf-dnsop-dontpublish-unreachable].


2.2  Temporary Addresses


   Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
   "privacy addresses") use a random number as the interface identifier.
   Publishing (useful) DNS records relating to such addresses would
   defeat the purpose of the mechanism and is not recommended.  However,
   it would still be possible to return a non-identifiable name (e.g.,
   the IPv6 address in hexadecimal format), as described in [RFC3041].