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