draft-ietf-dnsop-ipv6-dns-issues-04.txt   draft-ietf-dnsop-ipv6-dns-issues-05.txt 
DNS Operations WG A. Durand DNS Operations WG A. Durand
Internet-Draft SUN Microsystems, Inc. Internet-Draft SUN Microsystems, Inc.
Expires: July 1, 2004 J. Ihren Expires: September 30, 2004 J. Ihren
Autonomica Autonomica
P. Savola P. Savola
CSC/FUNET CSC/FUNET
Jan 2004 Apr 2004
Operational Considerations and Issues with IPv6 DNS Operational Considerations and Issues with IPv6 DNS
draft-ietf-dnsop-ipv6-dns-issues-04.txt draft-ietf-dnsop-ipv6-dns-issues-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 1, 2004. This Internet-Draft will expire on September 30, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo presents operational considerations and issues with IPv6 This memo presents operational considerations and issues with IPv6
Domain Name System (DNS), including a summary of special IPv6 Domain Name System (DNS), including a summary of special IPv6
addresses, documentation of known DNS implementation misbehaviour, addresses, documentation of known DNS implementation misbehaviour,
recommendations and considerations on how to perform DNS naming for recommendations and considerations on how to perform DNS naming for
service provisioning and for DNS resolver IPv6 support, service provisioning and for DNS resolver IPv6 support,
considerations for DNS updates for both the forward and reverse considerations for DNS updates for both the forward and reverse
trees, and miscellaneous issues. This memo is aimed to include a trees, and miscellaneous issues. This memo is aimed to include a
summary of information about IPv6 DNS considerations for those who summary of information about IPv6 DNS considerations for those who
have experience with IPv4 DNS. have experience with IPv4 DNS.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . . . 3 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 3
1.2 Independence of DNS Transport and DNS Records . . . . . . . . 3 1.2 Independence of DNS Transport and DNS Records . . . . . . 3
1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . . . 4 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 4
2. DNS Considerations about Special IPv6 Addresses . . . . . . . 4 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 4
2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . . . 4 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 4
2.2 Privacy (RFC3041) Address . . . . . . . . . . . . . . . . . . 4 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 5
2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 5
3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 5 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 5
3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . . . 5 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 6
3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . . . 6 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 6
4. Recommendations for Service Provisioning using DNS . . . . . . 6 4. Recommendations for Service Provisioning using DNS . . . . . . 6
4.1 Use of Service Names instead of Node Names . . . . . . . . . . 6 4.1 Use of Service Names instead of Node Names . . . . . . . . 6
4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . . . 7 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 7
4.3 Adding the Records Only when Fully IPv6-enabled . . . . . . . 7 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 8
4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . . . 8 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 8
4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments . . . . . . 8 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 9
4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . . . 9 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 10
5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 9 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 10
5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . . . 9 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 10
5.2 Recursive DNS Resolver Discovery . . . . . . . . . . . . . . . 11 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 12
5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . . . 11 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13
6. Considerations about Forward DNS Updating . . . . . . . . . . 11 6. Considerations about Forward DNS Updating . . . . . . . . . . 13
6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 12 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 13
6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 13
7. Considerations about Reverse DNS Updating . . . . . . . . . . 13 7. Considerations about Reverse DNS Updating . . . . . . . . . . 14
7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . . . 13 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 14
7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 14 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 15
7.3 DDNS with Stateless Address Autoconfiguration . . . . . . . . 14 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 15
7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . . . 14 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 16
7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . . . 15 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 17
8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 15 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 18
8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . . . 15 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 18
8.2 Renumbering Procedures and Applications' Use of DNS . . . . . 15 8.2 Renumbering Procedures and Applications' Use of DNS . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Informative References . . . . . . . . . . . . . . . . . . . . 16 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 11.2 Informative References . . . . . . . . . . . . . . . . . . . 19
A. Site-local Addressing Considerations for DNS . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 21 A. Site-local Addressing Considerations for DNS . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
1. Introduction 1. Introduction
This memo presents operational considerations and issues with IPv6 This memo presents operational considerations and issues with IPv6
DNS; it is meant to be an extensive summary and a list of pointers DNS; it is meant to be an extensive summary and a list of pointers
for more information about IPv6 DNS considerations for those with for more information about IPv6 DNS considerations for those with
experience with IPv4 DNS. 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 The first section gives a brief overview of how IPv6 addresses and
names are represented in the DNS, how transport protocols and names are represented in the DNS, how transport protocols and
resource records (don't) relate, and what IPv4/IPv6 name space resource records (don't) relate, and what IPv4/IPv6 name space
fragmentation means and how to avoid it; all of these are described fragmentation means and how to avoid it; all of these are described
at more length in other documents. at more length in other documents.
The second section summarizes the special IPv6 address types and how The second section summarizes the special IPv6 address types and how
they relate to DNS. The third section describes observed DNS they relate to DNS. The third section describes observed DNS
implementation misbehaviours which have a varying effect on the use implementation misbehaviours which have a varying effect on the use
of IPv6 records with DNS. The fourth section lists recommendations of IPv6 records with DNS. The fourth section lists recommendations
skipping to change at page 3, line 35 skipping to change at page 3, line 39
sections describe considerations with forward and reverse DNS sections describe considerations with forward and reverse DNS
updates, respectively. The eighth section introduces several updates, respectively. The eighth section introduces several
miscellaneous IPv6 issues relating to DNS for which no better place miscellaneous IPv6 issues relating to DNS for which no better place
has been found in this memo. Appendix A looks briefly at the has been found in this memo. Appendix A looks briefly at the
requirements for site-local addressing. requirements for site-local addressing.
1.1 Representing IPv6 Addresses in DNS Records 1.1 Representing IPv6 Addresses in DNS Records
In the forward zones, IPv6 addresses are represented using AAAA In the forward zones, IPv6 addresses are represented using AAAA
records. In the reverse zones, IPv6 address are represented using records. In the reverse zones, IPv6 address are represented using
PTR records in the nibble format under the ip6.arpa. -tree. See [1] PTR records in the nibble format under the ip6.arpa. tree. See [1]
for more about IPv6 DNS usage, and [2] or [4] for background for more about IPv6 DNS usage, and [2] or [4] for background
information. information.
In particular one should note that the use of A6 records, DNAME In particular one should note that the use of A6 records in the
records in the reverse tree, or Bitlabels in the reverse tree is not forward tree or Bitlabels in the reverse tree is not recommended [2].
recommended [2]. 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 [5].
1.2 Independence of DNS Transport and DNS Records 1.2 Independence of DNS Transport and DNS Records
DNS has been designed to present a single, globally unique name space DNS has been designed to present a single, globally unique name space
[6]. This property should be maintained, as described here and in [7]. This property should be maintained, as described here and in
Section 1.3. Section 1.3.
In DNS, the IP version used to transport the queries and responses is In DNS, the IP version used to transport the queries and responses is
independent of the records being queried: AAAA records can be queried 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 over IPv4, and A records over IPv6. The DNS servers must not make any
assumptions about what data to return for Answer and Authority assumptions about what data to return for Answer and Authority
sections. sections.
However, there is some debate whether the addresses in Additional However, there is some debate whether the addresses in Additional
section could be selected or filtered using hints obtained from which section could be selected or filtered using hints obtained from which
skipping to change at page 4, line 36 skipping to change at page 4, line 42
IPv4-enabled, and to ensure that recursive DNS servers support IPv4. IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
See DNS IPv6 transport guidelines [3] for more information. See DNS IPv6 transport guidelines [3] for more information.
2. DNS Considerations about Special IPv6 Addresses 2. DNS Considerations about Special IPv6 Addresses
There are a couple of IPv6 address types which are somewhat special; There are a couple of IPv6 address types which are somewhat special;
these are considered here. these are considered here.
2.1 Limited-scope Addresses 2.1 Limited-scope Addresses
The IPv6 addressing architecture [5] includes two kinds of local-use The IPv6 addressing architecture [6] includes two kinds of local-use
addresses: link-local (fe80::/10) and site-local (fec0::/10). The addresses: link-local (fe80::/10) and site-local (fec0::/10). The
site-local addresses are being deprecated [7], and are only discussed site-local addresses are being deprecated [8], and are only discussed
in Appendix A. in Appendix A.
Link-local addresses should never be published in DNS, because they Link-local addresses should never be published in DNS (whether in
have only local (to the connected link) significance [8]. forward or reverse tree), because they have only local (to the
connected link) significance [9].
2.2 Privacy (RFC3041) Address 2.2 Temporary Addresses
Privacy addresses (RFC3041 [9]) use a random number as the interface Temporary addresses defined in RFC3041 [10] (sometimes called
identifier. Publishing DNS records relating to such addresses would "privacy addresses") use a random number as the interface identifier.
defeat the purpose of the mechanism and is not recommended. If Publishing DNS records relating to such addresses would defeat the
absolutely necessary, a mapping could be made to some purpose of the mechanism and is not recommended. If absolutely
non-identifiable name, as described in [9]. necessary, a mapping could be made to some non-identifiable name, as
described in [10].
2.3 6to4 Addresses 2.3 6to4 Addresses
6to4 [10] specifies an automatic tunneling mechanism which maps a 6to4 [11] specifies an automatic tunneling mechanism which maps a
public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
Providing reverse DNS delegation path for such addresses is a Providing reverse DNS delegation path for such addresses is a
challenge. Note that similar difficulties don't surface with the challenge.
other automatic tunneling mechanisms (in particular, providing
reverse DNS information for Teredo [11] hosts whose address includes Note that it does not seem feasible to provide reverse DNS with the
the UDP port of the NAT binding does not seem reasonable). other automatic tunneling mechanism, Teredo [12]; this is because the
IPv6 address is based on the IPv4 address and UDP port of the current
NAT mapping which is likely to be relatively short-lived.
If the reverse DNS population would be desirable (see Section 7.1 for If the reverse DNS population would be desirable (see Section 7.1 for
applicability), there are a number of ways to tackle the delegation applicability), there are a number of ways to tackle the delegation
path problem [12], some more applicable than the others. path problem [13], some more applicable than the others.
The main proposal [13] has been to allocate 2.0.0.2.ip6.arpa. to RIRs The main proposal [14] has been to allocate 2.0.0.2.ip6.arpa. to
and let them do subdelegations in accordance to the delegations of Regional Internet Registries (RIRs) and let them do subdelegations in
the respective IPv4 address space. This has a major practical accordance to the delegations of the respective IPv4 address space.
drawback: those ISPs and IPv4 address space holders where 6to4 is This has a major practical drawback: those ISPs and IPv4 address
being used do not, in general, provide any IPv6 services -- as space holders where 6to4 is being used do not, in general, provide
otherwise, most people would not have to use 6to4 to begin with -- any IPv6 services -- as otherwise, most people would not have to use
and it is improbable that the reverse delegation chain would be 6to4 to begin with -- and it is improbable that the reverse
completed either. In most cases, creating such delegation chains delegation chain would be completed either. In most cases, creating
might just lead to latencies caused by lookups for (almost always) such delegation chains might just lead to latencies caused by lookups
non-existent DNS records. for (almost always) non-existent DNS records.
Another proposal [15] 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., RIRs.
This is a more practical solution, but may have some scalability
concerns.
3. Observed DNS Implementation Misbehaviour 3. Observed DNS Implementation Misbehaviour
Several classes of misbehaviour in DNS servers, load-balancers and Several classes of misbehaviour in DNS servers, load-balancers and
resolvers have been observed. Most of these are rather generic, not resolvers have been observed. Most of these are rather generic, not
only applicable to IPv6 -- but in some cases, the consequences of only applicable to IPv6 -- but in some cases, the consequences of
this misbehaviour are extremely severe in IPv6 environments and this misbehaviour are extremely severe in IPv6 environments and
deserve to be mentioned. deserve to be mentioned.
3.1 Misbehaviour of DNS Servers and Load-balancers 3.1 Misbehaviour of DNS Servers and Load-balancers
There are several classes of misbehaviour in certain DNS servers and There are several classes of misbehaviour in certain DNS servers and
load-balancers which have been noticed and documented [14]: some load-balancers which have been noticed and documented [16]: some
implementations silently drop queries for unimplemented DNS records implementations silently drop queries for unimplemented DNS records
types, or provide wrong answers to such queries (instead of a proper types, or provide wrong answers to such queries (instead of a proper
negative reply). While typically these issues are not limited to negative reply). While typically these issues are not limited to
AAAA records, the problems are aggravated by the fact that AAAA AAAA records, the problems are aggravated by the fact that AAAA
records are being queried instead of (mainly) A records. records are being queried instead of (mainly) A records.
The problems are serious because when looking up a DNS name, typical The problems are serious because when looking up a DNS name, typical
getaddrinfo() implementations, with AF_UNSPEC hint given, first try getaddrinfo() implementations, with AF_UNSPEC hint given, first try
to query the AAAA records of the name, and after receiving a 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 response, query the A records. This is done in a serial fashion -- if
skipping to change at page 6, line 20 skipping to change at page 6, line 38
The solution is to fix or retire those misbehaving implementations, The solution is to fix or retire those misbehaving implementations,
but that is likely not going to be effective. There are some but that is likely not going to be effective. There are some
possible ways to mitigate the problem, e.g. by performing the lookups possible ways to mitigate the problem, e.g. by performing the lookups
somewhat in parallel and reducing the timeout as long as at least one somewhat in parallel and reducing the timeout as long as at least one
answer has been received; but such methods remain to be investigated; answer has been received; but such methods remain to be investigated;
slightly more on this is included in Section 5. slightly more on this is included in Section 5.
3.2 Misbehaviour of DNS Resolvers 3.2 Misbehaviour of DNS Resolvers
Several classes of misbehaviour have also been noticed in DNS Several classes of misbehaviour have also been noticed in DNS
resolvers [15]. However, these do not seem to directly impair IPv6 resolvers [17]. However, these do not seem to directly impair IPv6
use, and are only referred to for completeness. use, and are only referred to for completeness.
4. Recommendations for Service Provisioning using DNS 4. Recommendations for Service Provisioning using DNS
When names are added in the DNS to facilitate a service, there are 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 several general guidelines to consider to be able to do it as
smoothly as possible. smoothly as possible.
4.1 Use of Service Names instead of Node Names 4.1 Use of Service Names instead of Node Names
When a node includes multiple services, one should keep them When a node includes multiple services, one should keep them
logically separate in the DNS. This can be done by the use of logically separate in the DNS. This can be done by the use of
service names instead of node names (or, "hostnames"). 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 For example, assume a node named "pobox.example.com" provides both
SMTP and IMAP service. Instead of configuring the MX records to SMTP and IMAP service. Instead of configuring the MX records to
point at "pobox.example.com", and configuring the mail clients to point at "pobox.example.com", and configuring the mail clients to
look up the mail via IMAP from "pobox.example.com", one should use look up the mail via IMAP from "pobox.example.com", one should use
e.g. "smtp.example.com" for SMTP (for both message submission and e.g. "smtp.example.com" for SMTP (for both message submission and
mail relaying between SMTP servers) and "imap.example.com" for IMAP. mail relaying between SMTP servers) and "imap.example.com" for IMAP.
Note that in the specific case of SMTP relaying, the server itself Note that in the specific case of SMTP relaying, the server itself
must typically also be configured to know all its names to ensure must typically also be configured to know all its names to ensure
loops do not occur. DNS can provide a layer of indirection between loops do not occur. DNS can provide a layer of indirection between
skipping to change at page 8, line 15 skipping to change at page 8, line 38
(if the recommendations above are followed), and no IPv6 (if the recommendations above are followed), and no IPv6
communication, which would have been unsuccessful, is even attempted. communication, which would have been unsuccessful, is even attempted.
The issues are not always so black-and-white. Usually it's important The issues are not always so black-and-white. Usually it's important
if the service offered using both protocols is of roughly equal if the service offered using both protocols is of roughly equal
quality, using the appropriate metrics for the service (e.g., quality, using the appropriate metrics for the service (e.g.,
latency, throughput, low packet loss, general reliability, etc.) -- latency, throughput, low packet loss, general reliability, etc.) --
this is typically very important especially for interactive or this is typically very important especially for interactive or
real-time services. In many cases, the quality of IPv6 connectivity real-time services. In many cases, the quality of IPv6 connectivity
is not yet equal to that of IPv4, at least globally -- this has to be is not yet equal to that of IPv4, at least globally -- this has to be
taken into consideration when enabling services [16]. taken into consideration when enabling services [18].
4.4 The Use of TTL for IPv4 and IPv6 RRs
The behaviour of DNS caching when different TTL values are used for
different records of the same name requires explicit discussion. For
example, let's consider a part of a zone:
example.com. 300 IN MX foo.example.com.
foo.example.com. 300 IN A 192.0.2.1
foo.example.com. 100 IN AAAA 2001:db8::1
Now, when a caching resolver asks for the MX record of example.com,
it gets both A and AAAA records of foo.example.com. Then, after 100
seconds, the AAAA record is removed from the cache because its TTL
expired. Now, subsequent queries only result in the cache returning
the A record; after 200 seconds the A record is purged as well. So,
in this particular case, there is a window of 200 seconds when
incomplete information is returned from the cache.
Therefore, when the same name refers to both A and AAAA records,
these records should have the same TTL. Otherwise, the caches may
return incomplete information about the queried names. More issues
with caching and A/AAAA records is presented in the next section.
4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments
In the previous section, we discussed the effect of impartial data 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments
returned from the caches when the TTLs are not kept the same. Now,
we present another problem highlighted in the mixed IPv4/IPv6
environments.
Consider the case where the query is so long or the number of the Consider thes case where the query name is so long, the number of the
additional ("glue") records is so high that the response must either additional records (originated from "glue") is so high, or for other
be truncated (leading to a retry with TCP) or some of the additional reasons that the response must either be truncated (leading to a
data removed from the reply. Further, resource record sets are never retry with TCP) or some of the additional data removed from the
"broken up", so if a name has 4 A records and 5 AAAA records, you can reply. However, note that if too much additional information that is
either return all 9, all 4 A records, all 5 AAAA records or nothing. not strictly necessary would be added, one should remove unnecessary
information instead of setting TC bit for this "courtesy" information
[19]. Further, resource record sets 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 the case of too much additional data, it might be tempting to not In the case of too much additional data, it might be tempting to not
return the AAAA records if the transport for DNS query was IPv4, or return the AAAA records if the transport for DNS query was IPv4, or
not return the A records, if the transport was IPv6. However, this not return the A records, if the transport was IPv6. However, this
breaks the model of independence of DNS transport and resource breaks the model of independence of DNS transport and resource
records, as noted in Section 1.2. records, as noted in Section 1.2.
This temptation would have significant problems in multiple areas. This temptation would have significant problems in multiple areas.
Remember that often the end-node, which will be using the records, is Remember that often the end-node, which will be using the records, is
not the same one as the node requesting them from the authorative DNS not the same one as the node requesting them from the authoritative
server (or even a caching resolver). So, whichever version the DNS server (or even a caching resolver). So, whichever version the
requestor ("the middleman") uses makes no difference to the ultimate requestor ("the middleman") uses makes no difference to the ultimate
user of the records. This might result in e.g., inappropriately user of the records. This might result in e.g., inappropriately
returning A records to an IPv6-only node, going through a returning A records to an IPv6-only node, going through a
translation, or opening up another IP-level session (e.g., a PDP translation, or opening up another IP-level session (e.g., a PDP
context [31]). context [20]).
The problem of too much additional data seems to be an operational The problem of too much additional data seems to be an operational
one: the zone administrator entering too many records which will be one: the zone administrator entering too many records which will be
returned either truncated or impartial to the users. A protocol fix returned either truncated or impartial to the users. A protocol fix
for this is using EDNS0 [32] to signal the capacity for larger UDP for this is using EDNS0 [40] to signal the capacity for larger UDP
packet sizes, pushing up the relevant threshold. The operational fix packet sizes, pushing up the relevant threshold. The operational fix
for this is having the DNS server implementations return a warning for this is having the DNS server implementations return a warning
when the administrators create the zones which would result in too when the administrators create the zones which would result in too
much additional data being returned. much additional data being returned.
4.5 The Use of TTL for IPv4 and IPv6 RRs
In the previous section, we discussed a danger with queries,
potentially leading to omitting records information from the
additional section. This section describes another problem leading
to omitting records in cached data, highlighted in the IPv4/IPv6
environment.
The behaviour of DNS caching when different TTL values are used for
different records of the same name requires explicit discussion. For
example, let's consider a part of a zone:
example.com. 300 IN MX foo.example.com.
foo.example.com. 300 IN A 192.0.2.1
foo.example.com. 100 IN AAAA 2001:db8::1
When a caching resolver asks for the MX record of example.com, it
gets back "foo.example.com". It may also get back either one or both
of the A and AAAA records in the additional section. So, there are
three cases about returning records for the MX in the additional
section:
1. We get back no A or AAAA records: this is the simplest case,
because then we have to query which information is required
explicitly, guaranteeing that we get all the information we're
interested in.
2. We get back all the records: this is an optimization as there is
no need to perform more queries, causing lower latency. However,
it is impossible to guarantee that in fact we would always get
back all the records (the only way to ensure that is to send a
AAAA query for the name after getting the cached reply); however,
one could try to work in the direction to try to ensure it as far
as possible.
3. We only get back A or AAAA records even if both existed: this is
indistinguishable from the previous case, and problematic as
described in the next section.
So, we assume we get back both A and AAAA records of foo.example.com,
or the resolver explicitly asks, in two separate queries, both A and
AAAA records. After 100 seconds, the AAAA record is removed from the
cache because its TTL expired. It would be useful for the cache to
re-query the AAAA record or 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. However, this is
not mandated or mentioned by the specification(s).
To simplify the situation, it is recommended to use the same TTL for
all the records referring to the same name. However, there are some
scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
a different strategy is preferable.
4.6 IPv6 Transport Guidelines for DNS Servers 4.6 IPv6 Transport Guidelines for DNS Servers
As described in Section 1.3 and [3], there should continue to be at As described in Section 1.3 and [3], there should continue to be at
least one authorative IPv4 DNS server for every zone, even if the least one authoritative IPv4 DNS server for every zone, even if the
zone has only IPv6 records. (Note that obviously, having more servers zone has only IPv6 records. (Note that obviously, having more servers
with robust connectivity would be preferable, but this is the minimum with robust connectivity would be preferable, but this is the minimum
recommendation; also see [17].) recommendation; also see [21].)
5. Recommendations for DNS Resolver IPv6 Support 5. Recommendations for DNS Resolver IPv6 Support
When IPv6 is enabled on a node, there are several things to consider When IPv6 is enabled on a node, there are several things to consider
to ensure that the process is as smooth as possible. to ensure that the process is as smooth as possible.
5.1 DNS Lookups May Query IPv6 Records Prematurely 5.1 DNS Lookups May Query IPv6 Records Prematurely
The system library that implements the getaddrinfo() function for The system library that implements the getaddrinfo() function for
looking up names is a critical piece when considering the robustness looking up names is a critical piece when considering the robustness
skipping to change at page 10, line 37 skipping to change at page 11, line 41
One option here could be to do the queries partially in parallel; for 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 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 0.5 seconds, start performing the A query while waiting for the
result (immediate parallelism might be unoptimal without information result (immediate parallelism might be unoptimal without information
sharing between the look-up threads, as that would probably lead to sharing between the look-up threads, as that would probably lead to
duplicate non-cached delegation chain lookups). duplicate non-cached delegation chain lookups).
An additional concern is the address selection, which may, in some An additional concern is the address selection, which may, in some
circumstances, prefer AAAA records over A records, even when the node circumstances, prefer AAAA records over A records, even when the node
does not have any IPv6 connectivity [18]. In some cases, the does not have any IPv6 connectivity [22]. In some cases, the
implementation may attempt to connect or send a datagram on a implementation may attempt to connect or send a datagram on a
physical link [19], incurring very long protocol timeouts, instead of physical link [23], incurring very long protocol timeouts, instead of
quickly failing back to IPv4. quickly failing back to IPv4.
Now, we can consider the issues specific to each of the three Now, we can consider the issues specific to each of the three
possibilities: possibilities:
In the first case, the node performs a number of completely useless 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 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 anyway. (The only exception is where the application desires to know
what's in the DNS, but not use the result for communication.) One what's in the DNS, but not use the result for communication.) One
should be able to disable these unnecessary queries, for both latency should be able to disable these unnecessary queries, for both latency
and reliability reasons. However, as IPv6 has not been enabled, the and reliability reasons. However, as IPv6 has not been enabled, the
connections to IPv6 addresses fail immediately, and if the connections to IPv6 addresses fail immediately, and if the
application is programmed properly, the application can fall application is programmed properly, the application can fall
gracefully back to IPv4 [20]. gracefully back to IPv4 [24].
The second case is similar to the first, except it happens to a 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 smaller set of nodes when IPv6 has been enabled but connectivity has
not been provided yet; similar considerations apply, with the not been provided yet; similar considerations apply, with the
exception that IPv6 records, when returned, will be actually tried exception that IPv6 records, when returned, will be actually tried
first which may typically lead to long timeouts. first which may typically lead to long timeouts.
The third case is a bit more complex: optimizing away the DNS lookups 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 with only link-locals is probably safe (but may be desirable with
different lookup services which getaddrinfo() may support), as the different lookup services which getaddrinfo() may support), as the
link-locals are typically automatically generated when IPv6 is link-locals are typically automatically generated when IPv6 is
enabled, and do not indicate any form of IPv6 connectivity. That enabled, and do not indicate any form of IPv6 connectivity. That
is, performing DNS lookups only when a non-link-local address has is, performing DNS lookups only when a non-link-local address has
been configured on any interface could be beneficial -- this would be been configured on any interface could be beneficial -- this would be
an indication that either the address has been configured either from an indication that either the address has been configured either from
a router advertisement, DHCPv6, or manually. Each would indicate at a router advertisement, DHCPv6 [25], or manually. Each would
least some form of IPv6 connectivity, even though there would not be indicate at least some form of IPv6 connectivity, even though there
guarantees of it. would not be guarantees of it.
These issues should be analyzed at more depth, and the fixes found These issues should be analyzed at more depth, and the fixes found
consensus on, perhaps in a separate document. consensus on, perhaps in a separate document.
5.2 Recursive DNS Resolver Discovery 5.2 Obtaining a List of DNS Recursive Resolvers
Recursive IPv6 DNS resolver discovery is a subject of active debate In scenarios where DHCPv6 is available, a host can discover a list of
at the moment: the main proposed mechanisms include the use of DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
well-known addresses [21], the use of Router Advertisements to convey option [29]. This option can be passed to a host through a subset of
the information [22], and using DHCPv6 (or the stateless subset of it DHCPv6 [28].
[23]) for DNS resolver configuration. No consensus has been reached
yet.
Note that IPv6 DNS resolver discovery, while an important topic, is The IETF is considering the development of alternative mechanisms for
not required for dual-stack nodes in dual-stack networks: IPv6 DNS obtaining the list of DNS recursive name servers when DHCPv6 is
records can very well be queried over IPv4 as well. unavailable or inappropriate. No decision about taking on this
development work has been reached as of this writing (April 2004).
In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
under consideration for development of dnsop WG include the use of
well-known addresses [26], the use of Router Advertisements to convey
the information [27].
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.
5.3 IPv6 Transport Guidelines for Resolvers 5.3 IPv6 Transport Guidelines for Resolvers
As described in Section 1.3 and [3], the recursive resolvers should As described in Section 1.3 and [3], the recursive resolvers should
be IPv4-only or dual-stack to be able to reach any IPv4-only DNS 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 server. Note that this requirement is also fulfilled by an IPv6-only
stub resolver pointing to a dual-stack recursive DNS resolver. stub resolver pointing to a dual-stack recursive DNS resolver.
6. Considerations about Forward DNS Updating 6. Considerations about Forward DNS Updating
While the topic how to enable updating the forward DNS, i.e., the While the topic how to enable updating the forward DNS, i.e., the
mapping from names to the correct new addresses, is not specific to mapping from names to the correct new addresses, is not specific to
IPv6, it bears thinking about especially due to adding Stateless IPv6, it bears thinking about especially due to adding Stateless
Address Autoconfiguration [24] to the mix. Address Autoconfiguration [30] to the mix.
Typically forward DNS updates are more manageable than doing them in Typically forward DNS updates are more manageable than doing them in
the reverse DNS, because the updater can, typically, be assumed to the reverse DNS, because the updater can, typically, be assumed to
"own" a certain DNS name -- and we can create a form of security "own" a certain DNS name -- and we can create a form of security
association with the DNS name and the node allowed to update it to relationship with the DNS name and the node allowed to update it to
point to a new address. point to a new address.
A more complex form of DNS updates -- adding a whole new name to a A more complex form of DNS updates -- adding a whole new name into a
DNS zone, instead of updating an existing name -- is considered DNS zone, instead of updating an existing name -- is considered out
out-of-scope: this is not an IPv6-specific problem, and one still of scope for this memo. Adding a new name in the forward zone is a
being explored. problem which is still being explored with IPv4, and IPv6 does not
seem to add much new in that area.
6.1 Manual or Custom DNS Updates 6.1 Manual or Custom DNS Updates
The DNS mappings can be maintained by hand, in a semi-automatic The DNS mappings can be maintained by hand, in a semi-automatic
fashion or by running non-standardized protocols. These are not fashion or by running non-standardized protocols. These are not
considered at more length in this memo. considered at more length in this memo.
6.2 Dynamic DNS 6.2 Dynamic DNS
Dynamic DNS updates (DDNS) [25][26] is a standardized mechanism for Dynamic DNS updates (DDNS) [31][32] is a standardized mechanism for
dynamically updating the DNS. It works equally well with stateless dynamically updating the DNS. It works equally well with stateless
address autoconfiguration (SLAAC), DHCPv6 or manual address address autoconfiguration (SLAAC), DHCPv6 or manual address
configuration. The only (minor) twist is that with SLAAC, the DNS configuration. The only (minor) twist is that with SLAAC, the DNS
server cannot tie the authentication of the user to the IP address, server cannot tie the authentication of the user to the IP address,
and stronger mechanisms must be used. Actually, relying on IP and stronger mechanisms must be used [32]. As relying on IP
addresses for Dynamic DNS is rather insecure at best, so this is addresses for Dynamic DNS is rather insecure at best, stronger
probably not a significant problem (but requires that the authentication should always be used; however, this requires that the
authorization keying will be explicitly configured). authorization keying will be explicitly configured using unspecified
operational methods.
Note that with DHCP, it is also possible that the DHCP server updates 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 the DNS, not the host. The host might only indicate in the DHCP
exchange which hostname it would prefer, and the DHCP server would exchange which hostname it would prefer, and the DHCP server would
make the appropriate updates. Nonetheless, while this makes setting make the appropriate updates. Nonetheless, while this makes setting
up a secure channel between the updater and the DNS server easier, it up a secure channel between the updater and the DNS server easier, it
does not help much with "content" security, i.e., whether the does not help much with "content" security, i.e., whether the
hostname was acceptable -- if the DNS server does not include hostname was acceptable -- if the DNS server does not include
policies, they must be included in the DHCP server (e.g., a regular 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"). host should not be able to state that its name is "www.example.com").
DHCP-initiated DDNS updates have been extensively described in [33],
[34] and [35].
The nodes must somehow be configured with the information about the The nodes must somehow be configured with the information about the
servers where they will attempt to update their addresses, sufficient servers where they will attempt to update their addresses, sufficient
security material for authenticating themselves to the server, and security material for authenticating themselves to the server, and
the hostname they will be updating. Unless otherwise configured, the the hostname they will be updating. Unless otherwise configured, the
first could be obtained by looking up the authorative name servers first could be obtained by looking up the authoritative name servers
for the hostname; the second must be configured explicitly unless one for the hostname; the second must be configured explicitly unless one
chooses to trust the IP address -based authentication (not a good chooses to trust the IP address -based authentication (not a good
idea); and lastly, the nodename is typically pre-configured somehow idea); and lastly, the nodename is typically pre-configured somehow
on the node, e.g. at install time. on the node, e.g. at install time.
Care should be observed when updating the addresses not to use longer Care should be observed when updating the addresses not to use longer
TTLs for addresses than are preferred lifetimes for the TTLs for addresses than are preferred lifetimes for the
autoconfigured addresses, so that if the node is renumbered in a autoconfigured addresses, so that if the node is renumbered in a
managed fashion, the amount of stale DNS information is kept to the managed fashion, the amount of stale DNS information is kept to the
minimum. Actually, the DNS TTL should be much shorter (e.g., a half minimum. That is, if the preferred lifetime of an address expires,
or a third) than the lifetime of an address; that way, the node can the TTL of the record needs be modified unless it was already done
start lowering the DNS TTL if it seems like the address has not be before the expiration. For better flexibility, the DNS TTL should be
renewed/refreshed in a while. Some discussion on how to manage the much shorter (e.g., a half or a third) than the lifetime of an
DNS TTL is included in [28]. 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 [37]; this could be applied to (smart) hosts as well.
7. Considerations about Reverse DNS Updating 7. Considerations about Reverse DNS Updating
Forward DNS updating is rather straightforward; reverse DNS is Updating the reverse DNS zone may be difficult because of the split
significantly trickier especially with certain mechanisms. However, authority over an address. However, first we have to consider the
first it makes sense to look at the applicability of reverse DNS in applicability of reverse DNS in the first place.
the first place.
7.1 Applicability of Reverse DNS 7.1 Applicability of Reverse DNS
Today, some applications use reverse DNS to either look up some hints Today, some applications use reverse DNS to either look up some hints
about the topological information associated with an address (e.g. about the topological information associated with an address (e.g.
resolving web server access logs), or as a weak form of a security 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 check, to get a feel whether the user's network administrator has
"authorized" the use of the address (on the premises that adding a "authorized" the use of the address (on the premises that adding a
reverse record for an address would signal some form of reverse record for an address would signal some form of
authorization). authorization).
skipping to change at page 13, line 51 skipping to change at page 15, line 22
authenticate "properly". authenticate "properly".
It is not clear whether it makes sense to require or recommend that 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 reverse DNS records be updated. In many cases, it would just make
more sense to use proper mechanisms for security (or topological more sense to use proper mechanisms for security (or topological
information lookup) in the first place. At minimum, the applications information lookup) in the first place. At minimum, the applications
which use it as a generic authorization (in the sense that a record which use it as a generic authorization (in the sense that a record
exists at all) should be modified as soon as possible to avoid such exists at all) should be modified as soon as possible to avoid such
lookups completely. lookups completely.
The applicability is discussed at more length in [29]. The applicability is discussed at more length in [38].
7.2 Manual or Custom DNS Updates 7.2 Manual or Custom DNS Updates
Reverse DNS can of course be updated using manual or custom methods. Reverse DNS can of course be updated using manual or custom methods.
These are not further described here, except for one special case. These are not further described here, except for one special case.
One way to deploy reverse DNS would be to use wildcard records, for 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). example, by configuring one name for a subnet (/64) or a site (/48).
Naturally, such a name could not be verified from the forward DNS, As a concrete example, a site (or the site's ISP) could configure the
but would at least provide some form of "topological information" or reverses of the prefix 2001:db8:f00::/48 to point to one name using a
"weak authorization" if that is really considered to be useful. Note wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
that this is not actually updating the DNS as such, as the whole site.example.com." Naturally, such a name could not be verified from
point is to avoid DNS updates completely by manually configuring a the forward DNS, but would at least provide some form of "topological
generic name. 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 7.3 DDNS with Stateless Address Autoconfiguration
Dynamic DNS with SLAAC is a bit complicated, but manageable with a Dynamic DNS with SLAAC simpler than forward DNS updates in some
rather low form of security with some implementation. regard, while being more difficult in another.
Every node on a link must then be allowed to insert its own reverse The address space administrator decides whether the hosts are trusted
DNS record in the reverse zone. However, in the typical case, there to update their reverse DNS records or not. If they are, a simple
can be no stronger form of authentication between the nodes and the address-based authorization is typically sufficient (i.e., check that
server than the source IP address (the user may roam to other the DNS update is done from the same IP address as the record being
administrative domains as well, requiring updates to foreign DNS updated); stronger security can also be used [32]. If they aren't
servers), which might make attacks more lucrative. allowed to update the reverses, no update can occur.
Moreover, the reverse zones must be cleaned up by some janitorial Address-based authorization is simpler with reverse DNS (as there is
process: the node does not typically know a priori that it will be a connection between the record and the address) than with forward
disconnected, and cannot send a DNS update using the correct source DNS. However, when stronger form of security is used, forward DNS
address to remove a record. updates are simpler to manage because the host knows the record it's
updating, and 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 stronger form of authorization for reverse DNS
updates than an address association is generally unfeasible.
Moreover, the reverse zones must be cleaned up by an unspecified
janitorial process: the node does not typically know a priori that it
will be disconnected, and cannot send a DNS update using the correct
source address to remove a record.
A problem with defining the clean-up process is that it is difficult
to ensure that a specific IP address and the corresponding record are
no longer being used. Considering the huge address space, and the
unlikelihood of collision within 64 bits of the interface
identifiers, a process which would remove the record after no traffic
has been seen from a node in a long period of time (e.g., a month or
year) might be one possible approach.
To insert or update the record, the node must discover the DNS server To insert or update the record, the node must discover the DNS server
to send the update to somehow, similar to as discussed in Section 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 6.2. One way to automate this is looking up the DNS server
authoritative for the IP address being updated, but the security authoritative (e.g., through SOA record) for the IP address being
material (unless the IP address -based authorization is trusted) must updated, but the security material (unless the IP address-based
also be established by some other means. authorization is trusted) must also be established by some other
means.
7.4 DDNS with DHCP 7.4 DDNS with DHCP
With DHCP, the reverse DNS name is typically already inserted to the With DHCPv4, the reverse DNS name is typically already inserted to
DNS that reflects to the name (e.g., "dhcp-67.example.com"). This is the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One
pre-configured, and requires no updating. 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 If a more explicit control is required, similar considerations as
with SLAAC apply, except for the fact that typically one must update with SLAAC apply, except for the fact that typically one must update
a reverse DNS record instead of inserting one -- due to a denser a reverse DNS record instead of inserting one (if an address
address assignment policy -- and updating a record seems like a assignment policy that reassigns disused addresses is adopted) and
slightly more difficult thing to secure. 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 Note that when using DHCP, either the host or the DHCP server could
perform the DNS updates; see the implications in Section 6.2. 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 7.5 DDNS with Dynamic Prefix Delegation
In cases where more than one address is being used and updated, one In cases where a prefix, instead of an address, is being used and
should consider where the updated server resides. That is, whether updated, one should consider what is the location of the server where
the prefixes have been delegated to a node in the local site, or DDNS updates are made. That is, where the DNS server is located:
whether they reside elsewhere, e.g., at the ISP. The reverse DNS
updates are typically easier to manage if they can be done within a 1. At the same organization as the prefix delegator.
single administrative entity -- and therefore, if a reverse DNS
delegation has been made, it may be easier to enable reverse DNS at 2. At the site where the prefixes are delegated to. In this case,
the site, e.g. by a wildcard record, or by some DNS update mechanism. the authority of the DNS reverse zone corresponding to the
delegated prefix is also delegated to the site.
3. Elsewhere; this implies a relationship between the site and where
DNS server is located, and such a relationship should be rather
straightforward to secure as well. Like in the previous case, the
authority of the DNS reverse zone is also delegated.
In the first case, managing the reverse DNS (delegation) is simpler
as the DNS server and the prefix delegator are in the same
administrative domain (as there is no need to delegate anything at
all); alternatively, the prefix delegator might forgo DDNS reverse
capability altogether, and use e.g., wildcard records (as described
in Section 7.2). In the other cases, it can be slighly more
difficult, particularly as the site will have to configure the DNS
server to be authoritative for the delegated reverse zone, implying
automatic configuration of the DNS server -- as the prefix may be
dynamic.
Managing the DDNS reverse updates is typically simple in the second
case, as the updated server is located at the local site, and
arguably IP address-based authentication could be sufficient (or if
not, setting up security relationships would be simpler). As there
is an explicit (security) relationship between the parties in the
third case, setting up the security relationships to allow reverse
DDNS updates should be rather straightforward as well. In the first
case, however, setting up and managing such relationships might be a
lot more difficult.
8. Miscellaneous DNS Considerations 8. Miscellaneous DNS Considerations
This section describes miscellaneous considerations about DNS which This section describes miscellaneous considerations about DNS which
seem related to IPv6, for which no better place has been found in seem related to IPv6, for which no better place has been found in
this document. this document.
8.1 NAT-PT with DNS-ALG 8.1 NAT-PT with DNS-ALG
NAT-PT [27] DNS-ALG is a critical component (unless something NAT-PT [36] DNS-ALG is a critical component (unless something
replacing that functionality is specified) which mangles A records to replacing that functionality is specified) which mangles A records to
look like AAAA records to the IPv6-only nodes. Numerous problems have look like AAAA records to the IPv6-only nodes. Numerous problems have
been identified with DNS-ALG [30]. been identified with DNS-ALG [39].
8.2 Renumbering Procedures and Applications' Use of DNS 8.2 Renumbering Procedures and Applications' Use of DNS
One of the most difficult problems of systematic IP address One of the most difficult problems of systematic IP address
renumbering procedures [28] is that an application which looks up a renumbering procedures [37] is that an application which looks up a
DNS name disregards information such as TTL, and uses the result 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 obtained from DNS as long as it happens to be stored in the memory of
the application. For applications which run for a long time, this the application. For applications which run for a long time, this
could be days, weeks or even months; some applications may be clever could be days, weeks or even months; some applications may be clever
enough to organize the data structures and functions in such a manner enough to organize the data structures and functions in such a manner
that look-ups get refreshed now and then. that look-ups get refreshed now and then.
While the issue appears to have a clear solution, "fix the While the issue appears to have a clear solution, "fix the
applications", practically this is not reasonable immediate advice; applications", practically this is not reasonable immediate advice;
the TTL information is not typically available in the APIs and the TTL information is not typically available in the APIs and
libraries (so, the advice becomes "fix the applications, APIs and libraries (so, the advice becomes "fix the applications, APIs and
libraries"), and a lot more analysis is needed on how to practically libraries"), and a lot more analysis is needed on how to practically
go about to achieve the ultimate goal of avoiding using the names go about to achieve the ultimate goal of avoiding using the names
longer than expected. longer than expected.
9. Acknowledgements 9. Acknowledgements
Some recommendations (Section 4.3, Section 5.1) about IPv6 service Some recommendations (Section 4.3, Section 5.1) about IPv6 service
provisioning were moved here from [33] by Erik Nordmark and Bob provisioning were moved here from [41] by Erik Nordmark and Bob
Gilligan. Havard Eidnes and Michael Patton provided useful feedback Gilligan. Havard Eidnes and Michael Patton provided useful feedback
and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark
Andrews helped in clarifying the issues regarding additional data and Andrews helped in clarifying the issues regarding additional data and
the use of TTL. the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei
Tatuya, and Iljitsch van Beijnum provided useful feedback during the
WG last call.
10. Security Considerations 10. Security Considerations
This document reviews the operational procedures for IPv6 DNS This document reviews the operational procedures for IPv6 DNS
operations and does not have security considerations in itself. operations and does not have security considerations in itself.
However, it is worth noting that in particular with Dynamic DNS However, it is worth noting that in particular with Dynamic DNS
Updates, security models based on the source address validation are Updates, security models based on the source address validation are
very weak and cannot be recommended. On the other hand, it should be very weak and cannot be recommended. On the other hand, it should be
noted that setting up an authorization mechanism (e.g., a shared noted that setting up an authorization mechanism (e.g., a shared
secret, or public-private keys) between a node and the DNS server has 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 to be done manually, and may require quite a bit of time and
expertise. expertise.
To re-emphasize which was already stated, reverse DNS checks provide To re-emphasize which was already stated, reverse DNS checks provide
very weak security at best, and the only (questionable) very weak security at best, and the only (questionable)
security-related use for them may be in conjunction with other security-related use for them may be in conjunction with other
mechanisms when authenticating a user. mechanisms when authenticating a user.
Normative References 11. References
11.1 Normative References
[1] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS [1] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
Extensions to Support IP Version 6", RFC 3596, October 2003. Extensions to Support IP Version 6", RFC 3596, October 2003.
[2] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain, [2] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain,
"Representing Internet Protocol version 6 (IPv6) Addresses in "Representing Internet Protocol version 6 (IPv6) Addresses in
the Domain Name System (DNS)", RFC 3363, August 2002. the Domain Name System (DNS)", RFC 3363, August 2002.
[3] Durand, A. and J. Ihren, "DNS IPv6 transport operational [3] Durand, A. and J. Ihren, "DNS IPv6 transport operational
guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-01 (work guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02 (work
in progress), October 2003. in progress), March 2004.
Informative References 11.2 Informative References
[4] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August [4] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August
2001. 2001.
[5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [5] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for
Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.
[6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[6] Internet Architecture Board, "IAB Technical Comment on the [7] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, May 2000. Unique DNS Root", RFC 2826, May 2000.
[7] Huitema, C. and B. Carpenter, "Deprecating Site Local [8] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", draft-ietf-ipv6-deprecate-site-local-02 (work in Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work in
progress), November 2003. progress), March 2004.
[8] Hazel, P., "IP Addresses that should never appear in the public [9] Hazel, P., "IP Addresses that should never appear in the public
DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in
progress), February 2002. progress), February 2002.
[9] Narten, T. and R. Draves, "Privacy Extensions for Stateless [10] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[10] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via [11] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[11] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", [12] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
draft-huitema-v6ops-teredo-00 (work in progress), June 2003. draft-huitema-v6ops-teredo-01 (work in progress), February
2004.
[12] Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work in [13] Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work in
progress), October 2002. progress), October 2002.
[13] Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa", [14] Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa",
draft-ymbk-6to4-arpa-delegation-00 (work in progress), February draft-ymbk-6to4-arpa-delegation-00 (work in progress), February
2003. 2003.
[14] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS [15] Huston, G., "6to4 Reverse DNS",
draft-huston-6to4-reverse-dns-02 (work in progress), April
2004.
[16] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS
Queries for IPv6 Addresses", Queries for IPv6 Addresses",
draft-morishita-dnsop-misbehavior-against-aaaa-00 (work in draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in
progress), June 2003. progress), April 2004.
[15] Larson, M. and P. Barber, "Observed DNS Resolution [17] Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in
progress), June 2003. progress), June 2003.
[16] Savola, P., "Moving from 6bone to IPv6 Internet", [18] Savola, P., "Moving from 6bone to IPv6 Internet",
draft-savola-v6ops-6bone-mess-01 (work in progress), November draft-savola-v6ops-6bone-mess-01 (work in progress), November
2002. 2002.
[17] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and [19] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.
[20] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks",
draft-ietf-v6ops-3gpp-analysis-09 (work in progress), March
2004.
[21] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and
Operation of Secondary DNS Servers", BCP 16, RFC 2182, July Operation of Secondary DNS Servers", BCP 16, RFC 2182, July
1997. 1997.
[18] Roy, S., "Dual Stack IPv6 on by Default", [22] Roy, S., "Dual Stack IPv6 on by Default",
draft-ietf-v6ops-v6onbydefault-00 (work in progress), October draft-ietf-v6ops-v6onbydefault-01 (work in progress), February
2003. 2004.
[19] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered
Harmful", draft-ietf-v6ops-onlinkassumption-00 (work in
progress), October 2003.
[20] Shin, M., "Application Aspects of IPv6 Transition", [23] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered
draft-ietf-v6ops-application-transition-00 (work in progress), Harmful", draft-ietf-v6ops-onlinkassumption-01 (work in
December 2003. progress), March 2004.
[21] Ohta, M., "Preconfigured DNS Server Addresses", [24] Shin, M., "Application Aspects of IPv6 Transition",
draft-ohta-preconfigured-dns-00 (work in progress), July 2003. draft-ietf-v6ops-application-transition-02 (work in progress),
March 2004.
[22] Jeong, J., "IPv6 DNS Discovery based on Router Advertisement", [25] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
draft-jeong-dnsop-ipv6-dns-discovery-00 (work in progress), Carney, "Dynamic Host Configuration Protocol for IPv6
July 2003. (DHCPv6)", RFC 3315, July 2003.
[23] Droms, R., "Stateless DHCP Service for IPv6", [26] Ohta, M., "Preconfigured DNS Server Addresses",
draft-ietf-dhc-dhcpv6-stateless-04 (work in progress), January draft-ohta-preconfigured-dns-01 (work in progress), February
2004. 2004.
[24] Thomson, S. and T. Narten, "IPv6 Stateless Address [27] Jeong, J., "IPv6 DNS Discovery based on Router Advertisement",
draft-jeong-dnsop-ipv6-dns-discovery-01 (work in progress),
February 2004.
[28] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[29] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
2003.
[30] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[25] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [31] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997. April 1997.
[26] Wellington, B., "Secure Domain Name System (DNS) Dynamic [32] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. Update", RFC 3007, November 2000.
[27] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - [33] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
Clients", draft-ietf-dhc-ddns-resolution-06 (work in progress),
October 2003.
[34] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
draft-ietf-dhc-fqdn-option-06 (work in progress), October 2003.
[35] Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for encoding
DHCP information (DHCID RR)", draft-ietf-dnsext-dhcid-rr-07
(work in progress), October 2003.
[36] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000. Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[28] Baker, F., "Procedures for Renumbering an IPv6 Network without [37] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering
a Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in an IPv6 Network without a Flag Day",
progress), October 2003. draft-baker-ipv6-renumber-procedure-01 (work in progress),
October 2003.
[29] Senie, D., "Requiring DNS IN-ADDR Mapping", [38] Senie, D., "Requiring DNS IN-ADDR Mapping",
draft-ietf-dnsop-inaddr-required-03 (work in progress), March draft-ietf-dnsop-inaddr-required-03 (work in progress), March
2002. 2002.
[30] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", [39] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress), draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress),
February 2003. February 2003.
[31] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", [40] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
draft-ietf-v6ops-3gpp-analysis-07 (work in progress), October
2003.
[32] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[33] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for [41] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-01 (work in IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in
progress), October 2003. progress), February 2004.
[42] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-03 (work in
progress), February 2004.
Authors' Addresses Authors' Addresses
Alain Durand Alain Durand
SUN Microsystems, Inc. SUN Microsystems, Inc.
17 Network circle UMPL17-202 17 Network circle UMPL17-202
Menlo Park, CA 94025 Menlo Park, CA 94025
USA USA
EMail: Alain.Durand@sun.com EMail: Alain.Durand@sun.com
skipping to change at page 19, line 40 skipping to change at page 23, line 22
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo Espoo
Finland Finland
EMail: psavola@funet.fi EMail: psavola@funet.fi
Appendix A. Site-local Addressing Considerations for DNS Appendix A. Site-local Addressing Considerations for DNS
As site-local addressing is being deprecated, and it is not yet clear As site-local addressing is being deprecated, the considerations for
whether an addressing-based replacement (and which kind) is devised, site-local addressing are discussed briefly here. Unique local
the considerations for site-local addressing are discussed briefly addressing format [42] has been proposed as a replacement, but being
here. work-in-progress, it is not considered further.
The interactions with DNS come in two flavors: forward and reverse The interactions with DNS come in two flavors: forward and reverse
DNS. DNS.
To actually use site-local addresses within a site, this implies the To actually use site-local addresses within a site, this implies the
deployment of a "split-faced" or a fragmented DNS name space, for the 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 zones internal to the site, and the outsiders' view to it. The
procedures to achieve this are not elaborated here. The implication procedures to achieve this are not elaborated here. The implication
is that site-local addresses must not be published in the public DNS. is that site-local addresses must not be published in the public DNS.
To faciliate reverse DNS (if desired) with site-local addresses, the To faciliate reverse DNS (if desired) with site-local addresses, the
stub resolvers must look for DNS information from the local DNS stub resolvers must look for DNS information from the local DNS
servers, not e.g. starting from the root servers, so that the servers, not e.g. starting from the root servers, so that the
site-local information may be provided locally. Note that the site-local information may be provided locally. Note that the
experience private addresses in IPv4 has shown that the root servers experience of private addresses in IPv4 has shown that the root
get loaded for requests for private address lookups in any. servers get loaded for requests for private address lookups in any
case.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the IETF's procedures with respect to rights in IETF Documents can
standards-related documentation can be found in BCP-11. Copies of be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/