From 7eb674ef56d8e01e98bb9471d10f7ff67bcce072 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 29 Jan 2004 01:05:40 +0000 Subject: [PATCH] new draft --- ...> draft-ietf-dnsop-ipv6-dns-issues-04.txt} | 739 +++++++++++------- 1 file changed, 454 insertions(+), 285 deletions(-) rename doc/draft/{draft-ietf-dnsop-ipv6-dns-issues-03.txt => draft-ietf-dnsop-ipv6-dns-issues-04.txt} (66%) diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-03.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt similarity index 66% rename from doc/draft/draft-ietf-dnsop-ipv6-dns-issues-03.txt rename to doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt index 54c3a8cff9..280c2f2d9a 100644 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-03.txt +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt @@ -1,15 +1,16 @@ + DNS Operations WG A. Durand Internet-Draft SUN Microsystems, Inc. -Expires: May 1, 2004 J. Ihren +Expires: July 1, 2004 J. Ihren Autonomica P. Savola CSC/FUNET - Nov 2003 + Jan 2004 Operational Considerations and Issues with IPv6 DNS - draft-ietf-dnsop-ipv6-dns-issues-03.txt + draft-ietf-dnsop-ipv6-dns-issues-04.txt Status of this Memo @@ -31,11 +32,11 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 1, 2004. + This Internet-Draft will expire on July 1, 2004. Copyright Notice - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract @@ -51,21 +52,21 @@ Abstract -Durand, et al. Expires May 1, 2004 [Page 1] +Durand, et al. Expires July 1, 2004 [Page 1] -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . . . 3 - 1.2 Difference of DNS Transport and DNS Records . . . . . . . . . 3 + 1.2 Independence of DNS Transport and DNS Records . . . . . . . . 3 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . . . 4 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 4 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . . . 4 2.2 Privacy (RFC3041) Address . . . . . . . . . . . . . . . . . . 4 - 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 5 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . . . 5 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . . . 6 @@ -73,30 +74,32 @@ Table of Contents 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.3 Adding the Records Only when Fully IPv6-enabled . . . . . . . 7 - 4.4 IPv6 Transport Guidelines for DNS Servers . . . . . . . . . . 8 - 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 8 - 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . . . 8 - 5.2 Recursive DNS Server Discovery . . . . . . . . . . . . . . . . 10 - 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . . . 10 - 6. Considerations about Forward DNS Updating . . . . . . . . . . 10 - 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 10 - 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 7. Considerations about Reverse DNS Updating . . . . . . . . . . 11 - 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . . . 11 - 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 12 - 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . . . 12 - 7.4 DDNS With DHCP . . . . . . . . . . . . . . . . . . . . . . . . 12 - 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . . . 13 - 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 13 - 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . . . 13 - 8.2 Renumbering Procedures and Applications' Use of DNS . . . . . 13 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - Normative References . . . . . . . . . . . . . . . . . . . . . 14 - Informative References . . . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 - A. Site-local Addressing Considerations for DNS . . . . . . . . . 17 - Intellectual Property and Copyright Statements . . . . . . . . 18 + 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . . . 8 + 4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments . . . . . . 8 + 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . . . 9 + 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 9 + 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . . . 9 + 5.2 Recursive DNS Resolver Discovery . . . . . . . . . . . . . . . 11 + 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . . . 11 + 6. Considerations about Forward DNS Updating . . . . . . . . . . 11 + 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 12 + 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. Considerations about Reverse DNS Updating . . . . . . . . . . 13 + 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . . . 13 + 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 14 + 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . . . 14 + 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . . . 15 + 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 15 + 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . . . 15 + 8.2 Renumbering Procedures and Applications' Use of DNS . . . . . 15 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + Normative References . . . . . . . . . . . . . . . . . . . . . 16 + Informative References . . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 + A. Site-local Addressing Considerations for DNS . . . . . . . . . 19 + Intellectual Property and Copyright Statements . . . . . . . . 21 @@ -105,11 +108,9 @@ Table of Contents - - -Durand, et al. Expires May 1, 2004 [Page 2] +Durand, et al. Expires July 1, 2004 [Page 2] -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 1. Introduction @@ -117,7 +118,7 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 This memo presents operational considerations and issues with IPv6 DNS; it is meant to be an extensive summary and a list of pointers for more information about IPv6 DNS considerations for those with - experience of IPv4 DNS. + experience with IPv4 DNS. The first section gives a brief overview of how IPv6 addresses and names are represented in the DNS, how transport protocols and @@ -127,16 +128,16 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 The second section summarizes the special IPv6 address types and how they relate to DNS. The third section describes observed DNS - implementation misbehaviour which have a varying effect on the use of - IPv6 records with DNS. The fourth section lists recommendations and - considerations for provisioning services with DNS. The fifth section - in turn looks at recommendations and considerations about providing - IPv6 support in the resolvers. The sixth and seveth sections - describe considerations with forward and reverse DNS updates, - respectively. The eighth section introduces several miscellaneous - IPv6 issues relating to DNS for which no better place has been found - in this memo. Appendix A looks briefly at the requirements for - site-local addressing. + implementation misbehaviours which have a varying effect on the use + of IPv6 records with DNS. The fourth section lists recommendations + and considerations for provisioning services with DNS. The fifth + section in turn looks at recommendations and considerations about + providing IPv6 support in the resolvers. The sixth and seventh + sections describe considerations with forward and reverse DNS + updates, respectively. The eighth section introduces several + miscellaneous IPv6 issues relating to DNS for which no better place + has been found in this memo. Appendix A looks briefly at the + requirements for site-local addressing. 1.1 Representing IPv6 Addresses in DNS Records @@ -150,24 +151,28 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 records in the reverse tree, or Bitlabels in the reverse tree is not recommended [2]. -1.2 Difference of DNS Transport and DNS Records +1.2 Independence of DNS Transport and DNS Records + + DNS has been designed to present a single, globally unique name space + [6]. This property should be maintained, as described here and in + Section 1.3. In DNS, the IP version used to transport the queries and responses is independent of the records being queried: AAAA records can be queried over IPv4, and A records over IPv6. The DNS servers must not make any assumptions about what data to return for Answer and Authority + + + +Durand, et al. Expires July 1, 2004 [Page 3] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + sections. However, there is some debate whether the addresses in Additional section could be selected or filtered using hints obtained from which - - - -Durand, et al. Expires May 1, 2004 [Page 3] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - - transport was being used; this has some obvious problems because in many cases the transport protocol does not correlate with the requests, and because a "bad" answer is in a way worse than no answer @@ -199,57 +204,56 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 The IPv6 addressing architecture [5] includes two kinds of local-use addresses: link-local (fe80::/10) and site-local (fec0::/10). The - site-local addresses are being deprecated [6], and are only discussed + site-local addresses are being deprecated [7], and are only discussed in Appendix A. Link-local addresses should never be published in DNS, because they - have only local (to the connected link) significance [7]. + have only local (to the connected link) significance [8]. 2.2 Privacy (RFC3041) Address - Privacy addresses (RFC3041 [8]) use a random number as the interface + Privacy addresses (RFC3041 [9]) use a random number as the interface identifier. Publishing DNS records relating to such addresses would defeat the purpose of the mechanism and is not recommended. If absolutely necessary, a mapping could be made to some - non-identifiable name, as described in [8]. + non-identifiable name, as described in [9]. + + + +Durand, et al. Expires July 1, 2004 [Page 4] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + 2.3 6to4 Addresses - 6to4 [9] specifies an automatic tunneling mechanism which maps a - - - -Durand, et al. Expires May 1, 2004 [Page 4] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - - + 6to4 [10] specifies an automatic tunneling mechanism which maps a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. Providing reverse DNS delegation path for such addresses is a challenge. Note that similar difficulties don't surface with the - other automatic tunneling mechanisms (in parcicular, providing - reverse DNS information for Teredo hosts whose address includes the - UDP port of the NAT binding does not seem reasonable). + other automatic tunneling mechanisms (in particular, providing + reverse DNS information for Teredo [11] hosts whose address includes + the UDP port of the NAT binding does not seem reasonable). If the reverse DNS population would be desirable (see Section 7.1 for applicability), there are a number of ways to tackle the delegation - path problem [10], some more applicable than the others. + path problem [12], some more applicable than the others. - The main proposal [11] has been to allocate 2.0.0.2.ip6.arpa. to RIRs + The main proposal [13] has been to allocate 2.0.0.2.ip6.arpa. to RIRs and let them do subdelegations in accordance to the delegations of the respective IPv4 address space. This has a major practical drawback: those ISPs and IPv4 address space holders where 6to4 is being used do not, in general, provide any IPv6 services -- as - otherwise, most people would not use 6to4 to begin with -- and it is - improbable that the reverse delegation chain would be completed - either. In most cases, creating such delegation chains might just - lead to latencies caused by lookups for (almost always) non-existant - DNS records. + otherwise, most people would not have to use 6to4 to begin with -- + and it is improbable that the reverse delegation chain would be + completed either. In most cases, creating such delegation chains + might just lead to latencies caused by lookups for (almost always) + non-existent DNS records. 3. Observed DNS Implementation Misbehaviour Several classes of misbehaviour in DNS servers, load-balancers and - resolvers has 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 this misbehaviour are extremely severe in IPv6 environments and deserve to be mentioned. @@ -257,7 +261,7 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 3.1 Misbehaviour of DNS Servers and Load-balancers There are several classes of misbehaviour in certain DNS servers and - load-balancers which have been noticed and documented [12]: some + load-balancers which have been noticed and documented [14]: some implementations silently drop queries for unimplemented DNS records types, or provide wrong answers to such queries (instead of a proper negative reply). While typically these issues are not limited to @@ -268,18 +272,18 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 getaddrinfo() implementations, with AF_UNSPEC hint given, first try to query the AAAA records of the name, and after receiving a response, query the A records. This is done in a serial fashion -- if - the first query is never responded (instead of properly returning a - negative answer), significant timeouts will occur. - - In consequence, this is an enermous problem for IPv6 deployments, and + the first query is never responded to (instead of properly returning -Durand, et al. Expires May 1, 2004 [Page 5] +Durand, et al. Expires July 1, 2004 [Page 5] -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + a negative answer), significant timeouts will occur. + + In consequence, this is an enormous problem for IPv6 deployments, and in some cases, IPv6 support in the software has even been disabled due to these problems. @@ -288,12 +292,12 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 possible ways to mitigate the problem, e.g. by performing the lookups somewhat in parallel and reducing the timeout as long as at least one answer has been received; but such methods remain to be investigated; - slightly more on this in Section 5. + slightly more on this is included in Section 5. 3.2 Misbehaviour of DNS Resolvers Several classes of misbehaviour have also been noticed in DNS - resolvers [13]. However, these do not seem to directly impair IPv6 + resolvers [15]. However, these do not seem to directly impair IPv6 use, and are only referred to for completeness. 4. Recommendations for Service Provisioning using DNS @@ -314,7 +318,7 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 look up the mail via IMAP from "pobox.example.com", one should use e.g. "smtp.example.com" for SMTP (for both message submission and mail relaying between SMTP servers) and "imap.example.com" for IMAP. - Note that in the specific case of STMP 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 loops do not occur. DNS can provide a layer of indirection between service names and where the service actually is, and using which @@ -325,17 +329,18 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 another. A specific reason why this is relevant for IPv6 is that the different services may have a different level of IPv6 support -- that is, one node providing multiple services might want to enable just + + + +Durand, et al. Expires July 1, 2004 [Page 6] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + one service to be IPv6-visible while keeping some others as IPv4-only. Using service names enables more flexibility with different IP versions as well. - - -Durand, et al. Expires May 1, 2004 [Page 6] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - - 4.2 Separate vs the Same Service Names for IPv4 and IPv6 The service naming can be achieved in basically two ways: when a @@ -344,7 +349,7 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 separately to a sub-domain, like, "service.ipv6.example.com". Both methods have different characteristics. Using a sub-domain - allows for easier service piloting, probably not disturbing the + allows for easier service piloting, minimizing the disturbance to the "regular" users of IPv4 service; however, the service would not be used without explicitly asking for it (or, within a restricted network, modifying the DNS search path) -- so it will not actually be @@ -372,7 +377,7 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 In addition, if the AAAA record is added for the node, instead of service as recommended, all the services of the node should be - IPv6-enabled prior to adding the AAAA record. + IPv6-enabled prior to adding the resource record. 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 @@ -380,17 +385,17 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 Consider the case of two dual-stack nodes, which both have IPv6 enabled, but the server does not have (global) IPv6 connectivity. As + + + +Durand, et al. Expires July 1, 2004 [Page 7] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + the client looks up the server's name, only A records are returned (if the recommendations above are followed), and no IPv6 - communication, which would be unsuccessful, is even attempted. - - - - -Durand, et al. Expires May 1, 2004 [Page 7] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - + communication, which would have been unsuccessful, is even attempted. The issues are not always so black-and-white. Usually it's important if the service offered using both protocols is of roughly equal @@ -399,15 +404,85 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 this is typically very important especially for interactive or 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 - taken into consideration when enabling services [14]. + taken into consideration when enabling services [16]. -4.4 IPv6 Transport Guidelines for DNS Servers +4.4 The Use of TTL for IPv4 and IPv6 RRs + + The behaviour of DNS caching when different TTL values are used for + different records of the same name requires explicit discussion. For + example, let's consider a part of a zone: + + example.com. 300 IN MX foo.example.com. + foo.example.com. 300 IN A 192.0.2.1 + foo.example.com. 100 IN AAAA 2001:db8::1 + + Now, when a caching resolver asks for the MX record of example.com, + it gets both A and AAAA records of foo.example.com. Then, after 100 + seconds, the AAAA record is removed from the cache because its TTL + expired. Now, subsequent queries only result in the cache returning + the A record; after 200 seconds the A record is purged as well. So, + in this particular case, there is a window of 200 seconds when + incomplete information is returned from the cache. + + Therefore, when the same name refers to both A and AAAA records, + these records should have the same TTL. Otherwise, the caches may + return incomplete information about the queried names. More issues + with caching and A/AAAA records is presented in the next section. + +4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments + + In the previous section, we discussed the effect of impartial data + returned from the caches when the TTLs are not kept the same. Now, + we present another problem highlighted in the mixed IPv4/IPv6 + environments. + + Consider the case where the query is so long or the number of the + additional ("glue") records is so high that the response must either + be truncated (leading to a retry with TCP) or some of the additional + data removed from the reply. Further, resource record sets are never + "broken up", so if a name has 4 A records and 5 AAAA records, you can + + + +Durand, et al. Expires July 1, 2004 [Page 8] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + 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 + 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. + Remember that often the end-node, which will be using the records, is + not the same one as the node requesting them from the authorative DNS + server (or even a caching resolver). So, whichever version the + requestor ("the middleman") uses makes no difference to the ultimate + user of the records. 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 [31]). + + 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 impartial to the users. A protocol fix + for this is using EDNS0 [32] to signal the capacity for larger UDP + packet sizes, pushing up the relevant threshold. The 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. + +4.6 IPv6 Transport Guidelines for DNS Servers As described in Section 1.3 and [3], there should continue to be at least one authorative IPv4 DNS server for every zone, even if the zone has only IPv6 records. (Note that obviously, having more servers - with robust connectivity would be preferably, but this is the - recommendation.) + with robust connectivity would be preferable, but this is the minimum + recommendation; also see [17].) 5. Recommendations for DNS Resolver IPv6 Support @@ -422,6 +497,14 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 1. The system library does not know whether IPv6 has been enabled in the kernel of the operating system: it may start looking up AAAA + + + +Durand, et al. Expires July 1, 2004 [Page 9] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + records with getaddrinfo() and AF_UNSPEC hint when the system is upgraded to a system library version which supports IPv6. @@ -433,21 +516,14 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 3. The system library might implement a toggle which would apply some heuristics to the "IPv6-readiness" of the node before - starting to perform queries; for example, it could check that a - link-local IPv6 address exists, or a global IPv6 address exists. + starting to perform queries; for example, it could check whether + only link-local IPv6 address(es) exists, or if at least one + global IPv6 address exists. First, let us consider generic implications of unnecessary queries for AAAA records: when looking up all the records in the DNS, AAAA records are typically tried first, and then A records. These are done in serial, and the A query is not performed until a response is - - - -Durand, et al. Expires May 1, 2004 [Page 8] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - - received to the AAAA query. Considering the misbehaviour of DNS servers and load-balancers, as described in Section 3.1, the look-up delay for AAAA may incur additional unnecessary latency, and @@ -462,9 +538,9 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 An additional concern is the address selection, which may, in some circumstances, prefer AAAA records over A records, even when the node - does not have any IPv6 connectivity [15]. In some cases, the + does not have any IPv6 connectivity [18]. In some cases, the implementation may attempt to connect or send a datagram on a - physical link [16], incurring very long protocol timeouts, instead of + physical link [19], incurring very long protocol timeouts, instead of quickly failing back to IPv4. Now, we can consider the issues specific to each of the three @@ -477,8 +553,16 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 should be able to disable these unnecessary queries, for both latency and reliability reasons. However, as IPv6 has not been enabled, the connections to IPv6 addresses fail immediately, and if the + + + +Durand, et al. Expires July 1, 2004 [Page 10] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + application is programmed properly, the application can fall - gracefully back to IPv4 [17]. + gracefully back to IPv4 [20]. 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 @@ -496,30 +580,23 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 an indication that either the address has been configured either from a router advertisement, DHCPv6, or manually. Each would indicate at least some form of IPv6 connectivity, even though there would not be - - - -Durand, et al. Expires May 1, 2004 [Page 9] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - - guarantees of it. - XXXX: are there any actual recommendations in here?!? :-) + These issues should be analyzed at more depth, and the fixes found + consensus on, perhaps in a separate document. -5.2 Recursive DNS Server Discovery +5.2 Recursive DNS Resolver Discovery - Recursive IPv6 DNS server discovery is a subject of active debate at - the moment: the main proposed mechanisms include the use of - well-known addresses [18], the use of Router Advertisements to convey - the information [19], and using DHCPv6 (or the stateless subset of it - [20]) for DNS server configuration. No consensus has been reached + Recursive IPv6 DNS resolver discovery is a subject of active debate + at the moment: the main proposed mechanisms include the use of + well-known addresses [21], the use of Router Advertisements to convey + the information [22], and using DHCPv6 (or the stateless subset of it + [23]) for DNS resolver configuration. No consensus has been reached yet. - Note that IPv6 DNS server discovery, while an important topic, is not - required for dual-stack nodes with dual-stack networks: IPv6 DNS - records can very well be queried over IPv4. + Note that IPv6 DNS resolver discovery, while an important topic, is + not required for dual-stack nodes in dual-stack networks: IPv6 DNS + records can very well be queried over IPv4 as well. 5.3 IPv6 Transport Guidelines for Resolvers @@ -532,8 +609,16 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 While the topic how to enable updating the forward DNS, i.e., the mapping from names to the correct new addresses, is not specific to + + + +Durand, et al. Expires July 1, 2004 [Page 11] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + IPv6, it bears thinking about especially due to adding Stateless - Address Autoconfiguration [21] to the mix. + Address Autoconfiguration [24] to the mix. Typically forward DNS updates are more manageable than doing them in the reverse DNS, because the updater can, typically, be assumed to @@ -542,8 +627,9 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 point to a new address. A more complex form of DNS updates -- adding a whole new name to a - DNS zone, instead of updating an existing one -- is considered - out-of-scope (XXX: at least for now, send text/feedback!). + DNS zone, instead of updating an existing name -- is considered + out-of-scope: this is not an IPv6-specific problem, and one still + being explored. 6.1 Manual or Custom DNS Updates @@ -551,46 +637,59 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 fashion or by running non-standardized protocols. These are not considered at more length in this memo. - - - - -Durand, et al. Expires May 1, 2004 [Page 10] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - - 6.2 Dynamic DNS - Dynamic DNS updates (DDNS) [22][23] is a standardized mechanism for + Dynamic DNS updates (DDNS) [25][26] is a standardized mechanism for dynamically updating the DNS. It works equally well with stateless address autoconfiguration (SLAAC), DHCPv6 or manual address - configuration. The only (minor) twist that with SLAAC, the DNS + configuration. The only (minor) twist is that with SLAAC, the DNS server cannot tie the authentication of the user to the IP address, and stronger mechanisms must be used. Actually, relying on IP addresses for Dynamic DNS is rather insecure at best, so this is probably not a significant problem (but requires that the authorization keying will be explicitly configured). - Note that the nodes must somehow be configured with the information - about the servers where they will attempt to update their addresses, - sufficient security material for authenticating themselves to the - server, and the hostname they will be updating. Unless otherwise - configured, the first could be obtained by looking up the authorative - name servers for the hostname; the second must be configured - explicitly unless one chooses to trust the IP address -based - authentication (not a good idea); and lastly, the nodename is - typically pre-configured somehow on the node, e.g. at install time. + Note that with DHCP, it is also possible that the DHCP server updates + the DNS, not the host. The host might only indicate in the DHCP + exchange which hostname it would prefer, and the DHCP server would + make the appropriate updates. Nonetheless, while this makes setting + up a secure channel between the updater and the DNS server easier, it + does not help much with "content" security, i.e., whether the + hostname was acceptable -- if the DNS server does not include + policies, they must be included in the DHCP server (e.g., a regular + host should not be able to state that its name is "www.example.com"). + + The nodes must somehow be configured with the information about the + servers where they will attempt to update their addresses, sufficient + security material for authenticating themselves to the server, and + the hostname they will be updating. Unless otherwise configured, the + first could be obtained by looking up the authorative name servers + for the hostname; the second must be configured explicitly unless one + + + +Durand, et al. Expires July 1, 2004 [Page 12] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + chooses to trust the IP address -based authentication (not a good + idea); and lastly, the nodename is typically pre-configured somehow + on the node, e.g. at install time. Care should be observed when updating the addresses not to use longer TTLs for addresses than are preferred lifetimes for the - autoconfigured addresses, so that if the node is renumberedin a + autoconfigured addresses, so that if the node is renumbered in a managed fashion, the amount of stale DNS information is kept to the - minimum. + minimum. Actually, the DNS TTL should be much shorter (e.g., a half + or a third) than the lifetime of an address; that way, the node can + start lowering the DNS TTL if it seems like the address has not be + renewed/refreshed in a while. Some discussion on how to manage the + DNS TTL is included in [28]. 7. Considerations about Reverse DNS Updating - Forward DNS updating was rather straightforward; reverse DNS is + Forward DNS updating is rather straightforward; reverse DNS is significantly trickier especially with certain mechanisms. However, first it makes sense to look at the applicability of reverse DNS in the first place. @@ -605,21 +704,13 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 reverse record for an address would signal some form of authorization). - One additional, maybe slightly more useful applicability is ensuring - the reverse and forward DNS contents match and correspond to a - configured name or domain. As a security check, it is typically - - - -Durand, et al. Expires May 1, 2004 [Page 11] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - - - accompanied by other mechanisms, such as a user/password login; the - main purpose of the DNS check is to weed out the majority of - unauthorized users, and if someone managed to bypass the checks, he - would still need to authenticate "properly". + One additional, maybe slightly more useful usage is ensuring the + reverse and forward DNS contents match and correspond to a configured + name or domain. As a security check, it is typically accompanied by + other mechanisms, such as a user/password login; the main purpose of + the DNS check is to weed out the majority of unauthorized users, and + if someone managed to bypass the checks, he would still need to + authenticate "properly". It is not clear whether it makes sense to require or recommend that reverse DNS records be updated. In many cases, it would just make @@ -629,9 +720,18 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 exists at all) should be modified as soon as possible to avoid such lookups completely. + The applicability is discussed at more length in [29]. + + + +Durand, et al. Expires July 1, 2004 [Page 13] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + 7.2 Manual or Custom DNS Updates - Reverse DNS can be updated using manual or custom methods, naturally. + Reverse DNS can of course be updated using manual or custom methods. These are not further described here, except for one special case. One way to deploy reverse DNS would be to use wildcard records, for @@ -640,7 +740,7 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 but would at least provide some form of "topological information" or "weak authorization" if that is really considered to be useful. Note that this is not actually updating the DNS as such, as the whole - point is to avoid DNS updates completely by manual configuration of a + point is to avoid DNS updates completely by manually configuring a generic name. 7.3 DDNS with Stateless Address Autoconfiguration @@ -660,24 +760,36 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 disconnected, and cannot send a DNS update using the correct source address to remove a record. -7.4 DDNS With DHCP + To insert or update the record, the node must discover the DNS server + to send the update to somehow, similar to as discussed in Section + 6.2. One way to automate this is looking up the DNS server + authoritative for the IP address being updated, but the security + material (unless the IP address -based authorization is trusted) must + also be established by some other means. + +7.4 DDNS with DHCP With DHCP, the reverse DNS name is typically already inserted to the - DNS that reflects to the name (e.g., "dhcp-67.example.com"). - - - -Durand, et al. Expires May 1, 2004 [Page 12] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - + DNS that reflects to the name (e.g., "dhcp-67.example.com"). This is + pre-configured, and requires no updating. If a more explicit control is required, similar considerations as with SLAAC apply, except for the fact that typically one must update a reverse DNS record instead of inserting one -- due to a denser address assignment policy -- and updating a record seems like a + + + +Durand, et al. Expires July 1, 2004 [Page 14] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + slightly more difficult thing to secure. + Note that when using DHCP, either the host or the DHCP server could + perform the DNS updates; see the implications in Section 6.2. + 7.5 DDNS with Dynamic Prefix Delegation In cases where more than one address is being used and updated, one @@ -697,43 +809,53 @@ Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 8.1 NAT-PT with DNS-ALG - NAT-PT [24] DNS-ALG is a critical component (unless something + NAT-PT [27] DNS-ALG is a critical component (unless something replacing that functionality is specified) which mangles A records to look like AAAA records to the IPv6-only nodes. Numerous problems have - been identified with DNS-ALG [25]. + been identified with DNS-ALG [30]. 8.2 Renumbering Procedures and Applications' Use of DNS - One of the most difficult problems of renumbering procedures [26] is - that an application which gets a DNS name disregards information such - as TTL, and uses the result obtained from DNS as long as it happens - to be stored in the memory of the application. For applications - which run for a long time, this could be days, weeks or even months; - some applications may be clever enough to organize the data - structures and functions in such a manner that look-ups get refreshed - now and then. This is an issue with no clear solution. + One of the most difficult problems of systematic IP address + renumbering procedures [28] is that 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 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; some applications may be clever + enough to organize the data structures and functions in such a manner + that look-ups get refreshed now and then. + + While the issue appears to have a clear solution, "fix the + applications", practically this is not reasonable immediate advice; + the TTL information is not typically available in the APIs and + libraries (so, the advice becomes "fix the applications, APIs and + libraries"), and a lot more analysis is needed on how to practically + go about to achieve the ultimate goal of avoiding using the names + longer than expected. + + + + +Durand, et al. Expires July 1, 2004 [Page 15] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + 9. Acknowledgements Some recommendations (Section 4.3, Section 5.1) about IPv6 service - provisioning were moved here from [27] by Erik Nordmark and Bob - Gilligan. Havard Eidnes provided useful feedback and improvements. - - - - - -Durand, et al. Expires May 1, 2004 [Page 13] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - + provisioning were moved here from [33] by Erik Nordmark and Bob + Gilligan. Havard Eidnes and Michael Patton provided useful feedback + and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark + Andrews helped in clarifying the issues regarding additional data and + the use of TTL. 10. Security Considerations This document reviews the operational procedures for IPv6 DNS operations and does not have security considerations in itself. - However, it is worth nothing 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 very weak and cannot be recommended. On the other hand, it should be noted that setting up an authorization mechanism (e.g., a shared @@ -767,101 +889,130 @@ Informative References [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. - [6] Huitema, C. and B. Carpenter, "Deprecating Site Local + + + +Durand, et al. Expires July 1, 2004 [Page 16] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + [6] Internet Architecture Board, "IAB Technical Comment on the + Unique DNS Root", RFC 2826, May 2000. + + [7] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", draft-ietf-ipv6-deprecate-site-local-02 (work in progress), November 2003. - [7] Hazel, P., "IP Addresses that should never appear in the public + [8] Hazel, P., "IP Addresses that should never appear in the public DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in progress), February 2002. - [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless - - - -Durand, et al. Expires May 1, 2004 [Page 14] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - - + [9] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. - [9] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via + [10] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. - [10] Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work in + [11] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", + draft-huitema-v6ops-teredo-00 (work in progress), June 2003. + + [12] Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work in progress), October 2002. - [11] Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa", + [13] Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa", draft-ymbk-6to4-arpa-delegation-00 (work in progress), February 2003. - [12] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS + [14] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS Queries for IPv6 Addresses", draft-morishita-dnsop-misbehavior-against-aaaa-00 (work in progress), June 2003. - [13] Larson, M. and P. Barber, "Observed DNS Resolution + [15] Larson, M. and P. Barber, "Observed DNS Resolution Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in progress), June 2003. - [14] Savola, P., "Moving from 6bone to IPv6 Internet", + [16] Savola, P., "Moving from 6bone to IPv6 Internet", draft-savola-v6ops-6bone-mess-01 (work in progress), November 2002. - [15] Roy, S., "Dual Stack IPv6 on by Default", + [17] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and + Operation of Secondary DNS Servers", BCP 16, RFC 2182, July + 1997. + + [18] Roy, S., "Dual Stack IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-00 (work in progress), October 2003. - [16] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered + + + +Durand, et al. Expires July 1, 2004 [Page 17] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + [19] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", draft-ietf-v6ops-onlinkassumption-00 (work in progress), October 2003. - [17] Shin, M., "Application Aspects of IPv6 Transition", - draft-shin-v6ops-application-transition-02 (work in progress), - October 2003. + [20] Shin, M., "Application Aspects of IPv6 Transition", + draft-ietf-v6ops-application-transition-00 (work in progress), + December 2003. - [18] Ohta, M., "Preconfigured DNS Server Addresses", + [21] Ohta, M., "Preconfigured DNS Server Addresses", draft-ohta-preconfigured-dns-00 (work in progress), July 2003. - [19] Jeong, J., "IPv6 DNS Discovery based on Router Advertisement", + [22] Jeong, J., "IPv6 DNS Discovery based on Router Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-00 (work in progress), July 2003. - [20] Droms, R., "A Guide to Implementing Stateless DHCPv6 Service", - draft-ietf-dhc-dhcpv6-stateless-01 (work in progress), October + [23] Droms, R., "Stateless DHCP Service for IPv6", + draft-ietf-dhc-dhcpv6-stateless-04 (work in progress), January + 2004. + + [24] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [25] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [26] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [27] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - + Protocol Translation (NAT-PT)", RFC 2766, February 2000. + + [28] Baker, F., "Procedures for Renumbering an IPv6 Network without + a Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in + progress), October 2003. + + [29] Senie, D., "Requiring DNS IN-ADDR Mapping", + draft-ietf-dnsop-inaddr-required-03 (work in progress), March + 2002. + + [30] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", + draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress), + February 2003. + + [31] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", + draft-ietf-v6ops-3gpp-analysis-07 (work in progress), October 2003. -Durand, et al. Expires May 1, 2004 [Page 15] +Durand, et al. Expires July 1, 2004 [Page 18] -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - [21] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. + [32] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. - [22] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [23] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [24] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - - Protocol Translation (NAT-PT)", RFC 2766, February 2000. - - [25] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", - draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress), - February 2003. - - [26] Baker, F., "Procedures for Renumbering an IPv6 Network without - a Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in - progress), October 2003. - - [27] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for + [33] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-01 (work in progress), October 2003. @@ -886,16 +1037,6 @@ Authors' Addresses EMail: johani@autonomica.se - - - - - -Durand, et al. Expires May 1, 2004 [Page 16] - -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 - - Pekka Savola CSC/FUNET @@ -908,13 +1049,22 @@ Appendix A. Site-local Addressing Considerations for DNS As site-local addressing is being deprecated, and it is not yet clear whether an addressing-based replacement (and which kind) is devised, - the considerations for site-local addressing are introduced here. + the considerations for site-local addressing are discussed briefly + here. The interactions with DNS come in two flavors: forward and reverse DNS. To actually use site-local addresses within a site, this implies the deployment of a "split-faced" or a fragmented DNS name space, for the + + + +Durand, et al. Expires July 1, 2004 [Page 19] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + zones internal to the site, and the outsiders' view to it. The procedures to achieve this are not elaborated here. The implication is that site-local addresses must not be published in the public DNS. @@ -924,7 +1074,7 @@ Appendix A. Site-local Addressing Considerations for DNS servers, not e.g. starting from the root servers, so that the site-local information may be provided locally. Note that the experience private addresses in IPv4 has shown that the root servers - get loaded for requests for private address lookups in any case. + get loaded for requests for private address lookups in any. @@ -947,9 +1097,28 @@ Appendix A. Site-local Addressing Considerations for DNS -Durand, et al. Expires May 1, 2004 [Page 17] + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires July 1, 2004 [Page 20] -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 Intellectual Property Statement @@ -977,7 +1146,7 @@ Intellectual Property Statement Full Copyright Statement - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it @@ -1003,9 +1172,9 @@ Full Copyright Statement -Durand, et al. Expires May 1, 2004 [Page 18] +Durand, et al. Expires July 1, 2004 [Page 21] -Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF @@ -1059,6 +1228,6 @@ Acknowledgment -Durand, et al. Expires May 1, 2004 [Page 19] +Durand, et al. Expires July 1, 2004 [Page 22]