DNS Operations WG                                              A. Durand
Internet-Draft                                    SUN Microsystems, Inc.
Expires: April 24, 2005                                         J. Ihren
                                                              Autonomica
                                                               P. Savola
                                                               CSC/FUNET
                                                        October 24, 2004



          Operational Considerations and Issues with IPv6 DNS
                draft-ietf-dnsop-ipv6-dns-issues-10.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 April 24, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


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 April 24, 2005                 [Page 1]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 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   Which Additional Data to Keep, If Any? . . . . . . . . 11
       4.4.3   Discussion of the Problems . . . . . . . . . . . . . . 12
     4.5   The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 13
     4.6   IPv6 Transport Guidelines for DNS Servers  . . . . . . . . 14
   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . . 15
     5.1   DNS Lookups May Query IPv6 Records Prematurely . . . . . . 15
     5.2   Obtaining a List of DNS Recursive Resolvers  . . . . . . . 16
     5.3   IPv6 Transport Guidelines for Resolvers  . . . . . . . . . 17
   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 17
     6.1   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17
     6.2   Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . 18
   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 19
     7.1   Applicability of Reverse DNS . . . . . . . . . . . . . . . 19
     7.2   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 20
     7.3   DDNS with Stateless Address Autoconfiguration  . . . . . . 20
     7.4   DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 21
     7.5   DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . 22
   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 23
     8.1   NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . 23
     8.2   Renumbering Procedures and Applications' Use of DNS  . . . 23
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23




Durand, et al.           Expires April 24, 2005                 [Page 2]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 24
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 24
   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 24
   11.2  Informative References . . . . . . . . . . . . . . . . . . . 26
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
   A.  Site-local Addressing Considerations for DNS . . . . . . . . . 29
       Intellectual Property and Copyright Statements . . . . . . . . 30













































Durand, et al.           Expires April 24, 2005                 [Page 3]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 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 April 24, 2005                 [Page 4]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 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 [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 April 24, 2005                 [Page 5]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 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
   [RFC3879], 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.
   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].


2.3  6to4 Addresses


   6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
   a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.


   If the reverse DNS population would be desirable (see Section 7.1 for
   applicability), there are a number of possible ways to do so
   [I-D.moore-6to4-dns], some more applicable than the others.


   The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
   autonomous reverse-delegation system that anyone being capable of
   communicating using a specific 6to4 address would be able to set up a
   reverse delegation to the corresponding 6to4 prefix.  This could be
   deployed by e.g., Regional Internet Registries (RIRs).  This is a
   practical solution, but may have some scalability concerns.


2.4  Other Transition Mechanisms


   6to4, above, is mentioned as a case of an IPv6 transition mechanism
   requiring special considerations.  In general, mechanisms which
   include a special prefix may need a custom solution; otherwise, for
   example when IPv4 address is embedded as the suffix or not embedded
   at all, special solutions are likely not needed.  This is why only
   6to4 and Teredo [I-D.huitema-v6ops-teredo] are described.


   Note that it does not seem feasible to provide reverse DNS with




Durand, et al.           Expires April 24, 2005                 [Page 6]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   another automatic tunneling mechanism, Teredo; this is because the
   IPv6 address is based on the IPv4 address and UDP port of the current
   NAT mapping which is likely to be relatively short-lived.


3.  Observed DNS Implementation Misbehaviour


   Several classes of misbehaviour in DNS servers, load-balancers and
   resolvers have been observed.  Most of these are rather generic, not
   only applicable to IPv6 -- but in some cases, the consequences of
   this misbehaviour are extremely severe in IPv6 environments and
   deserve to be mentioned.


