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