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

非常好的dns解析软件

DNS Operations WG                                              A. Durand
Internet-Draft                                    SUN Microsystems, Inc.
Expires: January 17, 2006                                       J. Ihren
                                                              Autonomica
                                                               P. Savola
                                                               CSC/FUNET
                                                           July 16, 2005


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

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 17, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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
   service provisioning and for DNS resolver IPv6 support,



Durand, et al.          Expires January 17, 2006                [Page 1]

Internet-Draft        Considerations with IPv6 DNS             July 2005


   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 . . . . . .  7
     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   The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
       4.4.1   TTL With Courtesy Additional Data  . . . . . . . . . . 10
       4.4.2   TTL With Critical Additional Data  . . . . . . . . . . 10
     4.5   IPv6 Transport Guidelines for DNS Servers  . . . . . . . . 11
   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . . 11
     5.1   DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
     5.2   Obtaining a List of DNS Recursive Resolvers  . . . . . . . 13
     5.3   IPv6 Transport Guidelines for Resolvers  . . . . . . . . . 13
   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 13
     6.1   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
     6.2   Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 15
     7.1   Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
     7.2   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
     7.3   DDNS with Stateless Address Autoconfiguration  . . . . . . 16
     7.4   DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
     7.5   DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . 18
   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
     8.1   NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . 19
     8.2   Renumbering Procedures and Applications' Use of DNS  . . . 19
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 20
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 20
     11.1  Normative References . . . . . . . . . . . . . . . . . . . 20



Durand, et al.          Expires January 17, 2006                [Page 2]

Internet-Draft        Considerations with IPv6 DNS             July 2005


     11.2  Informative References . . . . . . . . . . . . . . . . . . 22
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
   A.  Unique Local Addressing Considerations for DNS . . . . . . . . 25
   B.  Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25
     B.1   Description of Additional Data Scenarios . . . . . . . . . 26
     B.2   Which Additional Data to Keep, If Any? . . . . . . . . . . 27
     B.3   Discussion of the Potential Problems . . . . . . . . . . . 28
       Intellectual Property and Copyright Statements . . . . . . . . 30











































Durand, et al.          Expires January 17, 2006                [Page 3]

Internet-Draft        Considerations with IPv6 DNS             July 2005


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 unique 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 January 17, 2006                [Page 4]

Internet-Draft        Considerations with IPv6 DNS             July 2005


   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 [RFC3901] 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 January 17, 2006                [Page 5]

Internet-Draft        Considerations with IPv6 DNS             July 2005


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 [RFC3879]
   but are discussed with unique local addresses 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.durand-dnsop-dont-publish].

2.2  Temporary Addresses

   Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
   "privacy addresses") use a random number as the interface identifier.
   Having DNS AAAA records that are updated to always contain the
   current value of a node's temporary address 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].