3.1  Misbehaviour of DNS Servers and Load-balancers


   There are several classes of misbehaviour in certain DNS servers and
   load-balancers which have been noticed and documented
   [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations
   silently drop queries for unimplemented DNS records types, or provide
   wrong answers to such queries (instead of a proper negative reply).
   While typically these issues are not limited to AAAA records, the
   problems are aggravated by the fact that AAAA records are being
   queried instead of (mainly) A records.


   The problems are serious because when looking up a DNS name, typical
   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
   to query the AAAA records of the name, and after receiving a
   response, query the A records.  This is done in a serial fashion --
   if the first query is never responded to (instead of properly
   returning a negative answer), significant timeouts will occur.


   In consequence, this is an enormous problem for IPv6 deployments, and
   in some cases, IPv6 support in the software has even been disabled
   due to these problems.


   The solution is to fix or retire those misbehaving implementations,
   but that is likely not going to be effective.  There are some
   possible ways to mitigate the problem, e.g., by performing the
   lookups somewhat in parallel and reducing the timeout as long as at
   least one answer has been received; but such methods remain to be
   investigated; slightly more on this is included in Section 5.


3.2  Misbehaviour of DNS Resolvers


   Several classes of misbehaviour have also been noticed in DNS
   resolvers [I-D.ietf-dnsop-bad-dns-res].  However, these do not seem
   to directly impair IPv6 use, and are only referred to for
   completeness.





Durand, et al.           Expires April 24, 2005                 [Page 7]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



4.  Recommendations for Service Provisioning using DNS


   When names are added in the DNS to facilitate a service, there are
   several general guidelines to consider to be able to do it as
   smoothly as possible.


4.1  Use of Service Names instead of Node Names


   It makes sense to keep logically separate services by a node separate
   in the DNS, due to a number of reasons, for example:


   o  It allows more flexibility and ease for migration of (only a part
      of) services from one node to another,


   o  It allows configuring different properties (e.g., TTL) for each
      service, and


   o  It allows deciding separately for each service whether to publish
      the IPv6 addresses or not (in cases if some services are more
      IPv6-ready than others).


   Using SRV records [RFC2782] would avoid these problems.
   Unfortunately, those are not sufficiently widely used to be
   applicable in most cases.  Hence an operation technique is to use
   service names instead of node names (or, "hostnames").  This
   operational technique is not specific to IPv6, but required to
   understand the considerations described in Section 4.2 and Section
   4.3.


   For example, assume a node named "pobox.example.com" provides both
   SMTP and IMAP service.  Instead of configuring the MX records to
   point at "pobox.example.com", and configuring the mail clients to
   look up the mail via IMAP from "pobox.example.com", one could use
   e.g., "smtp.example.com" for SMTP (for both message submission and
   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
   Note that in the specific case of SMTP relaying, the server itself
   must typically also be configured to know all its names to ensure
   loops do not occur.  DNS can provide a layer of indirection between
   service names and where the service actually is, and using which
   addresses.  (Obviously, when wanting to reach a specific node, one
   should use the hostname rather than a service name.)


4.2  Separate vs the Same Service Names for IPv4 and IPv6


   The service naming can be achieved in basically two ways: when a
   service is named "service.example.com" for IPv4, the IPv6-enabled
   service could be either added to "service.example.com", or added
   separately under a different name, e.g., in a sub-domain, like,




Durand, et al.           Expires April 24, 2005                 [Page 8]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   "service.ipv6.example.com".


   These two methods have different characteristics.  Using a different
   name allows for easier service piloting, minimizing the disturbance
   to the "regular" users of IPv4 service; however, the service would
   not be used transparently, without the user/application explicitly
   finding it and asking for it -- which would be a disadvantage in most
   cases.  When the different name is under a sub-domain, if the
   services are deployed within a restricted network (e.g., inside an
   enterprise), it's possible to prefer them transparently, at least to
   a degree, by modifying the DNS search path; however, this is a
   suboptimal solution.  Using the same service name is the "long-term"
   solution, but may degrade performance for those clients whose IPv6
   performance is lower than IPv4, or does not work as well (see Section
   4.3 for more).


   In most cases, it makes sense to pilot or test a service using
   separate service names, and move to the use of the same name when
   confident enough that the service level will not degrade for the
   users unaware of IPv6.


4.3  Adding the Records Only when Fully IPv6-enabled


   The recommendation is that AAAA records for a service should not be
   added to the DNS until all of following are true:


   1.  The address is assigned to the interface on the node.


   2.  The address is configured on the interface.


   3.  The interface is on a link which is connected to the IPv6
       infrastructure.


   In addition, if the AAAA record is added for the node, instead of
   service as recommended, all the services of the node should be
   IPv6-enabled prior to adding the resource record.


   For example, if an IPv6 node is isolated from an IPv6 perspective
   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
   that it should not have an address in the DNS.


   Consider the case of two dual-stack nodes, which both have IPv6
   enabled, but the server does not have (global) IPv6 connectivity.  As
   the client looks up the server's name, only A records are returned
   (if the recommendations above are followed), and no IPv6
   communication, which would have been unsuccessful, is even attempted.


   The issues are not always so black-and-white.  Usually it's important




Durand, et al.           Expires April 24, 2005                 [Page 9]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   if the service offered using both protocols is of roughly equal
   quality, using the appropriate metrics for the service (e.g.,
   latency, throughput, low packet loss, general reliability, etc.) --
   this is typically very important especially for interactive or
   real-time services.  In many cases, the quality of IPv6 connectivity
   may not yet be equal to that of IPv4, at least globally -- this has
   to be taken into consideration when enabling services
   [I-D.savola-v6ops-6bone-mess].


4.4  Behaviour of Additional Data in IPv4/IPv6 Environments


   DNS responses do not always fit in a single UDP packet.  We'll
   examine the cases which happen when this is due to too much data in
   the Additional Section.


4.4.1  Description of Additional Data Scenarios


   There are two kinds of additional data:


   1.  "critical" additional data; this must be included in all
       scenarios, with all the RRsets, and


   2.  "courtesy" additional data; this could be sent in full, with only
       a few RRsets, or with no RRsets, and can be fetched separately as
       well, but at the cost of additional queries.


   The responding server can algorithmically determine which type the
   additional data is by checking whether it's at or below a zone cut.


   Only those additional data records (even if sometimes carelessly
   termed "glue") are considered "critical" or real "glue" if and only
   if they meet the abovementioned condition, as specified in Section
   4.2.1 of [RFC1034].


   Remember that resource record sets (RRsets) are never "broken up", so
   if a name has 4 A records and 5 AAAA records, you can either return
   all 9, all 4 A records, all 5 AAAA records or nothing.  In
   particular, notice that for the "critical" additional data getting
   all the RRsets can be critical.


   In particular, [RFC2181] specifies (in Section 9) that:


   a.  if all the "critical" RRsets do not fit, the sender should set
       the TC bit, and the recipient should discard the whole response
       and retry using mechanism allowing larger responses such as TCP.


   b.  "courtesy" additional data should not cause the setting of TC
       bit, but instead all the non-fitting additional data RRsets




Durand, et al.           Expires April 24, 2005                [Page 10]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



       should be removed.


   An example of the "courtesy" additional data is A/AAAA records in
   conjunction of MX records is shown in Section 4.5; an example of the
   "critical" additional data is shown below (where getting both the A
   and AAAA RRsets is critical):


      child.example.com.    IN   NS ns.child.example.com.
      ns.child.example.com. IN    A 192.0.2.1
      ns.child.example.com. IN AAAA 2001:db8::1


   When there is too much courtesy additional data, at least the
   non-fitting RRsets should be removed [RFC2181]; however, as the
   additional data is not critical, even all of it could be safely
   removed.


   When there is too much critical additional data, TC bit will have to
   be set, and the recipient should ignore the response and retry using
   TCP; if some data were to be left in the UDP response, the issue is
   which data could be retained.


   Failing to discard the response with TC bit set leads to a protocol
   problem.  Omitting only some of the RRsets if all would not fit leads
   to a performance problem.  These are discussed in Section 4.4.3.


4.4.2  Which Additional Data to Keep, If Any?


   If the implementation decides to keep as much data (whether
   "critical" or "courtesy") as possible in the UDP responses, it might
   be tempting to use the transport of the DNS query as a hint in either
   of these cases: return the AAAA records if the query was done over
   IPv6, or return the A records if the query was done over IPv4.
   However, this breaks the model of independence of DNS transport and
   resource records, as noted in Section 1.2.


   With courtesy additional data, as long as enough RRsets will be
   removed so that TC will not be set, it is allowed to send as many
   complete RRsets as the implementations prefers.  However, the
   implementations are also free to omit all such RRsets, even if
   complete.  Removing all the RRsets if some would not fit obviates a
   performance problem, which would require the users to issue second
   queries to obtain consistent information.


   With critical additional data, the alternatives are either returning
   nothing (and absolutely requiring a retry with TCP) or returning
   something (working also in the case if the recipient does not discard
   the response and retry using TCP) in addition to setting the TC bit.
   If the process for selecting "something" from the critical data would




Durand, et al.           Expires April 24, 2005                [Page 11]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   otherwise be practically "flipping the coin" between A and AAAA
   records, it could be argued that if one looked at the transport of
   the query, it would have a larger possibility of being right than
   just 50/50.  In other words, if the returned critical additional data
   would have to be selected somehow, using something more sophisticated
   than a random process would seem justifiable.


   That is, leaving in some intelligently selected critical additional
   data is a tradeoff between creating an optimization for those
   resolvers which ignore the "should discard" recommendation, and a
   causing a protocol problem by propagating inconsistent information
   about "critical" records in the caches.


   Similarly, leaving in the complete courtesy additional data RRsets
   instead of removing all the RRsets is a performance tradeoff as
   described in the next section.


4.4.3  Discussion of the Problems


   As noted above, the temptation for omitting only some of the
   additional data based on the transport of the query could be
   problematic.  In particular, there appears to be little justification
   for doing so in the case of "courtesy" data.


   For courtesy additional data, this causes a performance problem as
   this requires that the clients issue re-query for the potentially
   omitted RRsets.  For critical additional data, this causes a
   potential protocol problem if the response is not discarded and the
   query not re-tried with TCP, as the nameservers might be reachable
   only through the omitted RRsets.


   If an implementation would look at the transport used for the query,
   it is worth remembering that often the host using the records is
   different from the node requesting them from the authoritative DNS
   server (or even a caching resolver).  So, whichever version the
   requestor (e.g., a recursive server in the middle) uses makes no
   difference to the ultimate user of the records, whose transport
   capabilities might differ from those of the requestor.  This might
   result in e.g., inappropriately returning A records to an IPv6-only
   node, going through a translation, or opening up another IP-level
   session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
   Therefore, at least in many scenarios, it would be very useful if the
   information returned would be consistent and complete -- or if that
   is not feasible, return no misleading information but rather leave it
   to the client to query again.


   The problem of too much additional data seems to be an operational
   one: the zone administrator entering too many records which will be




Durand, et al.           Expires April 24, 2005                [Page 12]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   returned either truncated (or missing some RRsets, depending on
   implementations) to the users.  A protocol fix for this is using
   EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
   pushing up the relevant threshold.  Further, DNS server
   implementations should rather omit courtesy additional data
   completely rather than including only some RRsets [RFC2181].  An
   operational fix for this is having the DNS server implementations
   return a warning when the administrators create zones which would
   result in too much additional data being returned.  Further, DNS
   server implementations should warn of or disallow such zone
   configurations which are recursive or otherwise difficult to manage
   by the protocol.


   Additionally, to avoid the case where an application would not get an
   address at all due to some of "courtesy" additional data being
   omitted, the resolvers should be able to query the specific records
   of the desired protocol, not just rely on getting all the required
   RRsets in the additional section.


4.5  The Use of TTL for IPv4 and IPv6 RRs


   In the previous section, we discussed a danger with queries,
   potentially leading to omitting RRsets from the additional section;
   this could happen to both critical and "courtesy" additional data
   (however, both of these are recommended against in [RFC2181]).  This
   section discusses another problem with courtesy additional data,
   leading to omitting RRsets in cached data, highlighted in the
   IPv4/IPv6 environment.


   The behaviour of DNS caching when different TTL values are used for
   different RRsets of the same name requires explicit discussion.  For
   example, let's consider a part of a zone:


      example.com.        300    IN    MX     foo.example.com.
      foo.example.com.    300    IN    A      192.0.2.1
      foo.example.com.    100    IN    AAAA   2001:db8::1


   When a caching resolver asks for the MX record of example.com, it
   gets back "foo.example.com".  It may also get back either one or both
   of the A and AAAA records in the additional section.  So, there are
   three cases about returning records for the MX in the additional
   section:


   1.  We get back no A or AAAA RRsets: this is the simplest case,
       because then we have to query which information is required
       explicitly, guaranteeing that we get all the information we're
       interested in.





Durand, et al.           Expires April 24, 2005                [Page 13]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   2.  We get back all the RRsets: this is an optimization as there is
       no need to perform more queries, causing lower latency.  However,
       it is impossible to guarantee that in fact we would always get
       back all the records (the only way to ensure that is to send a
       AAAA query for the name after getting the cached reply with A
       records or vice versa).


   3.  We only get back A or AAAA RRsets even if both existed: this is
       indistinguishable from the previous case, and may have
       performance problems at least in certain environments as
       described in the previous section.


   As the third case was considered in the previous section, we assume
   we get back both A and AAAA records of foo.example.com, or the stub
   resolver explicitly asks, in two separate queries, both A and AAAA
   records.


   After 100 seconds, the AAAA record is removed from the cache(s)
   because its TTL expired.  It could be argued to be useful for the
   caching resolvers to discard the A record when the shorter TTL (in
   this case, for the AAAA record) expires; this would avoid the
   situation where there would be a window of 200 seconds when
   incomplete information is returned from the cache.  Further argument
   for discarding is that in the normal operation, the TTL values are so
   high that very likely the incurred additional queries would not be
   noticeable, compared to the obtained performance optimization.  The
   behaviour in this scenario is unspecified.


   To simplify the situation, it might help to use the same TTL for all
   the resource record sets referring to the same name, unless there is
   a particular reason for not doing so.  However, there are some
   scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
   a different strategy is preferable.


   Thus, applications that use the response should not rely on a
   particular TTL configuration.  For example, even if an application
   gets a response that only has the A record in the example described
   above, it should be still aware that there could be a AAAA record for
   "foo.example.com".  That is, the application should try to fetch the
   missing records itself if it needs the record.


4.6  IPv6 Transport Guidelines for DNS Servers


   As described in Section 1.3 and [RFC3901], there should continue to
   be at least one authoritative IPv4 DNS server for every zone, even if
   the zone has only IPv6 records.  (Note that obviously, having more
   servers with robust connectivity would be preferable, but this is the
   minimum recommendation; also see [RFC2182].)




Durand, et al.           Expires April 24, 2005                [Page 14]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



5.  Recommendations for DNS Resolver IPv6 Support


   When IPv6 is enabled on a node, there are several things to consider
   to ensure that the process is as smooth as possible.


5.1  DNS Lookups May Query IPv6 Records Prematurely


   The system library that implements the getaddrinfo() function for
   looking up names is a critical piece when considering the robustness
   of enabling IPv6; it may come in basically three flavours:


   1.  The system library does not know whether IPv6 has been enabled in
       the kernel of the operating system: it may start looking up AAAA
       records with getaddrinfo() and AF_UNSPEC hint when the system is
       upgraded to a system library version which supports IPv6.


   2.  The system library might start to perform IPv6 queries with
       getaddrinfo() only when IPv6 has been enabled in the kernel.
       However, this does not guarantee that there exists any useful
       IPv6 connectivity (e.g., the node could be isolated from the
       other IPv6 networks, only having link-local addresses).


   3.  The system library might implement a toggle which would apply
       some heuristics to the "IPv6-readiness" of the node before
       starting to perform queries; for example, it could check whether
       only link-local IPv6 address(es) exists, or if at least one
       global IPv6 address exists.


   First, let us consider generic implications of unnecessary queries
   for AAAA records: when looking up all the records in the DNS, AAAA
   records are typically tried first, and then A records.  These are
   done in serial, and the A query is not performed until a response is
   received to the AAAA query.  Considering the misbehaviour of DNS
   servers and load-balancers, as described in Section 3.1, the look-up
   delay for AAAA may incur additional unnecessary latency, and
   introduce a component of unreliability.


   One option here could be to do the queries partially in parallel; for
   example, if the final response to the AAAA query is not received in
   0.5 seconds, start performing the A query while waiting for the
   result (immediate parallelism might be unoptimal, at least without
   information sharing between the look-up threads, as that would
   probably lead to duplicate non-cached delegation chain lookups).


   An additional concern is the address selection, which may, in some
   circumstances, prefer AAAA records over A records even when the node
   does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
   In some cases, the implementation may attempt to connect or send a




Durand, et al.           Expires April 24, 2005                [Page 15]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
   incurring very long protocol timeouts, instead of quickly failing
   back to IPv4.


   Now, we can consider the issues specific to each of the three
   possibilities:


   In the first case, the node performs a number of completely useless
   DNS lookups as it will not be able to use the returned AAAA records
   anyway.  (The only exception is where the application desires to know
   what's in the DNS, but not use the result for communication.)  One
   should be able to disable these unnecessary queries, for both latency
   and reliability reasons.  However, as IPv6 has not been enabled, the
   connections to IPv6 addresses fail immediately, and if the
   application is programmed properly, the application can fall
   gracefully back to IPv4 [I-D.ietf-v6ops-application-transition].


   The second case is similar to the first, except it happens to a
   smaller set of nodes when IPv6 has been enabled but connectivity has
   not been provided yet; similar considerations apply, with the
   exception that IPv6 records, when returned, will be actually tried
   first which may typically lead to long timeouts.


   The third case is a bit more complex: optimizing away the DNS lookups
   with only link-locals is probably safe (but may be desirable with
   different lookup services which getaddrinfo() may support), as the
   link-locals are typically automatically generated when IPv6 is
   enabled, and do not indicate any form of IPv6 connectivity.  That is,
   performing DNS lookups only when a non-link-local address has been
   configured on any interface could be beneficial -- this would be an
   indication that either the address has been configured either from a
   router advertisement, DHCPv6 [RFC3315], or manually.  Each would
   indicate at least some form of IPv6 connectivity, even though there
   would not be guarantees of it.


   These issues should be analyzed at more depth, and the fixes found
   consensus on, perhaps in a separate document.


5.2  Obtaining a List of DNS Recursive Resolvers


   In scenarios where DHCPv6 is available, a host can discover a list of
   DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
   option [RFC3646].  This option can be passed to a host through a
   subset of DHCPv6 [RFC3736].


   The IETF is considering the development of alternative mechanisms for
   obtaining the list of DNS recursive name servers when DHCPv6 is
   unavailable or inappropriate.  No decision about taking on this




Durand, et al.           Expires April 24, 2005                [Page 16]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   development work has been reached as of this writing (Aug 2004)
   [I-D.ietf-dnsop-ipv6-dns-configuration].


   In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
   under consideration for development include the use of well-known
   addresses [I-D.ohta-preconfigured-dns] and the use of Router
   Advertisements to convey the information
   [I-D.jeong-dnsop-ipv6-dns-discovery].


   Note that even though IPv6 DNS resolver discovery is a recommended
   procedure, it is not required for dual-stack nodes in dual-stack
   networks as IPv6 DNS records can be queried over IPv4 as well as
   IPv6.  Obviously, nodes which are meant to function without manual
   configuration in IPv6-only networks must implement the DNS resolver
   discovery function.


5.3  IPv6 Transport Guidelines for Resolvers


   As described in Section 1.3 and [RFC3901], the recursive resolvers
   should be IPv4-only or dual-stack to be able to reach any IPv4-only
   DNS server.  Note that this requirement is also fulfilled by an
   IPv6-only stub resolver pointing to a dual-stack recursive DNS
   resolver.


6.  Considerations about Forward DNS Updating


   While the topic how to enable updating the forward DNS, i.e., the
   mapping from names to the correct new addresses, is not specific to
   IPv6, it should be considered especially due to the advent of
   Stateless Address Autoconfiguration [RFC2462].


   Typically forward DNS updates are more manageable than doing them in
   the reverse DNS, because the updater can often be assumed to "own" a
   certain DNS name -- and we can create a form of security relationship
   with the DNS name and the node which is allowed to update it to point
   to a new address.


   A more complex form of DNS updates -- adding a whole new name into a
   DNS zone, instead of updating an existing name -- is considered out
   of scope for this memo as it could require zone-wide authentication.
   Adding a new name in the forward zone is a problem which is still
   being explored with IPv4, and IPv6 does not seem to add much new in
   that area.


6.1  Manual or Custom DNS Updates


   The DNS mappings can also be maintained by hand, in a semi-automatic
   fashion or by running non-standardized protocols.  These are not




Durand, et al.           Expires April 24, 2005                [Page 17]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   considered at more length in this memo.


6.2  Dynamic DNS


   Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized
   mechanism for dynamically updating the DNS.  It works equally well
   with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
   address configuration.  It is important to consider how each of these
   behave if IP address-based authentication, instead of stronger
   mechanisms [RFC3007], was used in the updates.


   1.  manual addresses are static and can be configured


   2.  DHCPv6 addresses could be reasonably static or dynamic, depending
       on the deployment, and could or could not be configured on the
       DNS server for the long term


   3.  SLAAC addresses are typically stable for a long time, but could
       require work to be configured and maintained.


   As relying on IP addresses for Dynamic DNS is rather insecure at
   best, stronger authentication should always be used; however, this
   requires that the authorization keying will be explicitly configured
   using unspecified operational methods.


   Note that with DHCP it is also possible that the DHCP server updates
   the DNS, not the host.  The host might only indicate in the DHCP
   exchange which hostname it would prefer, and the DHCP server would
   make the appropriate updates.  Nonetheless, while this makes setting
   up a secure channel between the updater and the DNS server easier, it
   does not help much with "content" security, i.e., whether the
   hostname was acceptable -- if the DNS server does not include
   policies, they must be included in the DHCP server (e.g., a regular
   host should not be able to state that its name is "www.example.com").
   DHCP-initiated DDNS updates have been extensively described in
   [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
   [I-D.ietf-dnsext-dhcid-rr].


   The nodes must somehow be configured with the information about the
   servers where they will attempt to update their addresses, sufficient
   security material for authenticating themselves to the server, and
   the hostname they will be updating.  Unless otherwise configured, the
   first could be obtained by looking up the authoritative name servers
   for the hostname; the second must be configured explicitly unless one
   chooses to trust the IP address-based authentication (not a good
   idea); and lastly, the nodename is typically pre-configured somehow
   on the node, e.g., at install time.





Durand, et al.           Expires April 24, 2005                [Page 18]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   Care should be observed when updating the addresses not to use longer
   TTLs for addresses than are preferred lifetimes for the addresses, so
   that if the node is renumbered in a managed fashion, the amount of
   stale DNS information is kept to the minimum.  That is, if the
   preferred lifetime of an address expires, the TTL of the record needs
   be modified unless it was already done before the expiration.  For
   better flexibility, the DNS TTL should be much shorter (e.g., a half
   or a third) than the lifetime of an address; that way, the node can
   start lowering the DNS TTL if it seems like the address has not been
   renewed/refreshed in a while.  Some discussion on how an
   administrator could manage the DNS TTL is included in
   [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to
   (smart) hosts as well.


7.  Considerations about Reverse DNS Updating


   Updating the reverse DNS zone may be difficult because of the split
   authority over an address.  However, first we have to consider the
   applicability of reverse DNS in the first place.


7.1  Applicability of Reverse DNS


   Today, some applications use reverse DNS to either look up some hints
   about the topological information associated with an address (e.g.
   resolving web server access logs), or as a weak form of a security
   check, to get a feel whether the user's network administrator has
   "authorized" the use of the address (on the premises that adding a
   reverse record for an address would signal some form of
   authorization).


   One additional, maybe slightly more useful usage is ensuring that the
   reverse and forward DNS contents match (by looking up the pointer to
   the name by the IP address from the reverse tree, and ensuring that a
   record under the name in the forward tree points to the IP address)
   and correspond to a configured name or domain.  As a security check,
   it is typically accompanied by other mechanisms, such as a
   user/password login; the main purpose of the reverse+forward DNS
   check is to weed out the majority of unauthorized users, and if
   someone managed to bypass the checks, he would still need to
   authenticate "properly".


   It may also be desirable to store IPsec keying material corresponding
   to an IP address to the reverse DNS, as justified and described in
   [I-D.ietf-ipseckey-rr].


   It is not clear whether it makes sense to require or recommend that
   reverse DNS records be updated.  In many cases, it would just make
   more sense to use proper mechanisms for security (or topological




Durand, et al.           Expires April 24, 2005                [Page 19]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   information lookup) in the first place.  At minimum, the applications
   which use it as a generic authorization (in the sense that a record
   exists at all) should be modified as soon as possible to avoid such
   lookups completely.


   The applicability is discussed at more length in
   [I-D.ietf-dnsop-inaddr-required].


7.2  Manual or Custom DNS Updates


   Reverse DNS can of course be updated using manual or custom methods.
   These are not further described here, except for one special case.


   One way to deploy reverse DNS would be to use wildcard records, for
   example, by configuring one name for a subnet (/64) or a site (/48).
   As a concrete example, a site (or the site's ISP) could configure the
   reverses of the prefix 2001:db8:f00::/48 to point to one name using a
   wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN PTR
   site.example.com." Naturally, such a name could not be verified from
   the forward DNS, but would at least provide some form of "topological
   information" or "weak authorization" if that is really considered to
   be useful.  Note that this is not actually updating the DNS as such,
   as the whole point is to avoid DNS updates completely by manually
   configuring a generic name.


7.3  DDNS with Stateless Address Autoconfiguration


   Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
   some regard, while being more difficult in another, as described
   below.


   The address space administrator decides whether the hosts are trusted
   to update their reverse DNS records or not.  If they are trusted and
   deployed at the same site (e.g., not across the Internet), a simple
   address-based authorization is typically sufficient (i.e., check that
   the DNS update is done from the same IP address as the record being
   updated); stronger security can also be used [RFC3007].  If they
   aren't allowed to update the reverses, no update can occur.  However,
   such address-based update authorization operationally requires that
   ingress filtering [RFC3704] has been set up at the border of the site
   where the updates occur, and as close to the updater as possible.


   Address-based authorization is simpler with reverse DNS (as there is
   a connection between the record and the address) than with forward
   DNS.  However, when a stronger form of security is used, forward DNS
   updates are simpler to manage because the host can be assumed to have
   an association with the domain.  Note that the user may roam to
   different networks, and does not necessarily have any association




Durand, et al.           Expires April 24, 2005                [Page 20]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   with the owner of that address space -- so, assuming stronger form of
   authorization for reverse DNS updates than an address association is
   generally unfeasible.


   Moreover, the reverse zones must be cleaned up by an unspecified
   janitorial process: the node does not typically know a priori that it
   will be disconnected, and cannot send a DNS update using the correct
   source address to remove a record.


   A problem with defining the clean-up process is that it is difficult
   to ensure that a specific IP address and the corresponding record are
   no longer being used.  Considering the huge address space, and the
   unlikelihood of collision within 64 bits of the interface
   identifiers, a process which would remove the record after no traffic
   has been seen from a node in a long period of time (e.g., a month or
   year) might be one possible approach.


   To insert or update the record, the node must discover the DNS server
   to send the update to somehow, similar to as discussed in Section
   6.2.  One way to automate this is looking up the DNS server
   authoritative (e.g., through SOA record) for the IP address being
   updated, but the security material (unless the IP address-based
   authorization is trusted) must also be established by some other
   means.


   One should note that Cryptographically Generated Addresses
   [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of
   treatment.  CGAs are addresses where the interface identifier is
   calculated from a public key, a modifier (used as a nonce), the
   subnet prefix, and other data.  Depending on the usage profile, CGAs
   might or might not be changed periodically due to e.g., privacy
   reasons.  As the CGA address is not predicatable, a reverse record
   can only reasonably be inserted in the DNS by the node which
   generates the address.


7.4  DDNS with DHCP


   With DHCPv4, the reverse DNS name is typically already inserted to
   the DNS that reflects to the name (e.g., "dhcp-67.example.com").  One
   can assume similar practice may become commonplace with DHCPv6 as
   well; all such mappings would be pre-configured, and would require no
   updating.


   If a more explicit control is required, similar considerations as
   with SLAAC apply, except for the fact that typically one must update
   a reverse DNS record instead of inserting one (if an address
   assignment policy that reassigns disused addresses is adopted) and
   updating a record seems like a slightly more difficult thing to




Durand, et al.           Expires April 24, 2005                [Page 21]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   secure.  However, it is yet uncertain how DHCPv6 is going to be used
   for address assignment.


   Note that when using DHCP, either the host or the DHCP server could
   perform the DNS updates; see the implications in Section 6.2.


   If disused addresses were to be reassigned, host-based DDNS reverse
   updates would need policy considerations for DNS record modification,
   as noted above.  On the other hand, if disused address were not to be
   assigned, host-based DNS reverse updates would have similar
   considerations as SLAAC in Section 7.3.  Server-based updates have
   similar properties except that the janitorial process could be
   integrated with DHCP address assignment.


7.5  DDNS with Dynamic Prefix Delegation


   In cases where a prefix, instead of an address, is being used and
   updated, one should consider what is the location of the server where
   DDNS updates are made.  That is, where the DNS server is located:


   1.  At the same organization as the prefix delegator.


   2.  At the site where the prefixes are delegated to.  In this case,
       the authority of the DNS reverse zone corresponding to the
       delegated prefix is also delegated to the site.


   3.  Elsewhere; this implies a relationship between the site and where
       DNS server is located, and such a relationship should be rather
       straightforward to secure as well.  Like in the previous case,
       the authority of the DNS reverse zone is also delegated.


   In the first case, managing the reverse DNS (delegation) is simpler
   as the DNS server and the prefix delegator are in the same
   administrative domain (as there is no need to delegate anything at
   all); alternatively, the prefix delegator might forgo DDNS reverse
   capability altogether, and use e.g., wildcard records (as described
   in Section 7.2).  In the other cases, it can be slighly more
   difficult, particularly as the site will have to configure the DNS
   server to be authoritative for the delegated reverse zone, implying
   automatic configuration of the DNS server -- as the prefix may be
   dynamic.


   Managing the DDNS reverse updates is typically simple in the second
   case, as the updated server is located at the local site, and
   arguably IP address-based authentication could be sufficient (or if
   not, setting up security relationships would be simpler).  As there
   is an explicit (security) relationship between the parties in the
   third case, setting up the security relationships to allow reverse




Durand, et al.           Expires April 24, 2005                [Page 22]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   DDNS updates should be rather straightforward as well (but IP
   address-based authentication might not be acceptable).  In the first
   case, however, setting up and managing such relationships might be a
   lot more difficult.


8.  Miscellaneous DNS Considerations


   This section describes miscellaneous considerations about DNS which
   seem related to IPv6, for which no better place has been found in
   this document.


8.1  NAT-PT with DNS-ALG


   The DNS-ALG component of NAT-PT mangles A records  to look like AAAA
   records to the IPv6-only nodes.  Numerous problems have been
   identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues].
   This is a strong reason not to use NAT-PT in the first place.


8.2  Renumbering Procedures and Applications' Use of DNS


   One of the most difficult problems of systematic IP address
   renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
   an application which looks up a DNS name disregards information such
   as TTL, and uses the result obtained from DNS as long as it happens
   to be stored in the memory of the application.  For applications
   which run for a long time, this could be days, weeks or even months;
   some applications may be clever enough to organize the data
   structures and functions in such a manner that look-ups get refreshed
   now and then.


   While the issue appears to have a clear solution, "fix the
   applications", practically this is not reasonable immediate advice;
   the TTL information is not typically available in the APIs and
   libraries (so, the advice becomes "fix the applications, APIs and
   libraries"), and a lot more analysis is needed on how to practically
   go about to achieve the ultimate goal of avoiding using the names
   longer than expected.


9.  Acknowledgements


   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
   provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
   Nordmark and Bob Gilligan.  Havard Eidnes and Michael Patton provided
   useful feedback and improvements.  Scott Rose, Rob Austein, Masataka
   Ohta, and Mark Andrews helped in clarifying the issues regarding
   additional data and the use of TTL.  Jefsey Morfin, Ralph Droms,
   Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
   Rob Austein provided useful feedback during the WG last call.  Thomas




Durand, et al.           Expires April 24, 2005                [Page 23]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   Narten provided extensive feedback during the IESG evaluation.


10.  Security Considerations


   This document reviews the operational procedures for IPv6 DNS
   operations and does not have security considerations in itself.


   However, it is worth noting that in particular with Dynamic DNS
   Updates, security models based on the source address validation are
   very weak and cannot be recommended -- they could only be considered
   in the environments where ingress filtering [RFC3704] has been
   deployed.  On the other hand, it should be noted that setting up an
   authorization mechanism (e.g., a shared secret, or public-private
   keys) between a node and the DNS server has to be done manually, and
   may require quite a bit of time and expertise.


   To re-emphasize which was already stated, the reverse+forward DNS
   check provides very weak security at best, and the only
   (questionable) security-related use for them may be in conjunction
   with other mechanisms when authenticating a user.


11.  References


11.1  Normative References


   [I-D.ietf-dnsop-ipv6-dns-configuration]
              Jeong, J., "IPv6 Host Configuration of DNS Server
              Information Approaches",
              draft-ietf-dnsop-ipv6-dns-configuration-04 (work in
              progress), September 2004.


   [I-D.ietf-dnsop-misbehavior-against-aaaa]
              Morishita, Y. and T. Jinmei, "Common Misbehavior against
              DNS Queries for IPv6 Addresses",
              draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in
              progress), April 2004.


   [I-D.ietf-v6ops-application-transition]
              Shin, M., "Application Aspects of IPv6 Transition",
              draft-ietf-v6ops-application-transition-03 (work in
              progress), June 2004.


   [I-D.ietf-v6ops-renumbering-procedure]
              Baker, F., Lear, E. and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day",
              draft-ietf-v6ops-renumbering-procedure-01 (work in
              progress), July 2004.





Durand, et al.           Expires April 24, 2005                [Page 24]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.


   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
              April 1997.


   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.


   [RFC2182]  Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
              July 1997.


   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.


   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
              2671, August 1999.


   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.


   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001.


   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.


   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
              August 2001.


   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
              M. Carney, "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6)", RFC 3315, July 2003.


   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T.
              Hain, "Representing Internet Protocol version 6 (IPv6)
              Addresses in the Domain Name System (DNS)", RFC 3363,
              August 2002.


   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
              August 2002.


   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.




Durand, et al.           Expires April 24, 2005                [Page 25]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
              Extensions to Support IP Version 6", RFC 3596, October
              2003.


   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              December 2003.


   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, April 2004.


   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
              Addresses", RFC 3879, September 2004.


   [RFC3901]  Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
              Guidelines", BCP 91, RFC 3901, September 2004.


11.2  Informative References


   [I-D.durand-v6ops-natpt-dns-alg-issues]
              Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
              draft-durand-v6ops-natpt-dns-alg-issues-00 (work in
              progress), February 2003.


   [I-D.huitema-v6ops-teredo]
              Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              NATs", draft-huitema-v6ops-teredo-02 (work in progress),
              June 2004.


   [I-D.huston-6to4-reverse-dns]
              Huston, G., "6to4 Reverse DNS Delegation",
              draft-huston-6to4-reverse-dns-03 (work in progress),
              October 2004.


   [I-D.ietf-dhc-ddns-resolution]
              Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
              Clients", draft-ietf-dhc-ddns-resolution-08 (work in
              progress), October 2004.


   [I-D.ietf-dhc-fqdn-option]
              Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
              draft-ietf-dhc-fqdn-option-07 (work in progress), July
              2004.


   [I-D.ietf-dnsext-dhcid-rr]
              Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for
              encoding DHCP information (DHCID RR)",
              draft-ietf-dnsext-dhcid-rr-08 (work in progress), July




Durand, et al.           Expires April 24, 2005                [Page 26]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



              2004.


   [I-D.ietf-dnsop-bad-dns-res]
              Larson, M. and P. Barber, "Observed DNS Resolution
              Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in
              progress), July 2004.


   [I-D.ietf-dnsop-dontpublish-unreachable]
              Hazel, P., "IP Addresses that should never appear in the
              public DNS", draft-ietf-dnsop-dontpublish-unreachable-03
              (work in progress), February 2002.


   [I-D.ietf-dnsop-inaddr-required]
              Senie, D., "Requiring DNS IN-ADDR Mapping",
              draft-ietf-dnsop-inaddr-required-05 (work in progress),
              April 2004.


   [I-D.ietf-ipseckey-rr]
              Richardson, M., "A method for storing IPsec keying
              material in DNS", draft-ietf-ipseckey-rr-11 (work in
              progress), July 2004.


   [I-D.ietf-ipv6-unique-local-addr]
              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in
              progress), September 2004.


   [I-D.ietf-send-cga]
              Aura, T., "Cryptographically Generated Addresses (CGA)",
              draft-ietf-send-cga-06 (work in progress), April 2004.


   [I-D.ietf-v6ops-3gpp-analysis]
              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
              Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in
              progress), May 2004.


   [I-D.ietf-v6ops-mech-v2]
              Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06
              (work in progress), September 2004.


   [I-D.ietf-v6ops-onlinkassumption]
              Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
              On-Link Assumption Considered Harmful",
              draft-ietf-v6ops-onlinkassumption-02 (work in progress),
              May 2004.


   [I-D.ietf-v6ops-v6onbydefault]




Durand, et al.           Expires April 24, 2005                [Page 27]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



              Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack
              IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
              (work in progress), July 2004.


   [I-D.jeong-dnsop-ipv6-dns-discovery]
              Jeong, J., "IPv6 DNS Discovery based on Router
              Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02
              (work in progress), July 2004.


   [I-D.moore-6to4-dns]
              Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
              in progress), October 2002.


   [I-D.ohta-preconfigured-dns]
              Ohta, M., "Preconfigured DNS Server Addresses",
              draft-ohta-preconfigured-dns-01 (work in progress),
              February 2004.


   [I-D.savola-v6ops-6bone-mess]
              Savola, P., "Moving from 6bone to IPv6 Internet",
              draft-savola-v6ops-6bone-mess-01 (work in progress),
              November 2002.


   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.


   [RFC2782]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.


   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
              Unique DNS Root", RFC 2826, May 2000.


   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.



