draft-ietf-dnsop-ipv6-dns-issues-10.txt   draft-ietf-dnsop-ipv6-dns-issues-11.txt 
DNS Operations WG A. Durand DNS Operations WG A. Durand
Internet-Draft SUN Microsystems, Inc. Internet-Draft SUN Microsystems, Inc.
Expires: April 24, 2005 J. Ihren Expires: January 17, 2006 J. Ihren
Autonomica Autonomica
P. Savola P. Savola
CSC/FUNET CSC/FUNET
October 24, 2004 July 16, 2005
Operational Considerations and Issues with IPv6 DNS Operational Considerations and Issues with IPv6 DNS
draft-ietf-dnsop-ipv6-dns-issues-10.txt draft-ietf-dnsop-ipv6-dns-issues-11.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2005. This Internet-Draft will expire on January 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo presents operational considerations and issues with IPv6 This memo presents operational considerations and issues with IPv6
Domain Name System (DNS), including a summary of special IPv6 Domain Name System (DNS), including a summary of special IPv6
addresses, documentation of known DNS implementation misbehaviour, addresses, documentation of known DNS implementation misbehaviour,
recommendations and considerations on how to perform DNS naming for recommendations and considerations on how to perform DNS naming for
service provisioning and for DNS resolver IPv6 support, service provisioning and for DNS resolver IPv6 support,
considerations for DNS updates for both the forward and reverse considerations for DNS updates for both the forward and reverse
trees, and miscellaneous issues. This memo is aimed to include a trees, and miscellaneous issues. This memo is aimed to include a
skipping to change at page 2, line 25 skipping to change at page 2, line 24
1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5
1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . 6
2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6
2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6
3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7
3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7
3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7
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 . . . . . . . . 8
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 . . . . . 9
4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
4.4.1 Description of Additional Data Scenarios . . . . . . . 10 4.4.1 TTL With Courtesy Additional Data . . . . . . . . . . 10
4.4.2 Which Additional Data to Keep, If Any? . . . . . . . . 11 4.4.2 TTL With Critical Additional Data . . . . . . . . . . 10
4.4.3 Discussion of the Problems . . . . . . . . . . . . . . 12 4.5 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11
4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 13 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11
4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 14 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 15 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13
5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 15 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13
5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 16 6. Considerations about Forward DNS Updating . . . . . . . . . . 13
5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 17 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
6. Considerations about Forward DNS Updating . . . . . . . . . . 17 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14
6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15
6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 18 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
7. Considerations about Reverse DNS Updating . . . . . . . . . . 19 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 19 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16
7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 20 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 20 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18
7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 21 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 22 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19
8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 23 8.2 Renumbering Procedures and Applications' Use of DNS . . . 19
8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8.2 Renumbering Procedures and Applications' Use of DNS . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . 24 11.1 Normative References . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.2 Informative References . . . . . . . . . . . . . . . . . . 22
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
11.2 Informative References . . . . . . . . . . . . . . . . . . . 26 A. Unique Local Addressing Considerations for DNS . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 B. Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25
A. Site-local Addressing Considerations for DNS . . . . . . . . . 29 B.1 Description of Additional Data Scenarios . . . . . . . . . 26
B.2 Which Additional Data to Keep, If Any? . . . . . . . . . . 27
B.3 Discussion of the Potential Problems . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . 30
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
skipping to change at page 4, line 33 skipping to change at page 4, line 33
they relate to DNS. The third section describes observed DNS they relate to DNS. The third section describes observed DNS
implementation misbehaviours which have a varying effect on the use implementation misbehaviours which have a varying effect on the use
of IPv6 records with DNS. The fourth section lists recommendations of IPv6 records with DNS. The fourth section lists recommendations
and considerations for provisioning services with DNS. The fifth and considerations for provisioning services with DNS. The fifth
section in turn looks at recommendations and considerations about section in turn looks at recommendations and considerations about
providing IPv6 support in the resolvers. The sixth and seventh providing IPv6 support in the resolvers. The sixth and seventh
sections describe considerations with forward and reverse DNS sections describe considerations with forward and reverse DNS
updates, respectively. The eighth section introduces several updates, respectively. The eighth section introduces several
miscellaneous IPv6 issues relating to DNS for which no better place miscellaneous IPv6 issues relating to DNS for which no better place
has been found in this memo. Appendix A looks briefly at the has been found in this memo. Appendix A looks briefly at the
requirements for site-local addressing. requirements for unique local addressing.
1.1 Representing IPv6 Addresses in DNS Records 1.1 Representing IPv6 Addresses in DNS Records
In the forward zones, IPv6 addresses are represented using AAAA In the forward zones, IPv6 addresses are represented using AAAA
records. In the reverse zones, IPv6 address are represented using records. In the reverse zones, IPv6 address are represented using
PTR records in the nibble format under the ip6.arpa. tree. See 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
skipping to change at page 6, line 9 skipping to change at page 6, line 9
2. DNS Considerations about Special IPv6 Addresses 2. DNS Considerations about Special IPv6 Addresses
There are a couple of IPv6 address types which are somewhat special; There are a couple of IPv6 address types which are somewhat special;
these are considered here. these are considered here.
2.1 Limited-scope Addresses 2.1 Limited-scope Addresses
The IPv6 addressing architecture [RFC3513] includes two kinds of The IPv6 addressing architecture [RFC3513] 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 (fec0::/10). The site-local addresses have been deprecated [RFC3879]
[RFC3879], and are only discussed 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 connected link) significance [I-D.durand-dnsop-dont-publish].
[I-D.ietf-dnsop-dontpublish-unreachable].
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 which maps
a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
If the reverse DNS population would be desirable (see Section 7.1 for 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.
[I-D.moore-6to4-dns], some more applicable than the others.
The main proposal [I-D.huston-6to4-reverse-dns] aims to design an The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
autonomous reverse-delegation system that anyone being capable of autonomous reverse-delegation system that anyone being capable of
communicating using a specific 6to4 address would be able to set up a communicating using a specific 6to4 address would be able to set up a
reverse delegation to the corresponding 6to4 prefix. This could be reverse delegation to the corresponding 6to4 prefix. This could be
deployed by e.g., Regional Internet Registries (RIRs). This is a deployed by e.g., Regional Internet Registries (RIRs). This is a
practical solution, but may have some scalability concerns. practical solution, but may have some scalability concerns.
2.4 Other Transition Mechanisms 2.4 Other Transition Mechanisms
6to4, above, is mentioned as a case of an IPv6 transition mechanism 6to4 is mentioned as a case of an IPv6 transition mechanism requiring
requiring special considerations. In general, mechanisms which special considerations. In general, mechanisms which include a
include a special prefix may need a custom solution; otherwise, for special prefix may need a custom solution; otherwise, for example
example when IPv4 address is embedded as the suffix or not embedded when IPv4 address is embedded as the suffix or not embedded at all,
at all, special solutions are likely not needed. This is why only special solutions are likely not needed.
6to4 and Teredo [I-D.huitema-v6ops-teredo] are described.
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; this is because the another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops-
IPv6 address is based on the IPv4 address and UDP port of the current teredo]; this is because the IPv6 address is based on the IPv4
NAT mapping which is likely to be relatively short-lived. address and UDP port of the current NAT mapping which is likely to be
relatively short-lived.
3. Observed DNS Implementation Misbehaviour 3. Observed DNS Implementation Misbehaviour
Several classes of misbehaviour in DNS servers, load-balancers and Several classes of misbehaviour in DNS servers, load-balancers and
resolvers have been observed. Most of these are rather generic, not resolvers have been observed. Most of these are rather generic, not
only applicable to IPv6 -- but in some cases, the consequences of only applicable to IPv6 -- but in some cases, the consequences of
this misbehaviour are extremely severe in IPv6 environments and this misbehaviour are extremely severe in IPv6 environments and
deserve to be mentioned. deserve to be mentioned.
3.1 Misbehaviour of DNS Servers and Load-balancers 3.1 Misbehaviour of DNS Servers and Load-balancers
There are several classes of misbehaviour in certain DNS servers and There are several classes of misbehaviour in certain DNS servers and
load-balancers which have been noticed and documented load-balancers which have been noticed and documented [RFC4074]: some
[I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations implementations silently drop queries for unimplemented DNS records
silently drop queries for unimplemented DNS records types, or provide types, or provide wrong answers to such queries (instead of a proper
wrong answers to such queries (instead of a proper negative reply). negative reply). While typically these issues are not limited to
While typically these issues are not limited to AAAA records, the AAAA records, the problems are aggravated by the fact that AAAA
problems are aggravated by the fact that AAAA records are being records are being queried instead of (mainly) A records.
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 timeouts 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
skipping to change at page 8, line 13 skipping to change at page 8, line 9
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 logically separate services by a node separate It makes sense to keep information about separate services logically
in the DNS, due to a number of reasons, for example: separate in the DNS by using a different DNS hostname for each
service. There are several reasons for doing this, for example:
o It allows more flexibility and ease for migration of (only a part 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., TTL) for each
service, and service, and
o It allows deciding separately for each service whether to publish o It allows deciding separately for each service whether to publish
the IPv6 addresses or not (in cases if some services are more the IPv6 addresses or not (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 Section understand the considerations described in Section 4.2 and
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 loops do not occur. DNS can provide a layer of indirection between
service names and where the service actually is, and using which service names and where the service actually is, and using which
addresses. (Obviously, when wanting to reach a specific node, one addresses. (Obviously, when wanting to reach a specific node, one
should use the hostname rather than a service name.) 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 be either 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
a degree, by modifying the DNS search path; however, this is a a degree, by modifying the DNS search path; however, this is a
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 Section performance is lower than IPv4, or does not work as well (see
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 which 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 service as recommended, all the services of the node should be IPv6-
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 have 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 important
if the service offered using both protocols is of roughly equal that the service offered using both protocols is of roughly equal
quality, using the appropriate metrics for the service (e.g., quality, using the appropriate metrics for the service (e.g.,
latency, throughput, low packet loss, general reliability, etc.) -- latency, throughput, low packet loss, general reliability, etc.) --
this is typically very important especially for interactive or this is typically very important especially for interactive or real-
real-time services. In many cases, the quality of IPv6 connectivity time services. In many cases, the quality of IPv6 connectivity may
may not yet be equal to that of IPv4, at least globally -- this has not yet be equal to that of IPv4, at least globally -- this has to be
to be taken into consideration when enabling services taken into consideration when enabling services.
[I-D.savola-v6ops-6bone-mess].
4.4 Behaviour of Additional Data in IPv4/IPv6 Environments
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
the Additional Section.
4.4.1 Description of Additional Data Scenarios
There are two kinds of additional data:
1. "critical" additional data; this must be included in all
scenarios, with all the RRsets, and
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
well, but at the cost of additional queries.
The responding server can algorithmically determine which type the
additional data is by checking whether it's at or below a zone cut.
Only those additional data records (even if sometimes carelessly
termed "glue") are considered "critical" or real "glue" if and only
if they meet the abovementioned condition, as specified in Section
4.2.1 of [RFC1034].
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
all 9, all 4 A records, all 5 AAAA records or nothing. In
particular, notice that for the "critical" additional data getting
all the RRsets can be critical.
In particular, [RFC2181] specifies (in Section 9) that:
a. if all the "critical" RRsets do not fit, the sender should set
the TC bit, and the recipient should discard the whole response
and retry using mechanism allowing larger responses such as TCP.
b. "courtesy" additional data should not cause the setting of TC
bit, but instead all the non-fitting additional data RRsets
should be removed.
An example of the "courtesy" additional data is A/AAAA records in
conjunction of MX records is shown in Section 4.5; an example of the
"critical" additional data is shown below (where getting both the A
and AAAA RRsets is critical):
child.example.com. IN NS ns.child.example.com.
ns.child.example.com. IN A 192.0.2.1
ns.child.example.com. IN AAAA 2001:db8::1
When there is too much courtesy additional data, at least the
non-fitting RRsets should be removed [RFC2181]; however, as the
additional data is not critical, even all of it could be safely
removed.
When there is too much critical additional data, TC bit will have 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 issue is
which data could be retained.
Failing to discard the response with TC bit set leads to a protocol
problem. Omitting only some of the RRsets if all would not fit leads
to a performance problem. These are discussed in Section 4.4.3.
4.4.2 Which Additional Data to Keep, If Any?
If the implementation decides to keep as much data (whether
"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
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.
However, this breaks the model of independence of DNS transport and
resource records, as noted in Section 1.2.
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
complete RRsets as the implementations prefers. However, the
implementations are also free to omit all such RRsets, even if
complete. Removing all the RRsets if some would not fit obviates a
performance problem, which would require the users to issue second
queries to obtain consistent information.
With critical additional data, the alternatives are either returning
nothing (and absolutely requiring a retry with TCP) or returning
something (working also in the case if the recipient does not discard
the response and retry using TCP) in addition to setting the TC bit.
If the process for selecting "something" from the critical data would
otherwise be practically "flipping the coin" between A and AAAA
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
just 50/50. In other words, if the returned critical additional data
would have to be selected somehow, using something more sophisticated
than a random process would seem justifiable.
That is, leaving in some intelligently selected critical additional
data is a tradeoff between creating an optimization for those
resolvers which ignore the "should discard" recommendation, and a
causing a protocol problem by propagating inconsistent information
about "critical" records in the caches.
Similarly, leaving in the complete courtesy additional data RRsets
instead of removing all the RRsets is a performance tradeoff as
described in the next section.
4.4.3 Discussion of the Problems
As noted above, the temptation for omitting only some of the
additional data based on the transport of the query could be
problematic. In particular, there appears to be little justification
for doing so in the case of "courtesy" data.
For courtesy additional data, this causes a performance problem as
this requires that the clients issue re-query for the potentially
omitted RRsets. For critical additional data, this causes a
potential protocol problem if the response is not discarded and the
query not re-tried with TCP, as the nameservers might be reachable
only through the omitted RRsets.
If an implementation would look at the transport used for the query,
it is worth remembering that often the host using the records is
different from the node requesting them from the authoritative DNS
server (or even a caching resolver). So, whichever version the
requestor (e.g., a recursive server in the middle) uses makes no
difference to the ultimate user of the records, whose transport
capabilities might differ from those of the requestor. This might
result in e.g., inappropriately returning A records to an IPv6-only
node, going through a translation, or opening up another IP-level
session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
Therefore, at least in many scenarios, it would be very useful if the
information returned would be consistent and complete -- or if that
is not feasible, return no misleading information but rather leave it
to the client to query again.
The problem of too much additional data seems to be an operational
one: the zone administrator entering too many records which will be
returned either truncated (or missing some RRsets, depending on
implementations) to the users. A protocol fix for this is using
EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
pushing up the relevant threshold. Further, DNS server
implementations should rather omit courtesy additional data
completely rather than including only some RRsets [RFC2181]. An
operational fix for this is having the DNS server implementations
return a warning when the administrators create zones which would
result in too much additional data being returned. Further, DNS
server implementations should warn of or disallow such zone
configurations which are recursive or otherwise difficult to manage
by 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.
4.5 The Use of TTL for IPv4 and IPv6 RRs
In the previous section, we discussed a danger with queries, 4.4 The Use of TTL for IPv4 and IPv6 RRs
potentially leading to omitting RRsets from the additional section;
this could happen to both critical and "courtesy" additional data
(however, both of these are recommended against in [RFC2181]). This
section discusses another problem with courtesy additional data,
leading to omitting RRsets in cached data, highlighted in the
IPv4/IPv6 environment.
The behaviour of DNS caching when different TTL values are used for The behaviour of DNS caching when different TTL values are used for
different RRsets of the same name requires explicit discussion. For different RRsets of the same name calls for explicit discussion. For
example, let's consider a part of a zone: 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
When a caching resolver asks for the MX record of example.com, it ...
gets back "foo.example.com". It may also get back either one or both
of the A and AAAA records in the additional section. So, there are
three cases about returning records for the MX in the additional
section:
1. We get back no A or AAAA RRsets: this is the simplest case, child.example.com. 300 IN NS ns.child.example.com.
because then we have to query which information is required ns.child.example.com. 300 IN A 192.0.2.1
explicitly, guaranteeing that we get all the information we're ns.child.example.com. 100 IN AAAA 2001:db8::1
interested in.
2. We get back all the RRsets: this is an optimization as there is In the former case, we have "courtesy" additional data; in the
no need to perform more queries, causing lower latency. However, latter, we have "critical" additional data. See more extensive
it is impossible to guarantee that in fact we would always get background discussion of additional data handling in Appendix B.
back all the records (the only way to ensure that is to send a
AAAA query for the name after getting the cached reply with A
records or vice versa).
3. We only get back A or AAAA RRsets even if both existed: this is 4.4.1 TTL With Courtesy Additional Data
indistinguishable from the previous case, and may have
performance problems at least in certain environments as
described in the previous section.
As the third case was considered in the previous section, we assume When a caching resolver asks for the MX record of example.com, it
we get back both A and AAAA records of foo.example.com, or the stub gets back "foo.example.com". It may also get back either one or both
resolver explicitly asks, in two separate queries, both A and AAAA of the A and AAAA records in the additional section. The resolver
records. 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. behaviour in this scenario is unspecified.
To simplify the situation, it might help to use the same TTL for all 4.4.2 TTL With Critical Additional Data
the resource record sets referring to the same name, unless there is
a particular reason for not doing so. However, there are some
scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
a different strategy is preferable.
Thus, applications that use the response should not rely on a The difference to courtesy additional data is that the A/AAAA records
particular TTL configuration. For example, even if an application served by the parent zone cannot be queried explicitly. Therefore
gets a response that only has the A record in the example described after 100 seconds the AAAA record is removed from the cache(s), but
above, it should be still aware that there could be a AAAA record for the A record remains. Queries for the remaining 200 seconds
"foo.example.com". That is, the application should try to fetch the (provided that there are no further queries from the parent which
missing records itself if it needs the record. could refresh the caches) only return the A record, leading to a
potential opererational situation with unreachable servers.
4.6 IPv6 Transport Guidelines for DNS Servers Similar cache flushing strategies apply in this scenario; the record.
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
skipping to change at page 16, line 19 skipping to change at page 12, line 35
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 [I-D.ietf-v6ops-application-transition]. 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 timeouts.
The third case is a bit more complex: optimizing away the DNS lookups The third case is a bit more complex: optimizing away the DNS lookups
with only link-locals is probably safe (but may be desirable with with only link-locals is probably safe (but may be desirable with
different lookup services which getaddrinfo() may support), as the different lookup services which getaddrinfo() may support), as the
skipping to change at page 17, line 10 skipping to change at page 13, line 26
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 (Aug 2004)
[I-D.ietf-dnsop-ipv6-dns-configuration]. [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 well-known
addresses [I-D.ohta-preconfigured-dns] and the use of Router addresses [I-D.ohta-preconfigured-dns] and the use of Router
Advertisements to convey the information Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns-
[I-D.jeong-dnsop-ipv6-dns-discovery]. 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 which 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 DNS server. Note that this requirement is also fulfilled by an IPv6-
IPv6-only stub resolver pointing to a dual-stack recursive DNS only stub resolver pointing to a dual-stack recursive DNS resolver.
resolver.
6. Considerations about Forward DNS Updating 6. Considerations about Forward DNS Updating
While the topic how to enable updating the forward DNS, i.e., the While the topic 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 which is allowed to update it to point
to a new address. to a new address.
skipping to change at page 19, line 15 skipping to change at page 15, line 29
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 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 administrator could manage the DNS TTL is included in [I-D.ietf-
[I-D.ietf-v6ops-renumbering-procedure]; this could be applied to v6ops-renumbering-procedure]; this could be applied to (smart) hosts
(smart) hosts as well. 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 to either look up some hints
skipping to change at page 19, line 40 skipping to change at page 16, line 6
check, to get a feel whether the user's network administrator has check, to get a feel whether the user's network administrator has
"authorized" the use of the address (on the premises that adding a "authorized" the use of the address (on the premises that adding a
reverse record for an address would signal some form of reverse record for an address would signal some form of
authorization). authorization).
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 it is typically accompanied by other mechanisms, such as a user/
user/password login; the main purpose of the reverse+forward DNS password login; the main purpose of the reverse+forward DNS check is
check is to weed out the majority of unauthorized users, and if to weed out the majority of unauthorized users, and if someone
someone managed to bypass the checks, he would still need to managed to bypass the checks, he would still need to authenticate
authenticate "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 to the reverse DNS, as justified and described in to an IP address in the reverse DNS, as justified and described in
[I-D.ietf-ipseckey-rr]. [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 which use it as a generic authorization (in the sense that a record
exists at all) should be modified as soon as possible to avoid such exists at all) should be modified as soon as possible to avoid such
lookups completely. lookups completely.
The applicability is discussed at more length in The applicability is discussed at more length in [I-D.ietf-dnsop-
[I-D.ietf-dnsop-inaddr-required]. 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
skipping to change at page 21, line 6 skipping to change at page 17, line 21
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 the owner of that address space -- so, assuming stronger form of with the owner of that address space -- so, assuming stronger form of
authorization for reverse DNS updates than an address association is authorization for reverse DNS updates than an address association is
generally unfeasible. 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 cannot send a DNS update using the correct
source address to remove a record. 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 which would remove the record after no traffic
has been seen from a node in a long period of time (e.g., a month or 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 Section to send the update to somehow, similar to as discussed in
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 One should note that Cryptographically Generated Addresses [RFC3972]
[I-D.ietf-send-cga] (CGAs) may require a slightly different kind of (CGAs) may require a slightly different kind of treatment. CGAs are
treatment. CGAs are addresses where the interface identifier is addresses where the interface identifier is calculated from a public
calculated from a public key, a modifier (used as a nonce), the key, a modifier (used as a nonce), the subnet prefix, and other data.
subnet prefix, and other data. Depending on the usage profile, CGAs Depending on the usage profile, CGAs might or might not be changed
might or might not be changed periodically due to e.g., privacy periodically due to e.g., privacy reasons. As the CGA address is not
reasons. As the CGA address is not predicatable, a reverse record predicatable, a reverse record can only reasonably be inserted in the
can only reasonably be inserted in the DNS by the node which DNS by the node which generates the address.
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 to 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
skipping to change at page 23, line 19 skipping to change at page 19, line 32
8. Miscellaneous DNS Considerations 8. Miscellaneous DNS Considerations
This section describes miscellaneous considerations about DNS which This section describes miscellaneous considerations about DNS which
seem related to IPv6, for which no better place has been found in seem related to IPv6, for which no better place has been found in
this document. this document.
8.1 NAT-PT with DNS-ALG 8.1 NAT-PT with DNS-ALG
The DNS-ALG component of NAT-PT mangles A records to look like AAAA The DNS-ALG component of NAT-PT mangles A records to look like AAAA
records to the IPv6-only nodes. Numerous problems have been records to the IPv6-only nodes. Numerous problems have been
identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues]. identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is
This is a strong reason not to use NAT-PT in the first place. a strong reason not to 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 [I-D.ietf-v6ops-renumbering-procedure] is that renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
an application which looks up a DNS name disregards information such an application which looks up a DNS name disregards information such
as TTL, and uses the result obtained from DNS as long as it happens as TTL, and uses the result obtained from DNS as long as it happens
to be stored in the memory of the application. For applications to be stored in the memory of the application. For applications
which run for a long time, this could be days, weeks or even months; which run for a long time, this could be days, weeks or even months;
some applications may be clever enough to organize the data some applications may be clever enough to organize the data
skipping to change at page 24, line 20 skipping to change at page 20, line 33
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 which 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.
11. References 11. References
11.1 Normative References 11.1 Normative References
[I-D.ietf-dnsop-ipv6-dns-configuration] [I-D.ietf-dnsop-ipv6-dns-configuration]
Jeong, J., "IPv6 Host Configuration of DNS Server Jeong, J., "IPv6 Host Configuration of DNS Server
Information Approaches", Information Approaches",
draft-ietf-dnsop-ipv6-dns-configuration-04 (work in draft-ietf-dnsop-ipv6-dns-configuration-06 (work in
progress), September 2004. progress), May 2005.
[I-D.ietf-dnsop-misbehavior-against-aaaa]
Morishita, Y. and T. Jinmei, "Common Misbehavior against
DNS Queries for IPv6 Addresses",
draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in
progress), April 2004.
[I-D.ietf-v6ops-application-transition] [I-D.ietf-ipv6-unique-local-addr]
Shin, M., "Application Aspects of IPv6 Transition", Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
draft-ietf-v6ops-application-transition-03 (work in Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
progress), June 2004. progress), January 2005.
[I-D.ietf-v6ops-renumbering-procedure] [I-D.ietf-v6ops-renumbering-procedure]
Baker, F., Lear, E. and R. Droms, "Procedures for Baker, F., "Procedures for Renumbering an IPv6 Network
Renumbering an IPv6 Network without a Flag Day", without a Flag Day",
draft-ietf-v6ops-renumbering-procedure-01 (work in draft-ietf-v6ops-renumbering-procedure-05 (work in
progress), July 2004. progress), March 2005.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)",
April 1997. 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, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182, and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
July 1997. 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)", RFC [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
2671, August 1999. RFC 2671, August 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. 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.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
M. Carney, "Dynamic Host Configuration Protocol for IPv6 and M. Carney, "Dynamic Host Configuration Protocol for
(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)", RFC 3364,
August 2002. August 2002.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
Extensions to Support IP Version 6", RFC 3596, October "DNS Extensions to Support IP Version 6", RFC 3596,
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 Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (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 Operational
Guidelines", BCP 91, RFC 3901, September 2004. Guidelines", BCP 91, RFC 3901, September 2004.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
11.2 Informative References 11.2 Informative References
[I-D.durand-v6ops-natpt-dns-alg-issues] [I-D.durand-dnsop-dont-publish]
Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", Durand, A. and T. Chown, "To publish, or not to publish,
draft-durand-v6ops-natpt-dns-alg-issues-00 (work in that is the question.", draft-durand-dnsop-dont-publish-00
progress), February 2003. (work in progress), February 2005.
[I-D.huitema-v6ops-teredo] [I-D.huitema-v6ops-teredo]
Huitema, C., "Teredo: Tunneling IPv6 over UDP through Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", draft-huitema-v6ops-teredo-02 (work in progress), NATs", draft-huitema-v6ops-teredo-05 (work in progress),
June 2004. April 2005.
[I-D.huston-6to4-reverse-dns] [I-D.huston-6to4-reverse-dns]
Huston, G., "6to4 Reverse DNS Delegation", Huston, G., "6to4 Reverse DNS Delegation",
draft-huston-6to4-reverse-dns-03 (work in progress), draft-huston-6to4-reverse-dns-03 (work in progress),
October 2004. October 2004.
[I-D.ietf-dhc-ddns-resolution] [I-D.ietf-dhc-ddns-resolution]
Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among
Clients", draft-ietf-dhc-ddns-resolution-08 (work in DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in
progress), October 2004. progress), June 2005.
[I-D.ietf-dhc-fqdn-option] [I-D.ietf-dhc-fqdn-option]
Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
draft-ietf-dhc-fqdn-option-07 (work in progress), July draft-ietf-dhc-fqdn-option-10 (work in progress),
2004. February 2005.
[I-D.ietf-dnsext-dhcid-rr] [I-D.ietf-dnsext-dhcid-rr]
Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for
encoding DHCP information (DHCID RR)", encoding DHCP information (DHCID RR)",
draft-ietf-dnsext-dhcid-rr-08 (work in progress), July draft-ietf-dnsext-dhcid-rr-09 (work in progress),
2004. February 2005.
[I-D.ietf-dnsop-bad-dns-res] [I-D.ietf-dnsop-bad-dns-res]
Larson, M. and P. Barber, "Observed DNS Resolution Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in
progress), July 2004. progress), October 2004.
[I-D.ietf-dnsop-dontpublish-unreachable]
Hazel, P., "IP Addresses that should never appear in the
public DNS", draft-ietf-dnsop-dontpublish-unreachable-03
(work in progress), February 2002.
[I-D.ietf-dnsop-inaddr-required] [I-D.ietf-dnsop-inaddr-required]
Senie, D., "Requiring DNS IN-ADDR Mapping", Senie, D., "Encouraging the use of DNS IN-ADDR Mapping",
draft-ietf-dnsop-inaddr-required-05 (work in progress), draft-ietf-dnsop-inaddr-required-06 (work in progress),
April 2004. February 2005.
[I-D.ietf-ipseckey-rr]
Richardson, M., "A method for storing IPsec keying
material in DNS", draft-ietf-ipseckey-rr-11 (work in
progress), July 2004.
[I-D.ietf-ipv6-unique-local-addr]
Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in
progress), September 2004.
[I-D.ietf-send-cga]
Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-06 (work in progress), April 2004.
[I-D.ietf-v6ops-3gpp-analysis] [I-D.ietf-v6ops-3gpp-analysis]
Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
progress), May 2004. progress), October 2004.
[I-D.ietf-v6ops-mech-v2] [I-D.ietf-v6ops-mech-v2]
Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07
(work in progress), September 2004. (work in progress), March 2005.
[I-D.ietf-v6ops-natpt-to-exprmntl]
Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
in progress), July 2005.
[I-D.ietf-v6ops-onlinkassumption] [I-D.ietf-v6ops-onlinkassumption]
Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
On-Link Assumption Considered Harmful", Considered Harmful", draft-ietf-v6ops-onlinkassumption-03
draft-ietf-v6ops-onlinkassumption-02 (work in progress), (work in progress), May 2005.
May 2004.
[I-D.ietf-v6ops-v6onbydefault] [I-D.ietf-v6ops-v6onbydefault]
Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
(work in progress), July 2004. (work in progress), July 2004.
[I-D.jeong-dnsop-ipv6-dns-discovery] [I-D.jeong-dnsop-ipv6-dns-discovery]
Jeong, J., "IPv6 DNS Discovery based on Router Jeong, J., "IPv6 DNS Configuration based on Router
Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02 Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04
(work in progress), July 2004. (work in progress), February 2005.
[I-D.moore-6to4-dns]
Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
in progress), October 2002.
[I-D.ohta-preconfigured-dns] [I-D.ohta-preconfigured-dns]
Ohta, M., "Preconfigured DNS Server Addresses", Ohta, M., "Preconfigured DNS Server Addresses",
draft-ohta-preconfigured-dns-01 (work in progress), draft-ohta-preconfigured-dns-01 (work in progress),
February 2004. February 2004.
[I-D.savola-v6ops-6bone-mess]
Savola, P., "Moving from 6bone to IPv6 Internet",
draft-savola-v6ops-6bone-mess-01 (work in progress),
November 2002.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766, Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000. February 2000.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the [RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, May 2000. Unique DNS Root", RFC 2826, May 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005.
Authors' Addresses Authors' Addresses
Alain Durand Alain Durand
SUN Microsystems, Inc. SUN Microsystems, Inc.
17 Network circle UMPL17-202 17 Network circle UMPL17-202
Menlo Park, CA 94025 Menlo Park, CA 94025
USA USA
EMail: Alain.Durand@sun.com Email: Alain.Durand@sun.com
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
Appendix A. Site-local Addressing Considerations for DNS Appendix A. Unique Local Addressing Considerations for DNS
As site-local addressing has been deprecated, the considerations for Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have
site-local addressing are discussed briefly here. Unique local replaced the now-deprecated site-local addresses [RFC3879]. From the
addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed perspective of the DNS, the locally generated unique local addresses
as a replacement, but being work-in-progress, it is not considered (LUL) and site-local addresses have similar properties.
further.
The interactions with DNS come in two flavors: forward and reverse The interactions with DNS come in two flavors: forward and reverse
DNS. DNS.
To actually use site-local addresses within a site, this implies the To actually use local addresses within a site, this implies the
deployment of a "split-faced" or a fragmented DNS name space, for the deployment of a "split-faced" or a fragmented DNS name space, for the
zones internal to the site, and the outsiders' view to it. The zones internal to the site, and the outsiders' view to it. The
procedures to achieve this are not elaborated here. The implication procedures to achieve this are not elaborated here. The implication
is that site-local addresses must not be published in the public DNS. is that local addresses must not be published in the public DNS.
To faciliate reverse DNS (if desired) with site-local addresses, the To faciliate reverse DNS (if desired) with local addresses, the stub
stub resolvers must look for DNS information from the local DNS resolvers must look for DNS information from the local DNS servers,
servers, not e.g. starting from the root servers, so that the not e.g. starting from the root servers, so that the local
site-local information may be provided locally. Note that the information may be provided locally. Note that the experience of
experience of private addresses in IPv4 has shown that the root private addresses in IPv4 has shown that the root servers get loaded
servers get loaded for requests for private address lookups in any for requests for private address lookups in any case. This
case. requirement is discussed in [I-D.ietf-ipv6-unique-local-addr].
Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments
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
the Additional Section.
B.1 Description of Additional Data Scenarios
There are two kinds of additional data:
1. "critical" additional data; this must be included in all
scenarios, with all the RRsets, and
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
well, but at the cost of additional queries.
The responding server can algorithmically determine which type the
additional data is by checking whether it's at or below a zone cut.
Only those additional data records (even if sometimes carelessly
termed "glue") are considered "critical" or real "glue" if and only
if they meet the abovementioned condition, as specified in Section
4.2.1 of [RFC1034].
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
all 9, all 4 A records, all 5 AAAA records or nothing. In
particular, notice that for the "critical" additional data getting
all the RRsets can be critical.
In particular, [RFC2181] specifies (in Section 9) that:
a. if all the "critical" RRsets do not fit, the sender should set
the TC bit, and the recipient should discard the whole response
and retry using mechanism allowing larger responses such as TCP.
b. "courtesy" additional data should not cause the setting of TC
bit, but instead all the non-fitting additional data RRsets
should be removed.
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
the "critical" additional data is shown below (where getting both the
A and AAAA RRsets is critical w.r.t. to the NS RR):
child.example.com. IN NS ns.child.example.com.
ns.child.example.com. IN A 192.0.2.1
ns.child.example.com. IN AAAA 2001:db8::1
When there is too much "courtesy" additional data, at least the non-
fitting RRsets should be removed [RFC2181]; however, as the
additional data is not critical, even all of it could be safely
removed.
When there is too much "critical" additional data, TC bit will have
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
issue is which data could be retained.
Failing to discard the response with TC bit or omitting critical
information but not setting TC bit lead to an unrecoverable problem.
Omitting only some of the RRsets if all would not fit (but not
setting TC bit) leads to a performance problem. These are discussed
in the next two subsections.
B.2 Which Additional Data to Keep, If Any?
If the implementation decides to keep as much data (whether
"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
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.
However, this breaks the model of independence of DNS transport and
resource records, as noted in Section 1.2.
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
complete RRsets as the implementations prefers. However, the
implementations are also free to omit all such RRsets, even if
complete. Omitting all the RRsets (when removing only some would
suffice) may create a performance penalty, whereby the client may
need to issue one or more additional queries to obtain necessary
and/or consistent information.
With critical additional data, the alternatives are either returning
nothing (and absolutely requiring a retry with TCP) or returning
something (working also in the case if the recipient does not discard
the response and retry using TCP) in addition to setting the TC bit.
If the process for selecting "something" from the critical data would
otherwise be practically "flipping the coin" between A and AAAA
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
just 50/50. In other words, if the returned critical additional data
would have to be selected somehow, using something more sophisticated
than a random process would seem justifiable.
That is, leaving in some intelligently selected critical additional
data is a tradeoff between creating an optimization for those
resolvers which ignore the "should discard" recommendation, and
causing a protocol problem by propagating inconsistent information
about "critical" records in the caches.
Similarly, leaving in the complete courtesy additional data RRsets
instead of removing all the RRsets is a performance tradeoff as
described in the next section.
B.3 Discussion of the Potential Problems
As noted above, the temptation for omitting only some of the
additional data could be problematic. This is discussed more below.
For courtesy additional data, this causes a potential performance
problem as this requires that the clients issue re-queries for the
potentially omitted RRsets. For critical additional data, this
causes a potential unrecoverable problem if the response is not
discarded and the query not re-tried with TCP, as the nameservers
might be reachable only through the omitted RRsets.
If an implementation would look at the transport used for the query,
it is worth remembering that often the host using the records is
different from the node requesting them from the authoritative DNS
server (or even a caching resolver). So, whichever version the
requestor (e.g., a recursive server in the middle) uses makes no
difference to the ultimate user of the records, whose transport
capabilities might differ from those of the requestor. This might
result in e.g., inappropriately returning A records to an IPv6-only
node, going through a translation, or opening up another IP-level
session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
Therefore, at least in many scenarios, it would be very useful if the
information returned would be consistent and complete -- or if that
is not feasible, return no misleading information but rather leave it
to the client to query again.
The problem of too much additional data seems to be an operational
one: the zone administrator entering too many records which will be
returned either truncated (or missing some RRsets, depending on
implementations) to the users. A protocol fix for this is using
EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
pushing up the relevant threshold. Further, DNS server
implementations should rather omit courtesy additional data
completely rather than including only some RRsets [RFC2181]. An
operational fix for this is having the DNS server implementations
return a warning when the administrators create zones which would
result in too much additional data being returned. Further, DNS
server implementations should warn of or disallow such zone
configurations which are recursive or otherwise difficult to manage
by 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.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 30, line 41 skipping to change at page 30, line 41
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
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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