draft-ietf-dnsop-ipv6-dns-issues-12.txt   rfc4472.txt 
DNS Operations WG A. Durand Network Working Group A. Durand
Internet-Draft Comcast Request for Comments: 4472 Comcast
Expires: April 22, 2006 J. Ihren Category: Informational J. Ihren
Autonomica Autonomica
P. Savola P. Savola
CSC/FUNET CSC/FUNET
October 19, 2005 April 2006
Operational Considerations and Issues with IPv6 DNS Operational Considerations and Issues with IPv6 DNS
draft-ietf-dnsop-ipv6-dns-issues-12.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2006. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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 misbehavior,
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Representing IPv6 Addresses in DNS Records . . . . . . . . 4 1.1. Representing IPv6 Addresses in DNS Records .................3
1.2. Independence of DNS Transport and DNS Records . . . . . . 4 1.2. Independence of DNS Transport and DNS Records ..............4
1.3. Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4
1.4. Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 1.4. Query Type '*' and A/AAAA Records ..........................4
2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 2. DNS Considerations about Special IPv6 Addresses .................5
2.1. Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 2.1. Limited-Scope Addresses ....................................5
2.2. Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 2.2. Temporary Addresses ........................................5
2.3. 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 2.3. 6to4 Addresses .............................................5
2.4. Other Transition Mechanisms . . . . . . . . . . . . . . . 6 2.4. Other Transition Mechanisms ................................5
3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 3. Observed DNS Implementation Misbehavior .........................6
3.1. Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 3.1. Misbehavior of DNS Servers and Load-balancers ..............6
3.2. Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 3.2. Misbehavior of DNS Resolvers ...............................6
4. Recommendations for Service Provisioning using DNS . . . . . . 8 4. Recommendations for Service Provisioning Using DNS ..............7
4.1. Use of Service Names instead of Node Names . . . . . . . . 8 4.1. Use of Service Names instead of Node Names .................7
4.2. Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8
4.3. Adding the Records Only when Fully IPv6-enabled . . . . . 9 4.3. Adding the Records Only When Fully IPv6-enabled ............8
4.4. The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10 4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9
4.4.1. TTL With Courtesy Additional Data . . . . . . . . . . 10 4.4.1. TTL with Courtesy Additional Data ...................9
4.4.2. TTL With Critical Additional Data . . . . . . . . . . 11 4.4.2. TTL with Critical Additional Data ..................10
4.5. IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11 4.5. IPv6 Transport Guidelines for DNS Servers .................10
5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11 5. Recommendations for DNS Resolver IPv6 Support ..................10
5.1. DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11 5.1. DNS Lookups May Query IPv6 Records Prematurely ............10
5.2. Obtaining a List of DNS Recursive Resolvers . . . . . . . 13 5.2. Obtaining a List of DNS Recursive Resolvers ...............12
5.3. IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13 5.3. IPv6 Transport Guidelines for Resolvers ...................12
6. Considerations about Forward DNS Updating . . . . . . . . . . 14 6. Considerations about Forward DNS Updating ......................13
6.1. Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14 6.1. Manual or Custom DNS Updates ..............................13
6.2. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Dynamic DNS ...............................................13
7. Considerations about Reverse DNS Updating . . . . . . . . . . 15 7. Considerations about Reverse DNS Updating ......................14
7.1. Applicability of Reverse DNS . . . . . . . . . . . . . . . 15 7.1. Applicability of Reverse DNS ..............................14
7.2. Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 7.2. Manual or Custom DNS Updates ..............................15
7.3. DDNS with Stateless Address Autoconfiguration . . . . . . 17 7.3. DDNS with Stateless Address Autoconfiguration .............16
7.4. DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18 7.4. DDNS with DHCP ............................................17
7.5. DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18 7.5. DDNS with Dynamic Prefix Delegation .......................17
8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19 8. Miscellaneous DNS Considerations ...............................18
8.1. NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19 8.1. NAT-PT with DNS-ALG .......................................18
8.2. Renumbering Procedures and Applications' Use of DNS . . . 19 8.2. Renumbering Procedures and Applications' Use of DNS .......18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements ...............................................19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations .......................................19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. References ....................................................20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References .....................................20
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References ...................................22
12.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Unique Local Addressing Considerations for DNS ........24
Appendix A. Unique Local Addressing Considerations for DNS . . . 25 Appendix B. Behavior of Additional Data in IPv4/IPv6
Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments ..........................................24
Environments . . . . . . . . . . . . . . . . . . . . 25 B.1. Description of Additional Data Scenarios ..................24
B.1. Description of Additional Data Scenarios . . . . . . . . . 25 B.2. Which Additional Data to Keep, If Any? ....................26
B.2. Which Additional Data to Keep, If Any? . . . . . . . . . . 27 B.3. Discussion of the Potential Problems ......................27
B.3. Discussion of the Potential Problems . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 29
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 The purpose of this document is to give information about various
issues and considerations related to DNS operations with IPv6; it is issues and considerations related to DNS operations with IPv6; it is
not meant to be a normative specification or standard for IPv6 DNS. 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 misbehaviors that have a varying effect on the use of
of IPv6 records with DNS. The fourth section lists recommendations IPv6 records with DNS. The fourth section lists recommendations and
and considerations for provisioning services with DNS. The fifth considerations for provisioning services with DNS. The fifth section
section in turn looks at recommendations and considerations about in turn looks at recommendations and considerations about providing
providing IPv6 support in the resolvers. The sixth and seventh IPv6 support in the resolvers. The sixth and seventh sections
sections describe considerations with forward and reverse DNS describe considerations with forward and reverse DNS updates,
updates, respectively. The eighth section introduces several respectively. The eighth section introduces several miscellaneous
miscellaneous IPv6 issues relating to DNS for which no better place IPv6 issues relating to DNS for which no better place has been found
has been found in this memo. Appendix A looks briefly at the in this memo. Appendix A looks briefly at the requirements for
requirements for unique local addressing. unique local addressing. Appendix B discusses additional data.
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 PTR records in the nibble format under the ip6.arpa. tree. See
[RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
for background information. for background information.
In particular one should note that the use of A6 records in the In particular, one should note that the use of A6 records in the
forward tree or Bitlabels in the reverse tree is not recommended forward tree or Bitlabels in the reverse tree is not recommended
[RFC3363]. Using DNAME records is not recommended in the reverse [RFC3363]. Using DNAME records is not recommended in the reverse
tree in conjunction with A6 records; the document did not mean to tree in conjunction with A6 records; the document did not mean to
take a stance on any other use of DNAME records [RFC3364]. take a stance on any other use of DNAME records [RFC3364].
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
[RFC2826]. This property should be maintained, as described here and [RFC2826]. This property should be maintained, as described here and
in Section 1.3. in Section 1.3.
skipping to change at page 5, line 46 skipping to change at page 5, line 7
QTYPE=* is typically only used for debugging or management purposes; QTYPE=* is typically only used for debugging or management purposes;
it is worth keeping in mind that QTYPE=* ("ANY" queries) only return it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
any available RRsets, not *all* the RRsets, because the caches do not any available RRsets, not *all* the RRsets, because the caches do not
necessarily have all the RRsets and have no way of guaranteeing that necessarily have all the RRsets and have no way of guaranteeing that
they have all the RRsets. Therefore, to get both A and AAAA records they have all the RRsets. Therefore, to get both A and AAAA records
reliably, two separate queries must be made. reliably, two separate queries must be made.
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 that 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 [RFC3513] includes two kinds of The IPv6 addressing architecture [RFC4291] includes two kinds of
local-use addresses: link-local (fe80::/10) and site-local local-use addresses: link-local (fe80::/10) and site-local
(fec0::/10). The site-local addresses have been deprecated [RFC3879] (fec0::/10). The site-local addresses have been deprecated [RFC3879]
but are discussed with unique local addresses in Appendix A. but are discussed with unique local addresses in Appendix A.
Link-local addresses should never be published in DNS (whether in Link-local addresses should never be published in DNS (whether in
forward or reverse tree), because they have only local (to the forward or reverse tree), because they have only local (to the
connected link) significance [I-D.durand-dnsop-dont-publish]. connected link) significance [WIP-DC2005].
2.2. Temporary Addresses 2.2. Temporary Addresses
Temporary addresses defined in RFC3041 [RFC3041] (sometimes called Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
"privacy addresses") use a random number as the interface identifier. "privacy addresses") use a random number as the interface identifier.
Having DNS AAAA records that are updated to always contain the Having DNS AAAA records that are updated to always contain the
current value of a node's temporary address would defeat the purpose current value of a node's temporary address would defeat the purpose
of the mechanism and is not recommended. However, it would still be of the mechanism and is not recommended. However, it would still be
possible to return a non-identifiable name (e.g., the IPv6 address in possible to return a non-identifiable name (e.g., the IPv6 address in
hexadecimal format), as described in [RFC3041]. hexadecimal format), as described in [RFC3041].
2.3. 6to4 Addresses 2.3. 6to4 Addresses
6to4 [RFC3056] specifies an automatic tunneling mechanism which maps 6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a
a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
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 possible ways to do so. applicability), there are a number of possible ways to do so.
The main proposal [I-D.huston-6to4-reverse-dns] aims to design an [WIP-H2005] aims to design an autonomous reverse-delegation system
autonomous reverse-delegation system that anyone being capable of that anyone being capable of communicating using a specific 6to4
communicating using a specific 6to4 address would be able to set up a address would be able to set up a reverse delegation to the
reverse delegation to the corresponding 6to4 prefix. This could be corresponding 6to4 prefix. This could be deployed by, e.g., Regional
deployed by e.g., Regional Internet Registries (RIRs). This is a Internet Registries (RIRs). This is a practical solution, but may
practical solution, but may have some scalability concerns. have some scalability concerns.
2.4. Other Transition Mechanisms 2.4. Other Transition Mechanisms
6to4 is mentioned as a case of an IPv6 transition mechanism requiring 6to4 is mentioned as a case of an IPv6 transition mechanism requiring
special considerations. In general, mechanisms which include a special considerations. In general, mechanisms that include a
special prefix may need a custom solution; otherwise, for example special prefix may need a custom solution; otherwise, for example,
when IPv4 address is embedded as the suffix or not embedded at all, when IPv4 address is embedded as the suffix or not embedded at all,
special solutions are likely not needed. special solutions are likely not needed.
Note that it does not seem feasible to provide reverse DNS with Note that it does not seem feasible to provide reverse DNS with
another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops- another automatic tunneling mechanism, Teredo [RFC4380]; this is
teredo]; this is because the IPv6 address is based on the IPv4 because the IPv6 address is based on the IPv4 address and UDP port of
address and UDP port of the current NAT mapping which is likely to be the current Network Address Translation (NAT) mapping, which is
relatively short-lived. likely to be relatively short-lived.
3. Observed DNS Implementation Misbehaviour 3. Observed DNS Implementation Misbehavior
Several classes of misbehaviour in DNS servers, load-balancers and Several classes of misbehavior 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 misbehavior 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. Misbehavior of DNS Servers and Load-balancers
There are several classes of misbehaviour in certain DNS servers and There are several classes of misbehavior in certain DNS servers and
load-balancers which have been noticed and documented [RFC4074]: some load-balancers that have been noticed and documented [RFC4074]: 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 -- response, query the A records. This is done in a serial fashion --
if the first query is never responded to (instead of properly if the first query is never responded to (instead of properly
returning a negative answer), significant timeouts will occur. returning a negative answer), significant time-outs will occur.
In consequence, this is an enormous problem for IPv6 deployments, and In consequence, this is an enormous problem for IPv6 deployments, and
in some cases, IPv6 support in the software has even been disabled in some cases, IPv6 support in the software has even been disabled
due to these problems. due to these problems.
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 possible ways to mitigate the problem, e.g., by performing the
lookups somewhat in parallel and reducing the timeout as long as at lookups somewhat in parallel and reducing the time-out as long as at
least one answer has been received; but such methods remain to be least one answer has been received, but such methods remain to be
investigated; slightly more on this is included in Section 5. investigated; slightly more on this is included in Section 5.
3.2. Misbehaviour of DNS Resolvers 3.2. Misbehavior of DNS Resolvers
Several classes of misbehaviour have also been noticed in DNS Several classes of misbehavior have also been noticed in DNS
resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem resolvers [WIP-LB2005]. However, these do not seem to directly
to directly impair IPv6 use, and are only referred to for impair IPv6 use, and are only referred to for completeness.
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
It makes sense to keep information about separate services logically It makes sense to keep information about separate services logically
separate in the DNS by using a different DNS hostname for each separate in the DNS by using a different DNS hostname for each
service. There are several reasons for doing this, for example: service. There are several reasons for doing this, for example:
o It allows more flexibility and ease for migration of (only a part o It allows more flexibility and ease for migration of (only a part
of) services from one node to another, of) services from one node to another,
o It allows configuring different properties (e.g., TTL) for each o It allows configuring different properties (e.g., Time to Live
service, and (TTL)) for each service, and
o It allows deciding separately for each service whether to publish o It allows deciding separately for each service whether or not to
the IPv6 addresses or not (in cases where some services are more publish the IPv6 addresses (in cases where some services are more
IPv6-ready than others). IPv6-ready than others).
Using SRV records [RFC2782] would avoid these problems. Using SRV records [RFC2782] would avoid these problems.
Unfortunately, those are not sufficiently widely used to be Unfortunately, those are not sufficiently widely used to be
applicable in most cases. Hence an operation technique is to use applicable in most cases. Hence an operation technique is to use
service names instead of node names (or, "hostnames"). This service names instead of node names (or "hostnames"). This
operational technique is not specific to IPv6, but required to operational technique is not specific to IPv6, but required to
understand the considerations described in Section 4.2 and understand the considerations described in Section 4.2 and
Section 4.3. 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 could use look up the mail via IMAP from "pobox.example.com", one could use,
e.g., "smtp.example.com" for SMTP (for both message submission and 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 that loops do not occur. DNS can provide a layer of indirection
service names and where the service actually is, and using which between service names and where the service actually is, and using
addresses. (Obviously, when wanting to reach a specific node, one which addresses. (Obviously, when wanting to reach a specific node,
should use the hostname rather than a service name.) one should use the hostname rather than a service name.)
4.2. Separate vs the Same Service Names for IPv4 and IPv6 4.2. Separate vs. the Same Service Names for IPv4 and IPv6
The service naming can be achieved in basically two ways: when a The service naming can be achieved in basically two ways: when a
service is named "service.example.com" for IPv4, the IPv6-enabled service is named "service.example.com" for IPv4, the IPv6-enabled
service could either be added to "service.example.com", or added service could either be added to "service.example.com" or added
separately under a different name, e.g., in a sub-domain, like, separately under a different name, e.g., in a sub-domain like
"service.ipv6.example.com". "service.ipv6.example.com".
These two methods have different characteristics. Using a different These two methods have different characteristics. Using a different
name allows for easier service piloting, minimizing the disturbance name allows for easier service piloting, minimizing the disturbance
to the "regular" users of IPv4 service; however, the service would to the "regular" users of IPv4 service; however, the service would
not be used transparently, without the user/application explicitly not be used transparently, without the user/application explicitly
finding it and asking for it -- which would be a disadvantage in most finding it and asking for it -- which would be a disadvantage in most
cases. When the different name is under a sub-domain, if the cases. When the different name is under a sub-domain, if the
services are deployed within a restricted network (e.g., inside an services are deployed within a restricted network (e.g., inside an
enterprise), it's possible to prefer them transparently, at least to enterprise), it's possible to prefer them transparently, at least to
skipping to change at page 9, line 26 skipping to change at page 8, line 32
suboptimal solution. Using the same service name is the "long-term" suboptimal solution. Using the same service name is the "long-term"
solution, but may degrade performance for those clients whose IPv6 solution, but may degrade performance for those clients whose IPv6
performance is lower than IPv4, or does not work as well (see performance is lower than IPv4, or does not work as well (see
Section 4.3 for more). Section 4.3 for more).
In most cases, it makes sense to pilot or test a service using In most cases, it makes sense to pilot or test a service using
separate service names, and move to the use of the same name when separate service names, and move to the use of the same name when
confident enough that the service level will not degrade for the confident enough that the service level will not degrade for the
users unaware of IPv6. users unaware of IPv6.
4.3. Adding the Records Only when Fully IPv6-enabled 4.3. Adding the Records Only When Fully IPv6-enabled
The recommendation is that AAAA records for a service should not be The recommendation is that AAAA records for a service should not be
added to the DNS until all of following are true: added to the DNS until all of following are true:
1. The address is assigned to the interface on the node. 1. The address is assigned to the interface on the node.
2. The address is configured on the interface. 2. The address is configured on the interface.
3. The interface is on a link which is connected to the IPv6 3. The interface is on a link that is connected to the IPv6
infrastructure. infrastructure.
In addition, if the AAAA record is added for the node, instead of In addition, if the AAAA record is added for the node, instead of
service as recommended, all the services of the node should be IPv6- service as recommended, all the services of the node should be IPv6-
enabled prior to adding the resource record. enabled prior to adding the resource record.
For example, if an IPv6 node is isolated from an IPv6 perspective For example, if an IPv6 node is isolated from an IPv6 perspective
(e.g., it is not connected to IPv6 Internet) constraint #3 would mean (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
that it should not have an address in the DNS. that it should not have an address in the DNS.
Consider the case of two dual-stack nodes, which both have IPv6 Consider the case of two dual-stack nodes, which both are IPv6-
enabled, but the server does not have (global) IPv6 connectivity. As enabled, but the server does not have (global) IPv6 connectivity. As
the client looks up the server's name, only A records are returned the client looks up the server's name, only A records are returned
(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
that the service offered using both protocols is of roughly equal important that the service offered using both protocols is of roughly
quality, using the appropriate metrics for the service (e.g., equal 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 real- This is typically very important especially for interactive or real-
time services. In many cases, the quality of IPv6 connectivity may time services. In many cases, the quality of IPv6 connectivity may
not yet be equal to that of IPv4, at least globally -- this has to be not yet be equal to that of IPv4, at least globally; this has to be
taken into consideration when enabling services. taken into consideration when enabling services.
4.4. The Use of TTL for IPv4 and IPv6 RRs 4.4. The Use of TTL for IPv4 and IPv6 RRs
The behaviour of DNS caching when different TTL values are used for The behavior of DNS caching when different TTL values are used for
different RRsets of the same name calls for explicit discussion. For different RRsets of the same name calls for explicit discussion. For
example, let's consider two unrelated zone fragments: example, let's consider two unrelated zone fragments:
example.com. 300 IN MX foo.example.com. example.com. 300 IN MX foo.example.com.
foo.example.com. 300 IN A 192.0.2.1 foo.example.com. 300 IN A 192.0.2.1
foo.example.com. 100 IN AAAA 2001:db8::1 foo.example.com. 100 IN AAAA 2001:db8::1
... ...
child.example.com. 300 IN NS ns.child.example.com. child.example.com. 300 IN NS ns.child.example.com.
ns.child.example.com. 300 IN A 192.0.2.1 ns.child.example.com. 300 IN A 192.0.2.1
ns.child.example.com. 100 IN AAAA 2001:db8::1 ns.child.example.com. 100 IN AAAA 2001:db8::1
In the former case, we have "courtesy" additional data; in the In the former case, we have "courtesy" additional data; in the
latter, we have "critical" additional data. See more extensive latter, we have "critical" additional data. See more extensive
background discussion of additional data handling in Appendix B. background discussion of additional data handling in Appendix B.
4.4.1. TTL With Courtesy Additional Data 4.4.1. TTL with Courtesy Additional Data
When a caching resolver asks for the MX record of example.com, it 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 gets back "foo.example.com". It may also get back either one or both
of the A and AAAA records in the additional section. The resolver of the A and AAAA records in the additional section. The resolver
must explicitly query for both A and AAAA records [RFC2821]. must explicitly query for both A and AAAA records [RFC2821].
After 100 seconds, the AAAA record is removed from the cache(s) After 100 seconds, the AAAA record is removed from the cache(s)
because its TTL expired. It could be argued to be useful for the because its TTL expired. It could be argued to be useful for the
caching resolvers to discard the A record when the shorter TTL (in caching resolvers to discard the A record when the shorter TTL (in
this case, for the AAAA record) expires; this would avoid the this case, for the AAAA record) expires; this would avoid the
situation where there would be a window of 200 seconds when situation where there would be a window of 200 seconds when
incomplete information is returned from the cache. Further argument incomplete information is returned from the cache. Further argument
for discarding is that in the normal operation, the TTL values are so for discarding is that in the normal operation, the TTL values are so
high that very likely the incurred additional queries would not be high that very likely the incurred additional queries would not be
noticeable, compared to the obtained performance optimization. The noticeable, compared to the obtained performance optimization. The
behaviour in this scenario is unspecified. behavior in this scenario is unspecified.
4.4.2. TTL With Critical Additional Data 4.4.2. TTL with Critical Additional Data
The difference to courtesy additional data is that the A/AAAA records The difference to courtesy additional data is that the A/AAAA records
served by the parent zone cannot be queried explicitly. Therefore served by the parent zone cannot be queried explicitly. Therefore,
after 100 seconds the AAAA record is removed from the cache(s), but after 100 seconds the AAAA record is removed from the cache(s), but
the A record remains. Queries for the remaining 200 seconds the A record remains. Queries for the remaining 200 seconds
(provided that there are no further queries from the parent which (provided that there are no further queries from the parent that
could refresh the caches) only return the A record, leading to a could refresh the caches) only return the A record, leading to a
potential opererational situation with unreachable servers. potential operational situation with unreachable servers.
Similar cache flushing strategies apply in this scenario; the Similar cache flushing strategies apply in this scenario; the
behaviour is likewise unspecified. behavior is likewise unspecified.
4.5. IPv6 Transport Guidelines for DNS Servers 4.5. IPv6 Transport Guidelines for DNS Servers
As described in Section 1.3 and [RFC3901], there should continue to As described in Section 1.3 and [RFC3901], there should continue to
be at least one authoritative IPv4 DNS server for every zone, even if be at least one authoritative IPv4 DNS server for every zone, even if
the zone has only IPv6 records. (Note that obviously, having more the zone has only IPv6 records. (Note that obviously, having more
servers with robust connectivity would be preferable, but this is the servers with robust connectivity would be preferable, but this is the
minimum recommendation; also see [RFC2182].) minimum recommendation; also see [RFC2182].)
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
of enabling IPv6; it may come in basically three flavours: of enabling IPv6; it may come in basically three flavors:
1. The system library does not know whether IPv6 has been enabled in 1. The system library does not know whether IPv6 has been enabled in
the kernel of the operating system: it may start looking up AAAA the kernel of the operating system: it may start looking up AAAA
records with getaddrinfo() and AF_UNSPEC hint when the system is records with getaddrinfo() and AF_UNSPEC hint when the system is
upgraded to a system library version which supports IPv6. upgraded to a system library version that supports IPv6.
2. The system library might start to perform IPv6 queries with 2. The system library might start to perform IPv6 queries with
getaddrinfo() only when IPv6 has been enabled in the kernel. getaddrinfo() only when IPv6 has been enabled in the kernel.
However, this does not guarantee that there exists any useful However, this does not guarantee that there exists any useful
IPv6 connectivity (e.g., the node could be isolated from the IPv6 connectivity (e.g., the node could be isolated from the
other IPv6 networks, only having link-local addresses). other IPv6 networks, only having link-local addresses).
3. The system library might implement a toggle which would apply 3. The system library might implement a toggle that would apply some
some heuristics to the "IPv6-readiness" of the node before heuristics to the "IPv6-readiness" of the node before starting to
starting to perform queries; for example, it could check whether perform queries; for example, it could check whether only link-
only link-local IPv6 address(es) exists, or if at least one local IPv6 address(es) exists, or if at least one global IPv6
global IPv6 address exists. address exists.
First, let us consider generic implications of unnecessary queries First, let us consider generic implications of unnecessary queries
for AAAA records: when looking up all the records in the DNS, AAAA for AAAA records: when looking up all the records in the DNS, AAAA
records are typically tried first, and then A records. These are records are typically tried first, and then A records. These are
done in serial, and the A query is not performed until a response is done in serial, and the A query is not performed until a response is
received to the AAAA query. Considering the misbehaviour of DNS received to the AAAA query. Considering the misbehavior of DNS
servers and load-balancers, as described in Section 3.1, the look-up servers and load-balancers, as described in Section 3.1, the lookup
delay for AAAA may incur additional unnecessary latency, and delay for AAAA may incur additional unnecessary latency, and
introduce a component of unreliability. introduce a component of unreliability.
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, at least without result. (Immediate parallelism might not be optimal, at least
information sharing between the look-up threads, as that would without information-sharing between the lookup threads, as that would
probably lead to duplicate non-cached delegation chain lookups). probably lead to 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 [I-D.ietf-v6ops-v6onbydefault]. does not have any IPv6 connectivity [WIP-RDP2004]. In some cases,
In some cases, the implementation may attempt to connect or send a the implementation may attempt to connect or send a datagram on a
datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], physical link [WIP-R2006], incurring very long protocol time-outs,
incurring very long protocol timeouts, instead of quickly failing instead of quickly falling back to IPv4.
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 [RFC4038]. gracefully back to IPv4 [RFC4038].
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 time-outs.
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 that 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 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 performing DNS lookups only when a non-link-local address has been
configured on any interface could be beneficial -- this would be an configured on any interface could be beneficial -- this would be an
indication that either the address has been configured either from a indication that the address has been configured either from a router
router advertisement, DHCPv6 [RFC3315], or manually. Each would advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
indicate at least some form of IPv6 connectivity, even though there [RFC3315], or manually. Each would indicate at least some form of
would not be guarantees of it. IPv6 connectivity, even though there 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. Obtaining a List of DNS Recursive Resolvers 5.2. Obtaining a List of DNS Recursive Resolvers
In scenarios where DHCPv6 is available, a host can discover a list of In scenarios where DHCPv6 is available, a host can discover a list of
DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" DNS recursive resolvers through the DHCPv6 "DNS Recursive Name
option [RFC3646]. This option can be passed to a host through a Server" option [RFC3646]. This option can be passed to a host
subset of DHCPv6 [RFC3736]. through a subset of DHCPv6 [RFC3736].
The IETF is considering the development of alternative mechanisms for The IETF is considering the development of alternative mechanisms for
obtaining the list of DNS recursive name servers when DHCPv6 is obtaining the list of DNS recursive name servers when DHCPv6 is
unavailable or inappropriate. No decision about taking on this unavailable or inappropriate. No decision about taking on this
development work has been reached as of this writing (Aug 2004) development work has been reached as of this writing [RFC4339].
[I-D.ietf-dnsop-ipv6-dns-configuration].
In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
under consideration for development include the use of well-known under consideration for development include the use of [WIP-O2004]
addresses [I-D.ohta-preconfigured-dns] and the use of Router and the use of Router Advertisements to convey the information
Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns- [WIP-J2006].
discovery].
Note that even though IPv6 DNS resolver discovery is a recommended Note that even though IPv6 DNS resolver discovery is a recommended
procedure, it is not required for dual-stack nodes in dual-stack 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 networks as IPv6 DNS records can be queried over IPv4 as well as
IPv6. Obviously, nodes which are meant to function without manual IPv6. Obviously, nodes that are meant to function without manual
configuration in IPv6-only networks must implement the DNS resolver configuration in IPv6-only networks must implement the DNS resolver
discovery function. discovery function.
5.3. IPv6 Transport Guidelines for Resolvers 5.3. IPv6 Transport Guidelines for Resolvers
As described in Section 1.3 and [RFC3901], the recursive 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 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- DNS server. Note that this requirement is also fulfilled by an IPv6-
only stub resolver pointing to a dual-stack recursive DNS resolver. only 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 of how to enable updating the forward DNS, i.e., the 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 mapping from names to the correct new addresses, is not specific to
IPv6, it should be considered especially due to the advent of IPv6, it should be considered especially due to the advent of
Stateless Address Autoconfiguration [RFC2462]. Stateless Address Autoconfiguration [RFC2462].
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 often be assumed to "own" a 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 certain DNS name -- and we can create a form of security relationship
with the DNS name and the node which is allowed to update it to point with the DNS name and the node that is allowed to update it to point
to a new address. to a new address.
A more complex form of DNS updates -- adding a whole new name into 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 out DNS zone, instead of updating an existing name -- is considered out
of scope for this memo as it could require zone-wide authentication. of scope for this memo as it could require zone-wide authentication.
Adding a new name in the forward zone is a problem which is still 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 being explored with IPv4, and IPv6 does not seem to add much new in
that area. that area.
6.1. Manual or Custom DNS Updates 6.1. Manual or Custom DNS Updates
The DNS mappings can also be maintained by hand, in a semi-automatic The DNS mappings can also 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) [RFC2136] [RFC3007] is a standardized Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
mechanism for dynamically updating the DNS. It works equally well mechanism for dynamically updating the DNS. It works equally well
with stateless address autoconfiguration (SLAAC), DHCPv6 or manual with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual
address configuration. It is important to consider how each of these address configuration. It is important to consider how each of these
behave if IP address-based authentication, instead of stronger behave if IP address-based authentication, instead of stronger
mechanisms [RFC3007], was used in the updates. mechanisms [RFC3007], was used in the updates.
1. manual addresses are static and can be configured 1. Manual addresses are static and can be configured.
2. DHCPv6 addresses could be reasonably static or dynamic, depending 2. DHCPv6 addresses could be reasonably static or dynamic, depending
on the deployment, and could or could not be configured on the on the deployment, and could or could not be configured on the
DNS server for the long term DNS server for the long term.
3. SLAAC addresses are typically stable for a long time, but could 3. SLAAC addresses are typically stable for a long time, but could
require work to be configured and maintained. require work to be configured and maintained.
As relying on IP addresses for Dynamic DNS is rather insecure at As relying on IP addresses for Dynamic DNS is rather insecure at
best, stronger authentication should always be used; however, this best, stronger authentication should always be used; however, this
requires that the authorization keying will be explicitly configured requires that the authorization keying will be explicitly configured
using unspecified operational methods. 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 DHCP-initiated DDNS updates have been extensively described in
[I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b].
[I-D.ietf-dnsext-dhcid-rr].
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 authoritative 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 addresses, so TTLs for addresses than are preferred lifetimes for the addresses, so
that if the node is renumbered in a managed fashion, the amount of 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 stale DNS information is kept to the minimum. That is, if the
preferred lifetime of an address expires, the TTL of the record needs preferred lifetime of an address expires, the TTL of the record needs
be modified unless it was already done before the expiration. For 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 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 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 start lowering the DNS TTL if it seems like the address has not been
renewed/refreshed in a while. Some discussion on how an renewed/refreshed in a while. Some discussion on how an
administrator could manage the DNS TTL is included in [RFC4192]; this administrator could manage the DNS TTL is included in [RFC4192]; this
could be applied to (smart) hosts as well. could be applied to (smart) hosts as well.
7. Considerations about Reverse DNS Updating 7. Considerations about Reverse DNS Updating
Updating the reverse DNS zone may be difficult because of the split Updating the reverse DNS zone may be difficult because of the split
authority over an address. However, first we have to consider the authority over an address. However, first we have to consider the
applicability of reverse DNS in the first place. applicability of reverse DNS in 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 either to 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 premise 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).
One additional, maybe slightly more useful usage is ensuring that the One additional, maybe slightly more useful usage is ensuring that the
reverse and forward DNS contents match (by looking up the pointer to 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 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) 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, and correspond to a configured name or domain. As a security check,
it is typically accompanied by other mechanisms, such as a user/ it is typically accompanied by other mechanisms, such as a user/
password login; the main purpose of the reverse+forward DNS check is password login; the main purpose of the reverse+forward DNS check is
skipping to change at page 16, line 28 skipping to change at page 15, line 27
"properly". "properly".
It may also be desirable to store IPsec keying material corresponding It may also be desirable to store IPsec keying material corresponding
to an IP address in the reverse DNS, as justified and described in to an IP address in the reverse DNS, as justified and described in
[RFC4025]. [RFC4025].
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 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 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 [I-D.ietf-dnsop- The applicability is discussed at more length in [WIP-S2005c].
inaddr-required].
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).
As a concrete example, a site (or the site's ISP) could configure the 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 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 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 site.example.com.". Naturally, such a name could not be verified
the forward DNS, but would at least provide some form of "topological from the forward DNS, but would at least provide some form of
information" or "weak authorization" if that is really considered to "topological information" or "weak authorization" if that is really
be useful. Note that this is not actually updating the DNS as such, considered to be useful. Note that this is not actually updating the
as the whole point is to avoid DNS updates completely by manually DNS as such, as the whole point is to avoid DNS updates completely by
configuring a generic name. manually configuring a generic name.
7.3. DDNS with Stateless Address Autoconfiguration 7.3. DDNS with Stateless Address Autoconfiguration
Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
some regard, while being more difficult in another, as described some regard, while being more difficult in another, as described
below. below.
The address space administrator decides whether the hosts are trusted The address space administrator decides whether or not the hosts are
to update their reverse DNS records or not. If they are trusted and 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 deployed at the same site (e.g., not across the Internet), a simple
address-based authorization is typically sufficient (i.e., check that address-based authorization is typically sufficient (i.e., check that
the DNS update is done from the same IP address as the record being the DNS update is done from the same IP address as the record being
updated); stronger security can also be used [RFC3007]. If they updated); stronger security can also be used [RFC3007]. If they
aren't allowed to update the reverses, no update can occur. However, aren't allowed to update the reverses, no update can occur. However,
such address-based update authorization operationally requires that such address-based update authorization operationally requires that
ingress filtering [RFC3704] has been set up at the border of the site 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. where the updates occur, and as close to the updater as possible.
Address-based authorization is simpler with reverse DNS (as there is Address-based authorization is simpler with reverse DNS (as there is
a connection between the record and the address) than with forward a connection between the record and the address) than with forward
DNS. However, when a stronger form of security is used, forward DNS 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 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 an association with the domain. Note that the user may roam to
different networks, and does not necessarily have any association different networks and does not necessarily have any association with
with the owner of that address space -- so, assuming stronger form of the owner of that address space. So, assuming a stronger form of
authorization for reverse DNS updates than an address association is authorization for reverse DNS updates than an address association is
generally infeasible. generally infeasible.
Moreover, the reverse zones must be cleaned up by an unspecified Moreover, the reverse zones must be cleaned up by an unspecified
janitorial process: the node does not typically know a priori that it janitorial process: the node does not typically know a priori that it
will be disconnected, and cannot send a DNS update using the correct will be disconnected, and it cannot send a DNS update using the
source address to remove a record. correct source address to remove a record.
A problem with defining the clean-up process is that it is difficult 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 to ensure that a specific IP address and the corresponding record are
no longer being used. Considering the huge address space, and the no longer being used. Considering the huge address space, and the
unlikelihood of collision within 64 bits of the interface unlikelihood of collision within 64 bits of the interface
identifiers, a process which would remove the record after no traffic 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 has been seen from a node in a long period of time (e.g., a month or
year) might be one possible approach. 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 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 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 authoritative (e.g., through SOA record) for the IP address being
updated, but the security material (unless the IP address-based updated, but the security material (unless the IP address-based
authorization is trusted) must also be established by some other authorization is trusted) must also be established by some other
means. means.
One should note that Cryptographically Generated Addresses [RFC3972] One should note that Cryptographically Generated Addresses (CGAs)
(CGAs) may require a slightly different kind of treatment. CGAs are [RFC3972] may require a slightly different kind of treatment. CGAs
addresses where the interface identifier is calculated from a public are addresses where the interface identifier is calculated from a
key, a modifier (used as a nonce), the subnet prefix, and other data. public key, a modifier (used as a nonce), the subnet prefix, and
Depending on the usage profile, CGAs might or might not be changed other data. Depending on the usage profile, CGAs might or might not
periodically due to e.g., privacy reasons. As the CGA address is not be changed periodically due to, e.g., privacy reasons. As the CGA
predicatable, a reverse record can only reasonably be inserted in the address is not predictable, a reverse record can only reasonably be
DNS by the node which generates the address. inserted in the DNS by the node that generates the address.
7.4. DDNS with DHCP 7.4. DDNS with DHCP
With DHCPv4, the reverse DNS name is typically already inserted to With DHCPv4, the reverse DNS name is typically already inserted to
the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One the DNS that reflects the name (e.g., "dhcp-67.example.com"). One
can assume similar practice may become commonplace with DHCPv6 as can assume similar practice may become commonplace with DHCPv6 as
well; all such mappings would be pre-configured, and would require no well; all such mappings would be pre-configured and would require no
updating. 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 (if an address a reverse DNS record instead of inserting one (if an address
assignment policy that reassigns disused addresses is adopted) and assignment policy that reassigns disused addresses is adopted) and
updating a record seems like a slightly more difficult thing to updating a record seems like a slightly more difficult thing to
secure. However, it is yet uncertain how DHCPv6 is going to be used secure. However, it is yet uncertain how DHCPv6 is going to be used
for address assignment. for address assignment.
skipping to change at page 19, line 6 skipping to change at page 18, line 6
updated, one should consider what is the location of the server where updated, one should consider what is the location of the server where
DDNS updates are made. That is, where the DNS server is located: DDNS updates are made. That is, where the DNS server is located:
1. At the same organization as the prefix delegator. 1. At the same organization as the prefix delegator.
2. At the site where the prefixes are delegated to. In this case, 2. At the site where the prefixes are delegated to. In this case,
the authority of the DNS reverse zone corresponding to the the authority of the DNS reverse zone corresponding to the
delegated prefix is also delegated to the site. delegated prefix is also delegated to the site.
3. Elsewhere; this implies a relationship between the site and where 3. Elsewhere; this implies a relationship between the site and where
DNS server is located, and such a relationship should be rather the DNS server is located, and such a relationship should be
straightforward to secure as well. Like in the previous case, rather straightforward to secure as well. Like in the previous
the authority of the DNS reverse zone is also delegated. case, the authority of the DNS reverse zone is also delegated.
In the first case, managing the reverse DNS (delegation) is simpler In the first case, managing the reverse DNS (delegation) is simpler
as the DNS server and the prefix delegator are in the same as the DNS server and the prefix delegator are in the same
administrative domain (as there is no need to delegate anything at administrative domain (as there is no need to delegate anything at
all); alternatively, the prefix delegator might forgo DDNS reverse all); alternatively, the prefix delegator might forgo DDNS reverse
capability altogether, and use e.g., wildcard records (as described capability altogether, and use, e.g., wildcard records (as described
in Section 7.2). In the other cases, it can be slighly more in Section 7.2). In the other cases, it can be slightly more
difficult, particularly as the site will have to configure the DNS difficult, particularly as the site will have to configure the DNS
server to be authoritative for the delegated reverse zone, implying server to be authoritative for the delegated reverse zone, implying
automatic configuration of the DNS server -- as the prefix may be automatic configuration of the DNS server -- as the prefix may be
dynamic. dynamic.
Managing the DDNS reverse updates is typically simple in the second Managing the DDNS reverse updates is typically simple in the second
case, as the updated server is located at the local site, and case, as the updated server is located at the local site, and
arguably IP address-based authentication could be sufficient (or if arguably IP address-based authentication could be sufficient (or if
not, setting up security relationships would be simpler). As there not, setting up security relationships would be simpler). As there
is an explicit (security) relationship between the parties in the is an explicit (security) relationship between the parties in the
third case, setting up the security relationships to allow reverse third case, setting up the security relationships to allow reverse
DDNS updates should be rather straightforward as well (but IP DDNS updates should be rather straightforward as well (but IP
address-based authentication might not be acceptable). In the first address-based authentication might not be acceptable). In the first
case, however, setting up and managing such relationships might be a case, however, setting up and managing such relationships might be a
lot more difficult. 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 that
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
The DNS-ALG component of NAT-PT mangles A records to look like AAAA The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look
records to the IPv6-only nodes. Numerous problems have been like AAAA records to the IPv6-only nodes. Numerous problems have
identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is been identified with [WIP-AD2005]. This is a strong reason not to
a strong reason not to use NAT-PT in the first place. use NAT-PT in the first place.
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 [RFC4192] is that an application which looks renumbering procedures [RFC4192] is that an application that looks up
up a DNS name disregards information such as TTL, and uses the result 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 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 that 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
enough to organize the data structures and functions in such a manner clever enough to organize the data structures and functions in such a
that look-ups get refreshed now and then. manner that lookups 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 [RFC4213] by Erik Nordmark and Bob provisioning were moved here from [RFC4213] 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. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei
Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided
useful feedback during the WG last call. Thomas Narten provided useful feedback during the WG last call. Thomas Narten provided
extensive feedback during the IESG evaluation. extensive feedback during the IESG evaluation.
10. IANA Considerations 10. Security Considerations
This memo includes no request to IANA.
11. 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 -- they could only be considered very weak and cannot be recommended -- they could only be considered
in the environments where ingress filtering [RFC3704] has been in the environments where ingress filtering [RFC3704] has been
deployed. On the other hand, it should be noted that setting up an deployed. On the other hand, it should be noted that setting up an
authorization mechanism (e.g., a shared secret, or public-private authorization mechanism (e.g., a shared secret, or public-private
keys) between a node and the DNS server has to be done manually, and keys) between a node and the DNS server has to be done manually, and
may require quite a bit of time and expertise. may require quite a bit of time and expertise.
To re-emphasize what was already stated, the reverse+forward DNS To re-emphasize what was already stated, the reverse+forward DNS
check provides very weak security at best, and the only check provides very weak security at best, and the only
(questionable) security-related use for them may be in conjunction (questionable) security-related use for them may be in conjunction
with other mechanisms when authenticating a user. with other mechanisms when authenticating a user.
12. References 11. References
12.1. Normative References
[I-D.ietf-dnsop-ipv6-dns-configuration] 11.1. Normative References
Jeong, J., "IPv6 Host Configuration of DNS Server
Information Approaches",
draft-ietf-dnsop-ipv6-dns-configuration-06 (work in
progress), May 2005.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and
STD 13, RFC 1034, November 1987. facilities", STD 13, RFC 1034, November 1987.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS
RFC 2136, April 1997. UPDATE)", RFC 2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton,
and Operation of Secondary DNS Servers", BCP 16, RFC 2182, "Selection and Operation of Secondary DNS Servers",
July 1997. BCP 16, RFC 2182, July 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999. RFC 2671, August 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS)
Update", RFC 3007, November 2000. Dynamic Update", RFC 3007, November 2000.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001. January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
August 2001. August 2001.
skipping to change at page 22, line 15 skipping to change at page 21, line 6
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363, Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002. August 2002.
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
Support for Internet Protocol version 6 (IPv6)", RFC 3364, Support for Internet Protocol version 6 (IPv6)",
August 2002. RFC 3364, August 2002.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003. October 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration
(DHCP) Service for IPv6", RFC 3736, April 2004. Protocol (DHCP) Service for IPv6", RFC 3736,
April 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport
Guidelines", BCP 91, RFC 3901, September 2004. Operational Guidelines", BCP 91, RFC 3901,
September 2004.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition", Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005. RFC 4038, March 2005.
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior
DNS Queries for IPv6 Addresses", RFC 4074, May 2005. Against DNS Queries for IPv6 Addresses", RFC 4074,
May 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day",
September 2005. RFC 4192, September 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
12.2. Informative References [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[I-D.durand-dnsop-dont-publish] [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
Durand, A. and T. Chown, "To publish, or not to publish, Information Approaches", RFC 4339, February 2006.
that is the question.", draft-durand-dnsop-dont-publish-00
(work in progress), February 2005.
[I-D.huitema-v6ops-teredo] 11.2. Informative References
Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", draft-huitema-v6ops-teredo-05 (work in progress),
April 2005.
[I-D.huston-6to4-reverse-dns] [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Huston, G., "6to4 Reverse DNS Delegation", Translation - Protocol Translation (NAT-PT)", RFC 2766,
draft-huston-6to4-reverse-dns-03 (work in progress), February 2000.
October 2004.
[I-D.ietf-dhc-ddns-resolution] [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among for specifying the location of services (DNS SRV)",
DHCP Clients", draft-ietf-dhc-ddns-resolution-10 (work in RFC 2782, February 2000.
progress), September 2005.
[I-D.ietf-dhc-fqdn-option] [RFC2826] Internet Architecture Board, "IAB Technical Comment on
Stapp, M., "The DHCP Client FQDN Option", the Unique DNS Root", RFC 2826, May 2000.
draft-ietf-dhc-fqdn-option-11 (work in progress),
September 2005.
[I-D.ietf-dnsext-dhcid-rr] [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Stapp, M., "A DNS RR for Encoding DHCP Information (DHCID Multihomed Networks", BCP 84, RFC 3704, March 2004.
RR)", draft-ietf-dnsext-dhcid-rr-10 (work in progress),
September 2005.
[I-D.ietf-dnsop-bad-dns-res] [RFC3972] Aura, T., "Cryptographically Generated Addresses
Larson, M. and P. Barber, "Observed DNS Resolution (CGA)", RFC 3972, March 2005.
Misbehavior", draft-ietf-dnsop-bad-dns-res-04 (work in
progress), July 2005.
[I-D.ietf-dnsop-inaddr-required] [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", Material in DNS", RFC 4025, March 2005.
draft-ietf-dnsop-inaddr-required-07 (work in progress),
August 2005.
[I-D.ietf-v6ops-natpt-to-exprmntl] [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Mechanisms for IPv6 Hosts and Routers", RFC 4213,
Experimental", draft-ietf-v6ops-natpt-to-exprmntl-02 (work October 2005.
in progress), October 2005.
[I-D.ietf-v6ops-onlinkassumption] [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Generation Partnership Project (3GPP) Networks",
Considered Harmful", draft-ietf-v6ops-onlinkassumption-03 RFC 4215, October 2005.
(work in progress), May 2005.
[I-D.ietf-v6ops-v6onbydefault] [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack Network Address Translations (NATs)", RFC 4380,
IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 February 2006.
(work in progress), July 2004.
[I-D.jeong-dnsop-ipv6-dns-discovery] [TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit
Jeong, J., "IPv6 Router Advertisement Option for DNS handling and additional data" on DNSEXT mailing list,
Configuration", draft-jeong-dnsop-ipv6-dns-discovery-05 Message-
(work in progress), July 2005. Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August
1, 2005, <http://ops.ietf.org/lists/namedroppers/
namedroppers.2005/msg01102.html>.
[I-D.ohta-preconfigured-dns] [WIP-AD2005] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Ohta, M., "Preconfigured DNS Server Addresses", Experimental", Work in Progress, October 2005.
draft-ohta-preconfigured-dns-01 (work in progress),
February 2004.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address [WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to
Translation - Protocol Translation (NAT-PT)", RFC 2766, publish, that is the question", Work in Progress,
February 2000. October 2005.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation
specifying the location of services (DNS SRV)", RFC 2782, Specification", Work in Progress, November 2005.
February 2000.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the [WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS
Unique DNS Root", RFC 2826, May 2000. Configuration", Work in Progress, January 2006.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution
Networks", BCP 84, RFC 3704, March 2004. Misbehavior", Work in Progress, February 2006.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in
RFC 3972, March 2005. Progress, February 2004.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
Material in DNS", RFC 4025, March 2005. Considered Harmful", Work in Progress, January 2006.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual
for IPv6 Hosts and Routers", RFC 4213, October 2005. Stack IPv6 on by Default", Work in Progress, July 2004.
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third [WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in
Generation Partnership Project (3GPP) Networks", RFC 4215, Progress, March 2006.
October 2005.
[TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit handling [WIP-S2005b] Stapp, M., "A DNS RR for Encoding DHCP Information
and additional data" on DNSEXT mailing list, Message-Id: (DHCID RR)", Work in Progress, March 2006.
y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August [WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR
1st 2005, <http://ops.ietf.org/lists/namedroppers/ Mapping", Work in Progress, August 2005.
namedroppers.2005/msg01102.html>.
[WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts
among DHCP Clients", Work in Progress, March 2006.
Appendix A. Unique Local Addressing Considerations for DNS Appendix A. Unique Local Addressing Considerations for DNS
Unique local addresses [RFC4193] have replaced the now-deprecated Unique local addresses [RFC4193] have replaced the now-deprecated
site-local addresses [RFC3879]. From the perspective of the DNS, the site-local addresses [RFC3879]. From the perspective of the DNS, the
locally generated unique local addresses (LUL) and site-local locally generated unique local addresses (LUL) and site-local
addresses have similar properties. addresses have similar properties.
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 local addresses within a site, this implies the To actually use 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 local addresses must not be published in the public DNS. is that local addresses must not be published in the public DNS.
To faciliate reverse DNS (if desired) with local addresses, the stub To facilitate reverse DNS (if desired) with local addresses, the stub
resolvers must look for DNS information from the local DNS servers, resolvers must look for DNS information from the local DNS servers,
not e.g. starting from the root servers, so that the local not, e.g., starting from the root servers, so that the local
information may be provided locally. Note that the experience of information may be provided locally. Note that the experience of
private addresses in IPv4 has shown that the root servers get loaded private addresses in IPv4 has shown that the root servers get loaded
for requests for private address lookups in any case. This for requests for private address lookups in any case. This
requirement is discussed in [RFC4193]. requirement is discussed in [RFC4193].
Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments
DNS responses do not always fit in a single UDP packet. We'll DNS responses do not always fit in a single UDP packet. We'll
examine the cases which happen when this is due to too much data in examine the cases that happen when this is due to too much data in
the Additional Section. the Additional section.
B.1. Description of Additional Data Scenarios B.1. Description of Additional Data Scenarios
There are two kinds of additional data: There are two kinds of additional data:
1. "critical" additional data; this must be included in all 1. "critical" additional data; this must be included in all
scenarios, with all the RRsets, and scenarios, with all the RRsets, and
2. "courtesy" additional data; this could be sent in full, with only 2. "courtesy" additional data; this could be sent in full, with only
a few RRsets, or with no RRsets, and can be fetched separately as a few RRsets, or with no RRsets, and can be fetched separately as
well, but at the cost of additional queries. well, but at the cost of additional queries.
The responding server can algorithmically determine which type the The responding server can algorithmically determine which type the
additional data is by checking whether it's at or below a zone cut. additional data is by checking whether it's at or below a zone cut.
Only those additional data records (even if sometimes carelessly Only those additional data records (even if sometimes carelessly
termed "glue") are considered "critical" or real "glue" if and only termed "glue") are considered "critical" or real "glue" if and only
if they meet the abovementioned condition, as specified in Section if they meet the above-mentioned condition, as specified in Section
4.2.1 of [RFC1034]. 4.2.1 of [RFC1034].
Remember that resource record sets (RRsets) are never "broken up", so Remember that resource record sets (RRsets) are never "broken up", so
if a name has 4 A records and 5 AAAA records, you can either return 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 all 9, all 4 A records, all 5 AAAA records, or nothing. In
particular, notice that for the "critical" additional data getting particular, notice that for the "critical" additional data getting
all the RRsets can be critical. all the RRsets can be critical.
In particular, [RFC2181] specifies (in Section 9) that: In particular, [RFC2181] specifies (in Section 9) that:
a. if all the "critical" RRsets do not fit, the sender should set a. if all the "critical" RRsets do not fit, the sender should set
the TC bit, and the recipient should discard the whole response the TC bit, and the recipient should discard the whole response
and retry using mechanism allowing larger responses such as TCP. and retry using mechanism allowing larger responses such as TCP.
b. "courtesy" additional data should not cause the setting of TC b. "courtesy" additional data should not cause the setting of the TC
bit, but instead all the non-fitting additional data RRsets bit, but instead all the non-fitting additional data RRsets
should be removed. should be removed.
An example of the "courtesy" additional data is A/AAAA records in An example of the "courtesy" additional data is A/AAAA records in
conjunction with MX records as shown in Section 4.4; an example of conjunction with MX records as shown in Section 4.4; an example of
the "critical" additional data is shown below (where getting both the the "critical" additional data is shown below (where getting both the
A and AAAA RRsets is critical w.r.t. to the NS RR): A and AAAA RRsets is critical with respect to the NS RR):
child.example.com. IN NS ns.child.example.com. child.example.com. IN NS ns.child.example.com.
ns.child.example.com. IN A 192.0.2.1 ns.child.example.com. IN A 192.0.2.1
ns.child.example.com. IN AAAA 2001:db8::1 ns.child.example.com. IN AAAA 2001:db8::1
When there is too much "courtesy" additional data, at least the non- When there is too much "courtesy" additional data, at least the non-
fitting RRsets should be removed [RFC2181]; however, as the fitting RRsets should be removed [RFC2181]; however, as the
additional data is not critical, even all of it could be safely additional data is not critical, even all of it could be safely
removed. removed.
When there is too much "critical" additional data, TC bit will have When there is too much "critical" additional data, TC bit will have
to be set, and the recipient should ignore the response and retry to be set, and the recipient should ignore the response and retry
using TCP; if some data were to be left in the UDP response, the using TCP; if some data were to be left in the UDP response, the
issue is which data could be retained. issue is which data could be retained.
However, the practise may differ from the specification. Testing and However, the practice may differ from the specification. Testing and
code analysis of 3 recent implementations [TC-TEST] confirm this. code analysis of three recent implementations [TC-TEST] confirm this.
None of the tested implementations have a strict separation of None of the tested implementations have a strict separation of
critical and courtesy additional data, while some forms of additional critical and courtesy additional data, while some forms of additional
data may be treated preferably. All the implementations remove some data may be treated preferably. All the implementations remove some
(critical or courtesy) additional data RRsets without setting TC bit (critical or courtesy) additional data RRsets without setting the TC
if the response would not otherwise fit. bit if the response would not otherwise fit.
Failing to discard the response with TC bit or omitting critical Failing to discard the response with the TC bit or omitting critical
information but not setting TC bit lead to an unrecoverable problem. information but not setting the TC bit lead to an unrecoverable
Omitting only some of the RRsets if all would not fit (but not problem. Omitting only some of the RRsets if all would not fit (but
setting TC bit) leads to a performance problem. These are discussed not setting the TC bit) leads to a performance problem. These are
in the next two subsections. discussed in the next two subsections.
B.2. Which Additional Data to Keep, If Any? B.2. Which Additional Data to Keep, If Any?
NOTE: omitting some critical additional data instead of setting the
TC bit violates a 'should' in Section 9 of RFC2181. However, as many
implementations still do that [TC-TEST], operators need to understand
its implications, and we describe that behavior as well.
If the implementation decides to keep as much data (whether If the implementation decides to keep as much data (whether
"critical" or "courtesy") as possible in the UDP responses, it might "critical" or "courtesy") as possible in the UDP responses, it might
be tempting to use the transport of the DNS query as a hint in either be tempting to use the transport of the DNS query as a hint in either
of these cases: return the AAAA records if the query was done over of these cases: return the AAAA records if the query was done over
IPv6, or return the A records if the query was done over IPv4. IPv6, or return the A records if the query was done over IPv4.
However, this breaks the model of independence of DNS transport and However, this breaks the model of independence of DNS transport and
resource records, as noted in Section 1.2. resource records, as noted in Section 1.2.
With courtesy additional data, as long as enough RRsets will be With courtesy additional data, as long as enough RRsets will be
removed so that TC will not be set, it is allowed to send as many removed so that TC will not be set, it is allowed to send as many
skipping to change at page 27, line 44 skipping to change at page 26, line 42
the response and retry using TCP) in addition to setting the TC bit. the response and retry using TCP) in addition to setting the TC bit.
If the process for selecting "something" from the critical data would If the process for selecting "something" from the critical data would
otherwise be practically "flipping the coin" between A and AAAA otherwise be practically "flipping the coin" between A and AAAA
records, it could be argued that if one looked at the transport of records, it could be argued that if one looked at the transport of
the query, it would have a larger possibility of being right than the query, it would have a larger possibility of being right than
just 50/50. In other words, if the returned critical additional data just 50/50. In other words, if the returned critical additional data
would have to be selected somehow, using something more sophisticated would have to be selected somehow, using something more sophisticated
than a random process would seem justifiable. than a random process would seem justifiable.
That is, leaving in some intelligently selected critical additional That is, leaving in some intelligently selected critical additional
data is a tradeoff between creating an optimization for those data is a trade-off between creating an optimization for those
resolvers which ignore the "should discard" recommendation, and resolvers that ignore the "should discard" recommendation and causing
causing a protocol problem by propagating inconsistent information a protocol problem by propagating inconsistent information about
about "critical" records in the caches. "critical" records in the caches.
Similarly, leaving in the complete courtesy additional data RRsets Similarly, leaving in the complete courtesy additional data RRsets
instead of removing all the RRsets is a performance tradeoff as instead of removing all the RRsets is a performance trade-off as
described in the next section. described in the next section.
B.3. Discussion of the Potential Problems B.3. Discussion of the Potential Problems
As noted above, the temptation for omitting only some of the As noted above, the temptation for omitting only some of the
additional data could be problematic. This is discussed more below. additional data could be problematic. This is discussed more below.
For courtesy additional data, this causes a potential performance For courtesy additional data, this causes a potential performance
problem as this requires that the clients issue re-queries for the problem as this requires that the clients issue re-queries for the
potentially omitted RRsets. For critical additional data, this potentially omitted RRsets. For critical additional data, this
skipping to change at page 28, line 24 skipping to change at page 27, line 24
discarded and the query not re-tried with TCP, as the nameservers discarded and the query not re-tried with TCP, as the nameservers
might be reachable only through the omitted RRsets. might be reachable only through the omitted RRsets.
If an implementation would look at the transport used for the query, If an implementation would look at the transport used for the query,
it is worth remembering that often the host using the records is it is worth remembering that often the host using the records is
different from the node requesting them from the authoritative DNS different from the node requesting them from the authoritative DNS
server (or even a caching resolver). So, whichever version the server (or even a caching resolver). So, whichever version the
requestor (e.g., a recursive server in the middle) uses makes no requestor (e.g., a recursive server in the middle) uses makes no
difference to the ultimate user of the records, whose transport difference to the ultimate user of the records, whose transport
capabilities might differ from those of the requestor. This might capabilities might differ from those of the requestor. This might
result in e.g., inappropriately returning A records to an IPv6-only result in, e.g., inappropriately returning A records to an IPv6-only
node, going through a translation, or opening up another IP-level node, going through a translation, or opening up another IP-level
session (e.g., a PDP context [RFC4215]). Therefore, at least in many session (e.g., a Packet Data Protocol (PDP) context [RFC4215]).
scenarios, it would be very useful if the information returned would Therefore, at least in many scenarios, it would be very useful if the
be consistent and complete -- or if that is not feasible, return no information returned would be consistent and complete -- or if that
misleading information but rather leave it to the client to query is not feasible, leave it to the client to query again.
again.
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 that will be
returned either truncated (or missing some RRsets, depending on returned truncated (or missing some RRsets, depending on
implementations) to the users. A protocol fix for this is using implementations) to the users. A protocol fix for this is using
EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity
pushing up the relevant threshold. Further, DNS server for larger UDP packet sizes, pushing up the relevant threshold.
implementations should rather omit courtesy additional data Further, DNS server implementations should omit courtesy additional
completely rather than including only some RRsets [RFC2181]. An data completely rather than including only some RRsets [RFC2181]. An
operational fix for this is having the DNS server implementations operational fix for this is having the DNS server implementations
return a warning when the administrators create zones which would return a warning when the administrators create zones that would
result in too much additional data being returned. Further, DNS result in too much additional data being returned. Further, DNS
server implementations should warn of or disallow such zone server implementations should warn of or disallow such zone
configurations which are recursive or otherwise difficult to manage configurations that are recursive or otherwise difficult to manage by
by the protocol. the protocol.
Additionally, to avoid the case where an application would not get an
address at all due to some of courtesy additional data being omitted,
the resolvers should be able to query the specific records of the
desired protocol, not just rely on getting all the required RRsets in
the additional section.
Authors' Addresses Authors' Addresses
Alain Durand Alain Durand
Comcast Comcast
150 Market st 1500 Market St.
Philadelphia, PA 19102 Philadelphia, PA 19102
USA USA
Email: Alain_Durand@cable.comcast.com EMail: Alain_Durand@cable.comcast.com
Johan Ihren Johan Ihren
Autonomica Autonomica
Bellmansgatan 30 Bellmansgatan 30
SE-118 47 Stockholm SE-118 47 Stockholm
Sweden Sweden
Email: johani@autonomica.se EMail: johani@autonomica.se
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo Espoo
Finland Finland
Email: psavola@funet.fi EMail: psavola@funet.fi
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
skipping to change at page 30, line 29 skipping to change at page 29, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. 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 that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 152 change blocks. 
411 lines changed or deleted 353 lines changed or added

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