draft-ietf-dnsop-ipv6-dns-issues-05.txt   draft-ietf-dnsop-ipv6-dns-issues-06.txt 
DNS Operations WG A. Durand DNS Operations WG A. Durand
Internet-Draft SUN Microsystems, Inc. Internet-Draft SUN Microsystems, Inc.
Expires: September 30, 2004 J. Ihren Expires: September 30, 2004 J. Ihren
Autonomica Autonomica
P. Savola P. Savola
CSC/FUNET CSC/FUNET
Apr 2004 Apr 2004
Operational Considerations and Issues with IPv6 DNS Operational Considerations and Issues with IPv6 DNS
draft-ietf-dnsop-ipv6-dns-issues-05.txt draft-ietf-dnsop-ipv6-dns-issues-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 5 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 5
2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 5 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 5
3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 5 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 5
3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 6 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 6
3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 6 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 6
4. Recommendations for Service Provisioning using DNS . . . . . . 6 4. Recommendations for Service Provisioning using DNS . . . . . . 6
4.1 Use of Service Names instead of Node Names . . . . . . . . 6 4.1 Use of Service Names instead of Node Names . . . . . . . . 6
4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 7 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 7
4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 8 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 8
4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 8 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 8
4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 9 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 10 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11
5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 10 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11
5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 10 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 12 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13
5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 14
6. Considerations about Forward DNS Updating . . . . . . . . . . 13 6. Considerations about Forward DNS Updating . . . . . . . . . . 14
6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 13 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 13 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14
7. Considerations about Reverse DNS Updating . . . . . . . . . . 14 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15
7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 14 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 15 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 15 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16
7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 16 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 17
7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 17 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18
8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 18 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 18 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19
8.2 Renumbering Procedures and Applications' Use of DNS . . . 18 8.2 Renumbering Procedures and Applications' Use of DNS . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 20
11.2 Informative References . . . . . . . . . . . . . . . . . . . 19 11.2 Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
A. Site-local Addressing Considerations for DNS . . . . . . . . . 23 A. Site-local Addressing Considerations for DNS . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 25
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
skipping to change at page 8, line 42 skipping to change at page 8, line 42
if the service offered using both protocols is of roughly equal if the service offered using both protocols is of roughly equal
quality, using the appropriate metrics for the service (e.g., quality, using the appropriate metrics for the service (e.g.,
latency, throughput, low packet loss, general reliability, etc.) -- latency, throughput, low packet loss, general reliability, etc.) --
this is typically very important especially for interactive or this is typically very important especially for interactive or
real-time services. In many cases, the quality of IPv6 connectivity real-time services. In many cases, the quality of IPv6 connectivity
is not yet equal to that of IPv4, at least globally -- this has to be is not yet equal to that of IPv4, at least globally -- this has to be
taken into consideration when enabling services [18]. taken into consideration when enabling services [18].
4.4 Behaviour of Additional Data in IPv4/IPv6 Environments 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments
Consider thes case where the query name is so long, the number of the Consider the case where the query name is so long, the number of the
additional records (originated from "glue") is so high, or for other additional records (originated from "glue") is so high, or for other
reasons that the response must either be truncated (leading to a reasons that the entire response would not fit in a single UDP
retry with TCP) or some of the additional data removed from the packet. In some cases, the responder truncates the response with the
reply. However, note that if too much additional information that is TC bit being set (leading to a retry with TCP), in order for the
not strictly necessary would be added, one should remove unnecessary querier to get the entire response later.
However, note that if too much additional information that is not
strictly necessary would be added, one should remove unnecessary
information instead of setting TC bit for this "courtesy" information information instead of setting TC bit for this "courtesy" information
[19]. Further, resource record sets are never "broken up", so if a [19].
name has 4 A records and 5 AAAA records, you can either return all 9,
all 4 A records, all 5 AAAA records or nothing.
In the case of too much additional data, it might be tempting to not Also notice that there are two kinds of additional data:
return the AAAA records if the transport for DNS query was IPv4, or
not return the A records, if the transport was IPv6. However, this 1. "critical" additional data; this must be included (all the
breaks the model of independence of DNS transport and resource possible RRsets) in all scenarios, and
records, as noted in Section 1.2.
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 which could lead to non-optimal results.
Meanwhile, 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. Notice that for
the "critical" additional data getting all the RRsets can be
critical.
An example of the "courtesy" additional data is A/AAAA records in
conjunction of MX records as shown in the next section; 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
In the case of too much additional data (whether courtesy or
critical), it might be tempting to not return the AAAA records if the
transport for DNS query was IPv4, or not return the A records, if the
transport was IPv6. However, this breaks the model of independence
of DNS transport and resource records, as noted in Section 1.2.
This temptation would have significant problems in multiple areas. This temptation would have significant problems in multiple areas.
Remember that often the end-node, which will be using the records, is Remember that often the end-node, which will be using the records, is
not the same one as the node requesting them from the authoritative not the same one as the node requesting them from the authoritative
DNS server (or even a caching resolver). So, whichever version the DNS server (or even a caching resolver). So, whichever version the
requestor ("the middleman") uses makes no difference to the ultimate requestor ("the middleman") uses makes no difference to the ultimate
user of the records. This might result in e.g., inappropriately user of the records. This might result in e.g., inappropriately
returning A records to an IPv6-only node, going through a returning A records to an IPv6-only node, going through a
translation, or opening up another IP-level session (e.g., a PDP translation, or opening up another IP-level session (e.g., a PDP
context [20]). context [20]).
The problem of too much additional data seems to be an operational The problem of too much additional data seems to be an operational
one: the zone administrator entering too many records which will be one: the zone administrator entering too many records which will be
returned either truncated or impartial to the users. A protocol fix returned either truncated or missing some RRsets to the users. A
for this is using EDNS0 [40] to signal the capacity for larger UDP protocol fix for this is using EDNS0 [40] to signal the capacity for
packet sizes, pushing up the relevant threshold. The operational fix larger UDP packet sizes, pushing up the relevant threshold. Further,
for this is having the DNS server implementations return a warning DNS server implementations should rather omit courtesy additional
when the administrators create the zones which would result in too data completely rather than including only some RRsets. An
much additional data being returned. operational fix for this is having the DNS server implementations
return a warning when the administrators create the zones which would
result in too much additional data being returned.
Additionally, to avoid the case where an application would not get an
address at all due to non-critical additional data being omitted, the
applications 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 4.5 The Use of TTL for IPv4 and IPv6 RRs
In the previous section, we discussed a danger with queries, In the previous section, we discussed a danger with queries,
potentially leading to omitting records information from the potentially leading to omitting RRsets from the additional section;
additional section. This section describes another problem leading this could happen to both critical and "courtesy" additional data.
to omitting records in cached data, highlighted in the IPv4/IPv6 This section discusses another problem with the latter, leading to
omitting RRsets in cached data, highlighted in the IPv4/IPv6
environment. 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 records of the same name requires explicit discussion. For different RRsets of the same name requires explicit discussion. For
example, let's consider a part of a zone: example, let's consider a part of a zone:
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 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. So, there are of the A and AAAA records in the additional section. So, there are
three cases about returning records for the MX in the additional three cases about returning records for the MX in the additional
section: section:
1. We get back no A or AAAA records: this is the simplest case, 1. We get back no A or AAAA RRsets: this is the simplest case,
because then we have to query which information is required because then we have to query which information is required
explicitly, guaranteeing that we get all the information we're explicitly, guaranteeing that we get all the information we're
interested in. interested in.
2. We get back all the records: this is an optimization as there is 2. We get back all the RRsets: this is an optimization as there is
no need to perform more queries, causing lower latency. However, no need to perform more queries, causing lower latency. However,
it is impossible to guarantee that in fact we would always get it is impossible to guarantee that in fact we would always get
back all the records (the only way to ensure that is to send a back all the records (the only way to ensure that is to send a
AAAA query for the name after getting the cached reply); however, AAAA query for the name after getting the cached reply); however,
one could try to work in the direction to try to ensure it as far one could try to work in the direction to try to ensure it as far
as possible. as possible.
3. We only get back A or AAAA records even if both existed: this is 3. We only get back A or AAAA RRsets even if both existed: this is
indistinguishable from the previous case, and problematic as indistinguishable from the previous case, and problematic as
described in the next section. described in the previous section.
So, we assume we get back both A and AAAA records of foo.example.com, As the third case was considered in the previous section, we assume
or the resolver explicitly asks, in two separate queries, both A and we get back both A and AAAA records of foo.example.com, or the stub
AAAA records. After 100 seconds, the AAAA record is removed from the resolver explicitly asks, in two separate queries, both A and AAAA
cache because its TTL expired. It would be useful for the cache to records.
re-query the AAAA record or discard the A record when the shorter TTL
(in this case, for the AAAA record) expires; this would avoid the
situation where there would be a window of 200 seconds when
incomplete information is returned from the cache. However, this is
not mandated or mentioned by the specification(s).
To simplify the situation, it is recommended to use the same TTL for After 100 seconds, the AAAA record is removed from the cache(s)
all the records referring to the same name. However, there are some because its TTL expired. It would be useful for the caching
resolvers to discard the A record when the shorter TTL (in this case,
for the AAAA record) expires; this would avoid the situation where
there would be a window of 200 seconds when incomplete information is
returned from the cache. However, this is not mandated or mentioned
by the specification(s).
To simplify the situation, it might help to use the same TTL for all
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 scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
a different strategy is preferable. a different strategy is preferable.
Thus, applications that use the response should not rely on a
particular TTL configuration. For example, even if an application
gets a response that only has the A record in the example described
above, it should not assume there is no AAAA record for
"foo.example.com". Instead, the application should try to fetch the
missing records by itself if it needs the record.
4.6 IPv6 Transport Guidelines for DNS Servers 4.6 IPv6 Transport Guidelines for DNS Servers
As described in Section 1.3 and [3], there should continue to be at As described in Section 1.3 and [3], there should continue to be at
least one authoritative IPv4 DNS server for every zone, even if the least one authoritative IPv4 DNS server for every zone, even if the
zone has only IPv6 records. (Note that obviously, having more servers zone has only IPv6 records. (Note that obviously, having more servers
with robust connectivity would be preferable, but this is the minimum with robust connectivity would be preferable, but this is the minimum
recommendation; also see [21].) recommendation; also see [21].)
5. Recommendations for DNS Resolver IPv6 Support 5. Recommendations for DNS Resolver IPv6 Support
skipping to change at page 13, line 4 skipping to change at page 13, line 47
development work has been reached as of this writing (April 2004). development work has been reached as of this writing (April 2004).
In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
under consideration for development of dnsop WG include the use of under consideration for development of dnsop WG include the use of
well-known addresses [26], the use of Router Advertisements to convey well-known addresses [26], the use of Router Advertisements to convey
the information [27]. the information [27].
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. IPv6. Obviously, nodes which are meant to function without manual
configuration in IPv6-only networks must implement DNS resolver
discovery function.
5.3 IPv6 Transport Guidelines for Resolvers 5.3 IPv6 Transport Guidelines for Resolvers
As described in Section 1.3 and [3], the recursive resolvers should As described in Section 1.3 and [3], the recursive resolvers should
be IPv4-only or dual-stack to be able to reach any IPv4-only DNS be IPv4-only or dual-stack to be able to reach any IPv4-only DNS
server. Note that this requirement is also fulfilled by an IPv6-only server. Note that this requirement is also fulfilled by an IPv6-only
stub resolver pointing to a dual-stack recursive DNS resolver. stub resolver pointing to a dual-stack recursive DNS resolver.
6. Considerations about Forward DNS Updating 6. Considerations about Forward DNS Updating
skipping to change at page 22, line 12 skipping to change at page 23, line 12
[35] Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for encoding [35] Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for encoding
DHCP information (DHCID RR)", draft-ietf-dnsext-dhcid-rr-07 DHCP information (DHCID RR)", draft-ietf-dnsext-dhcid-rr-07
(work in progress), October 2003. (work in progress), October 2003.
[36] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - [36] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000. Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[37] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering [37] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering
an IPv6 Network without a Flag Day", an IPv6 Network without a Flag Day",
draft-baker-ipv6-renumber-procedure-01 (work in progress), draft-ietf-v6ops-renumbering-procedure-00 (work in progress),
October 2003. February 2004.
[38] Senie, D., "Requiring DNS IN-ADDR Mapping", [38] Senie, D., "Requiring DNS IN-ADDR Mapping",
draft-ietf-dnsop-inaddr-required-03 (work in progress), March draft-ietf-dnsop-inaddr-required-05 (work in progress), April
2002. 2004.
[39] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", [39] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress), draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress),
February 2003. February 2003.
[40] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [40] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[41] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for [41] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in
 End of changes. 

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