Authors' Addresses


   Alain Durand
   SUN Microsystems, Inc.
   17 Network circle UMPL17-202
   Menlo Park, CA  94025
   USA


   EMail: Alain.Durand@sun.com





Durand, et al.           Expires April 24, 2005                [Page 28]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



   Johan Ihren
   Autonomica
   Bellmansgatan 30
   SE-118 47 Stockholm
   Sweden


   EMail: johani@autonomica.se



   Pekka Savola
   CSC/FUNET
   Espoo
   Finland


   EMail: psavola@funet.fi


Appendix A.  Site-local Addressing Considerations for DNS


   As site-local addressing has been deprecated, the considerations for
   site-local addressing are discussed briefly here.  Unique local
   addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed
   as a replacement, but being work-in-progress, it is not considered
   further.


   The interactions with DNS come in two flavors: forward and reverse
   DNS.


   To actually use site-local addresses within a site, this implies the
   deployment of a "split-faced" or a fragmented DNS name space, for the
   zones internal to the site, and the outsiders' view to it.  The
   procedures to achieve this are not elaborated here.  The implication
   is that site-local addresses must not be published in the public DNS.


   To faciliate reverse DNS (if desired) with site-local addresses, the
   stub resolvers must look for DNS information from the local DNS
   servers, not e.g.  starting from the root servers, so that the
   site-local information may be provided locally.  Note that the
   experience of private addresses in IPv4 has shown that the root
   servers get loaded for requests for private address lookups in any
   case.












Durand, et al.           Expires April 24, 2005                [Page 29]


Internet-Draft    Considerations and Issues with IPv6 DNS   October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Durand, et al.           Expires April 24, 2005                [Page 30]