    Network Working Group                                          A. Durand
    Request for Comments: 4472                                       Comcast
    Category: Informational                                         J. Ihren
                                                                  Autonomica
                                                                   P. Savola
                                                                   CSC/FUNET
                                                                  April 2006

              Operational Considerations and Issues with IPv6 DNS

    Status of This Memo

       This memo provides information for the Internet community.  It does
       not specify an Internet standard of any kind.  Distribution of this
       memo is unlimited.

    Copyright Notice

       Copyright (C) The Internet Society (2006).

    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 misbehavior,
       recommendations and considerations on how to perform DNS naming for
       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 ....................................................3
          1.1. Representing IPv6 Addresses in DNS Records .................3
          1.2. Independence of DNS Transport and DNS Records ..............4
          1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4
          1.4. Query Type '*' and A/AAAA Records ..........................4
       2. DNS Considerations about Special IPv6 Addresses .................5
          2.1. Limited-Scope Addresses ....................................5
          2.2. Temporary Addresses ........................................5
          2.3. 6to4 Addresses .............................................5
          2.4. Other Transition Mechanisms ................................5
       3. Observed DNS Implementation Misbehavior .........................6
          3.1. Misbehavior of DNS Servers and Load-balancers ..............6
          3.2. Misbehavior of DNS Resolvers ...............................6

    Durand, et al.               Informational                      [Page 1]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       4. Recommendations for Service Provisioning Using DNS ..............7
          4.1. Use of Service Names instead of Node Names .................7
          4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8
          4.3. Adding the Records Only When Fully IPv6-enabled ............8
          4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9
               4.4.1. TTL with Courtesy Additional Data ...................9
               4.4.2. TTL with Critical Additional Data ..................10
          4.5. IPv6 Transport Guidelines for DNS Servers .................10
       5. Recommendations for DNS Resolver IPv6 Support ..................10
          5.1. DNS Lookups May Query IPv6 Records Prematurely ............10
          5.2. Obtaining a List of DNS Recursive Resolvers ...............12
          5.3. IPv6 Transport Guidelines for Resolvers ...................12
       6. Considerations about Forward DNS Updating ......................13
          6.1. Manual or Custom DNS Updates ..............................13
          6.2. Dynamic DNS ...............................................13
       7. Considerations about Reverse DNS Updating ......................14
          7.1. Applicability of Reverse DNS ..............................14
          7.2. Manual or Custom DNS Updates ..............................15
          7.3. DDNS with Stateless Address Autoconfiguration .............16
          7.4. DDNS with DHCP ............................................17
          7.5. DDNS with Dynamic Prefix Delegation .......................17
       8. Miscellaneous DNS Considerations ...............................18
          8.1. NAT-PT with DNS-ALG .......................................18
          8.2. Renumbering Procedures and Applications' Use of DNS .......18
       9. Acknowledgements ...............................................19
       10. Security Considerations .......................................19
       11. References ....................................................20
          11.1. Normative References .....................................20
          11.2. Informative References ...................................22
       Appendix A. Unique Local Addressing Considerations for DNS ........24
       Appendix B. Behavior of Additional Data in IPv4/IPv6
                   Environments ..........................................24
          B.1. Description of Additional Data Scenarios ..................24
          B.2. Which Additional Data to Keep, If Any? ....................26
          B.3. Discussion of the Potential Problems ......................27

    Durand, et al.               Informational                      [Page 2]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    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 misbehaviors that 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.  Appendix B discusses additional data.

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

    Durand, et al.               Informational                      [Page 3]

    RFC 4472              Considerations with IPv6 DNS            April 2006

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

    Durand, et al.               Informational                      [Page 4]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    2.  DNS Considerations about Special IPv6 Addresses

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

    2.1.  Limited-Scope Addresses

       The IPv6 addressing architecture [RFC4291] 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 [WIP-DC2005].

    2.2.  Temporary Addresses

       Temporary addresses defined in RFC 3041 [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 that 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.

       [WIP-H2005] 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 is mentioned as a case of an IPv6 transition mechanism requiring
       special considerations.  In general, mechanisms that 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.

    Durand, et al.               Informational                      [Page 5]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       Note that it does not seem feasible to provide reverse DNS with
       another automatic tunneling mechanism, Teredo [RFC4380]; this is
       because the IPv6 address is based on the IPv4 address and UDP port of
       the current Network Address Translation (NAT) mapping, which is
       likely to be relatively short-lived.

    3.  Observed DNS Implementation Misbehavior

       Several classes of misbehavior 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 misbehavior are extremely severe in IPv6 environments and
       deserve to be mentioned.

    3.1.  Misbehavior of DNS Servers and Load-balancers

       There are several classes of misbehavior in certain DNS servers and
       load-balancers that have been noticed and documented [RFC4074]: 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 time-outs 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 time-out 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.  Misbehavior of DNS Resolvers

       Several classes of misbehavior have also been noticed in DNS
       resolvers [WIP-LB2005].  However, these do not seem to directly
       impair IPv6 use, and are only referred to for completeness.

    Durand, et al.               Informational                      [Page 6]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    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 information about separate services logically
       separate in the DNS by using a different DNS hostname for each
       service.  There are several reasons for doing this, 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., Time to Live
          (TTL)) for each service, and

       o  It allows deciding separately for each service whether or not to
          publish the IPv6 addresses (in cases where 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
       that 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.)

    Durand, et al.               Informational                      [Page 7]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    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 either be added to "service.example.com" or added
       separately under a different name, e.g., in a sub-domain like
       "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 that 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.

    Durand, et al.               Informational                      [Page 8]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       Consider the case of two dual-stack nodes, which both are 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 that 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.

    4.4.  The Use of TTL for IPv4 and IPv6 RRs

       The behavior of DNS caching when different TTL values are used for
       different RRsets of the same name calls for explicit discussion.  For
       example, let's consider two unrelated zone fragments:

          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

       ...

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

       In the former case, we have "courtesy" additional data; in the
       latter, we have "critical" additional data.  See more extensive
       background discussion of additional data handling in Appendix B.

    4.4.1.  TTL with Courtesy Additional Data

       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.  The resolver
       must explicitly query for both A and AAAA records [RFC2821].

       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

    Durand, et al.               Informational                      [Page 9]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       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
       behavior in this scenario is unspecified.

    4.4.2.  TTL with Critical Additional Data

       The difference to courtesy additional data is that the A/AAAA records
       served by the parent zone cannot be queried explicitly.  Therefore,
       after 100 seconds the AAAA record is removed from the cache(s), but
       the A record remains.  Queries for the remaining 200 seconds
       (provided that there are no further queries from the parent that
       could refresh the caches) only return the A record, leading to a
       potential operational situation with unreachable servers.

       Similar cache flushing strategies apply in this scenario; the
       behavior is likewise unspecified.

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

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

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

    Durand, et al.               Informational                     [Page 10]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       3.  The system library might implement a toggle that 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 misbehavior of DNS
       servers and load-balancers, as described in Section 3.1, the lookup
       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 not be optimal, at least
       without information-sharing between the lookup 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 [WIP-RDP2004].  In some cases,
       the implementation may attempt to connect or send a datagram on a
       physical link [WIP-R2006], incurring very long protocol time-outs,
       instead of quickly falling 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 [RFC4038].

       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 time-outs.

    Durand, et al.               Informational                     [Page 11]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       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 that 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 the address has been configured either from a router
       advertisement, Dynamic Host Configuration Protocol for IPv6 (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 the 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
       development work has been reached as of this writing [RFC4339].

       In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
       under consideration for development include the use of [WIP-O2004]
       and the use of Router Advertisements to convey the information
       [WIP-J2006].

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

    Durand, et al.               Informational                     [Page 12]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    6.  Considerations about Forward DNS Updating

       While the topic of 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 that 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 that 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
       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.

    Durand, et al.               Informational                     [Page 13]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       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
       [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b].

       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.

       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
       to 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 [RFC4192]; 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 either to 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

    Durand, et al.               Informational                     [Page 14]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       "authorized" the use of the address (on the premise 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 in the reverse DNS, as justified and described in
       [RFC4025].

       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
       information lookup) in the first place.  At minimum, the applications
       that 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 [WIP-S2005c].

    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.

    Durand, et al.               Informational                     [Page 15]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    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 or not the hosts are
       trusted to update their reverse DNS records.  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 with
       the owner of that address space.  So, assuming a stronger form of
       authorization for reverse DNS updates than an address association is
       generally infeasible.

       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 it 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 that 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.

    Durand, et al.               Informational                     [Page 16]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       One should note that Cryptographically Generated Addresses (CGAs)
       [RFC3972] 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 predictable, a reverse record can only reasonably be
       inserted in the DNS by the node that generates the address.

    7.4.  DDNS with DHCP

       With DHCPv4, the reverse DNS name is typically already inserted to
       the DNS that reflects 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
       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.

    Durand, et al.               Informational                     [Page 17]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       3.  Elsewhere; this implies a relationship between the site and where
           the 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 slightly 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
       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 that
       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 [RFC2766] mangles A records to look
       like AAAA records to the IPv6-only nodes.  Numerous problems have
       been identified with [WIP-AD2005].  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 [RFC4192] is that an application that 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 that run for a long time, this

    Durand, et al.               Informational                     [Page 18]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       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 lookups 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 [RFC4213] 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 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 what 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.

    Durand, et al.               Informational                     [Page 19]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    11.  References

    11.1.  Normative References

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

       [RFC2821]     Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
                     April 2001.

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

    Durand, et al.               Informational                     [Page 20]

    RFC 4472              Considerations with IPv6 DNS            April 2006

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

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

       [RFC4038]     Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
                     Castro, "Application Aspects of IPv6 Transition",
                     RFC 4038, March 2005.

       [RFC4074]     Morishita, Y. and T. Jinmei, "Common Misbehavior
                     Against DNS Queries for IPv6 Addresses", RFC 4074,
                     May 2005.

       [RFC4192]     Baker, F., Lear, E., and R. Droms, "Procedures for
                     Renumbering an IPv6 Network without a Flag Day",
                     RFC 4192, September 2005.

       [RFC4193]     Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
                     Addresses", RFC 4193, October 2005.

       [RFC4291]     Hinden, R. and S. Deering, "IP Version 6 Addressing
                     Architecture", RFC 4291, February 2006.

       [RFC4339]     Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
                     Information Approaches", RFC 4339, February 2006.

    Durand, et al.               Informational                     [Page 21]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    11.2.  Informative References

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

       [RFC3972]     Aura, T., "Cryptographically Generated Addresses
                     (CGA)", RFC 3972, March 2005.

       [RFC4025]     Richardson, M., "A Method for Storing IPsec Keying
                     Material in DNS", RFC 4025, March 2005.

       [RFC4213]     Nordmark, E. and R. Gilligan, "Basic Transition
                     Mechanisms for IPv6 Hosts and Routers", RFC 4213,
                     October 2005.

       [RFC4215]     Wiljakka, J., "Analysis on IPv6 Transition in Third
                     Generation Partnership Project (3GPP) Networks",
                     RFC 4215, October 2005.

       [RFC4380]     Huitema, C., "Teredo: Tunneling IPv6 over UDP through
                     Network Address Translations (NATs)", RFC 4380,
                     February 2006.

       [TC-TEST]     Jinmei, T., "Thread "RFC2181 section 9.1: TC bit
                     handling and additional data" on DNSEXT mailing list,
                     Message-
                     Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August
                     1, 2005, <http://ops.ietf.org/lists/namedroppers/
                     namedroppers.2005/msg01102.html>.

       [WIP-AD2005]  Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
                     Experimental", Work in Progress, October 2005.

       [WIP-DC2005]  Durand, A. and T. Chown, "To publish, or not to
                     publish, that is the question", Work in Progress,
                     October 2005.

    Durand, et al.               Informational                     [Page 22]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       [WIP-H2005]   Huston, G., "6to4 Reverse DNS Delegation
                     Specification", Work in Progress, November 2005.

       [WIP-J2006]   Jeong, J., "IPv6 Router Advertisement Option for DNS
                     Configuration", Work in Progress, January 2006.

       [WIP-LB2005]  Larson, M. and P. Barber, "Observed DNS Resolution
                     Misbehavior", Work in Progress, February 2006.

       [WIP-O2004]   Ohta, M., "Preconfigured DNS Server Addresses", Work in
                     Progress, February 2004.

       [WIP-R2006]   Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
                     Considered Harmful", Work in Progress, January 2006.

       [WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual
                     Stack IPv6 on by Default", Work in Progress, July 2004.

       [WIP-S2005a]  Stapp, M., "The DHCP Client FQDN Option", Work in
                     Progress, March 2006.

       [WIP-S2005b]  Stapp, M., "A DNS RR for Encoding DHCP Information
                     (DHCID RR)", Work in Progress, March 2006.

       [WIP-S2005c]  Senie, D., "Encouraging the use of DNS IN-ADDR
                     Mapping", Work in Progress, August 2005.

       [WIP-SV2005]  Stapp, M. and B. Volz, "Resolution of FQDN Conflicts
                     among DHCP Clients", Work in Progress, March 2006.

    Durand, et al.               Informational                     [Page 23]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    Appendix A.  Unique Local Addressing Considerations for DNS

       Unique local addresses [RFC4193] have replaced the now-deprecated
       site-local addresses [RFC3879].  From the perspective of the DNS, the
       locally generated unique local addresses (LUL) and site-local
       addresses have similar properties.

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

       To actually use 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 local addresses must not be published in the public DNS.

       To facilitate reverse DNS (if desired) with 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 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.  This
       requirement is discussed in [RFC4193].

    Appendix B.  Behavior of Additional Data in IPv4/IPv6 Environments

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

    B.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 above-mentioned condition, as specified in Section
       4.2.1 of [RFC1034].

    Durand, et al.               Informational                     [Page 24]

    RFC 4472              Considerations with IPv6 DNS            April 2006

       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 the TC
           bit, but instead all the non-fitting additional data RRsets
           should be removed.

       An example of the "courtesy" additional data is A/AAAA records in
       conjunction with MX records as shown in Section 4.4; an example of
       the "critical" additional data is shown below (where getting both the
       A and AAAA RRsets is critical with respect to the NS RR):

          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.

       However, the practice may differ from the specification.  Testing and
       code analysis of three recent implementations [TC-TEST] confirm this.
       None of the tested implementations have a strict separation of
       critical and courtesy additional data, while some forms of additional
       data may be treated preferably.  All the implementations remove some
       (critical or courtesy) additional data RRsets without setting the TC
       bit if the response would not otherwise fit.

       Failing to discard the response with the TC bit or omitting critical
       information but not setting the TC bit lead to an unrecoverable
       problem.  Omitting only some of the RRsets if all would not fit (but
       not setting the TC bit) leads to a performance problem.  These are
       discussed in the next two subsections.

    Durand, et al.               Informational                     [Page 25]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    B.2.  Which Additional Data to Keep, If Any?

       NOTE: omitting some critical additional data instead of setting the
       TC bit violates a 'should' in Section 9 of RFC2181.  However, as many
       implementations still do that [TC-TEST], operators need to understand
       its implications, and we describe that behavior as well.

       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.  Omitting all the RRsets (when removing only some would
       suffice) may create a performance penalty, whereby the client may
       need to issue one or more additional queries to obtain necessary
       and/or 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
       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 trade-off between creating an optimization for those
       resolvers that ignore the "should discard" recommendation and 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 trade-off as
       described in the next section.

    Durand, et al.               Informational                     [Page 26]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    B.3.  Discussion of the Potential Problems

       As noted above, the temptation for omitting only some of the
       additional data could be problematic.  This is discussed more below.

       For courtesy additional data, this causes a potential performance
       problem as this requires that the clients issue re-queries for the
       potentially omitted RRsets.  For critical additional data, this
       causes a potential unrecoverable 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 Packet Data Protocol (PDP) context [RFC4215]).
       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, 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 that will be
       returned truncated (or missing some RRsets, depending on
       implementations) to the users.  A protocol fix for this is using
       Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity
       for larger UDP packet sizes, pushing up the relevant threshold.
       Further, DNS server implementations should 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 that would
       result in too much additional data being returned.  Further, DNS
       server implementations should warn of or disallow such zone
       configurations that are recursive or otherwise difficult to manage by
       the protocol.

    Durand, et al.               Informational                     [Page 27]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    Authors' Addresses

       Alain Durand
       Comcast
       1500 Market St.
       Philadelphia, PA  19102
       USA

       EMail: Alain_Durand@cable.comcast.com

       Johan Ihren
       Autonomica
       Bellmansgatan 30
       SE-118 47 Stockholm
       Sweden

       EMail: johani@autonomica.se

       Pekka Savola
       CSC/FUNET
       Espoo
       Finland

       EMail: psavola@funet.fi

    Durand, et al.               Informational                     [Page 28]

    RFC 4472              Considerations with IPv6 DNS            April 2006

    Full Copyright Statement

       Copyright (C) The Internet Society (2006).

       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.

       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.

    Intellectual Property

       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.

    Acknowledgement

       Funding for the RFC Editor function is provided by the IETF
       Administrative Support Activity (IASA).

    Durand, et al.               Informational                     [Page 29]