投递文章
投稿指南
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
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
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].
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.
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.
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.
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.)
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.
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
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).
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.