diff options
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt | 1969 |
1 files changed, 0 insertions, 1969 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt deleted file mode 100644 index b14f711..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt +++ /dev/null @@ -1,1969 +0,0 @@ - - -DNS Operations WG A. Durand -Internet-Draft SUN Microsystems, Inc. -Expires: February 7, 2005 J. Ihren - Autonomica - P. Savola - CSC/FUNET - August 9, 2004 - - - - Operational Considerations and Issues with IPv6 DNS - draft-ietf-dnsop-ipv6-dns-issues-09.txt - - -Status of this Memo - - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - This Internet-Draft will expire on February 7, 2005. - - -Copyright Notice - - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - -Abstract - - - This memo presents operational considerations and issues with IPv6 - Domain Name System (DNS), including a summary of special IPv6 - addresses, documentation of known DNS implementation misbehaviour, - recommendations and considerations on how to perform DNS naming for - - - - -Durand, et al. Expires February 7, 2005 [Page 1] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - service provisioning and for DNS resolver IPv6 support, - considerations for DNS updates for both the forward and reverse - trees, and miscellaneous issues. This memo is aimed to include a - summary of information about IPv6 DNS considerations for those who - have experience with IPv4 DNS. - - -Table of Contents - - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 - 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 - 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 - 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 - 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 - 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 - 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 - 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 - 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 - 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 - 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 - 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 - 4. Recommendations for Service Provisioning using DNS . . . . . . 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.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 - 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10 - 4.4.1 Description of Additional Data Scenarios . . . . . . . 10 - 4.4.2 Discussion of the Problems . . . . . . . . . . . . . . 11 - 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12 - 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 13 - 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 13 - 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14 - 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 15 - 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 16 - 6. Considerations about Forward DNS Updating . . . . . . . . . . 16 - 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 - 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 17 - 7. Considerations about Reverse DNS Updating . . . . . . . . . . 18 - 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 18 - 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19 - 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 19 - 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20 - 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 21 - 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22 - 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 22 - 8.2 Renumbering Procedures and Applications' Use of DNS . . . 22 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 - - - - -Durand, et al. Expires February 7, 2005 [Page 2] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 - 11.2 Informative References . . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 - A. Site-local Addressing Considerations for DNS . . . . . . . . . 28 - B. Issues about Additional Data or TTL . . . . . . . . . . . . . 28 - Intellectual Property and Copyright Statements . . . . . . . . 30 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 3] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -1. Introduction - - - 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 with IPv4 DNS. - - - The purpose of this document is to give information about various - issues and considerations related to DNS operations with IPv6; it is - not meant to be a normative specification or standard for IPv6 DNS. - - - The first section gives a brief overview of how IPv6 addresses and - names are represented in the DNS, how transport protocols and - resource records (don't) relate, and what IPv4/IPv6 name space - fragmentation means and how to avoid it; all of these are described - at more length in other documents. - - - The second section summarizes the special IPv6 address types and how - they relate to DNS. The third section describes observed DNS - 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 - - - In the forward zones, IPv6 addresses are represented using AAAA - records. In the reverse zones, IPv6 address are represented using - PTR records in the nibble format under the ip6.arpa. tree. See - [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] - for background information. - - - In particular one should note that the use of A6 records in the - forward tree or Bitlabels in the reverse tree is not recommended - [RFC3363]. Using DNAME records is not recommended in the reverse - tree in conjunction with A6 records; the document did not mean to - take a stance on any other use of DNAME records [RFC3364]. - - -1.2 Independence of DNS Transport and DNS Records - - - DNS has been designed to present a single, globally unique name space - [RFC2826]. This property should be maintained, as described here and - - - - -Durand, et al. Expires February 7, 2005 [Page 4] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - in Section 1.3. - - - The IP version used to transport the DNS 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 - sections based on the underlying transport used in a query. - - - However, there is some debate whether the addresses in Additional - section could be selected or filtered using hints obtained from which - 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 - at all (consider the case where the client is led to believe that a - name received in the additional record does not have any AAAA records - at all). - - - As stated in [RFC3596]: - - - The IP protocol version used for querying resource records is - independent of the protocol version of the resource records; e.g., - IPv4 transport can be used to query IPv6 records and vice versa. - - - -1.3 Avoiding IPv4/IPv6 Name Space Fragmentation - - - To avoid the DNS name space from fragmenting into parts where some - parts of DNS are only visible using IPv4 (or IPv6) transport, the - recommendation is to always keep at least one authoritative server - IPv4-enabled, and to ensure that recursive DNS servers support IPv4. - See DNS IPv6 transport guidelines - [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information. - - -1.4 Query Type '*' and A/AAAA Records - - - QTYPE=* is typically only used for debugging or management purposes; - it is worth keeping in mind that QTYPE=* ("ANY" queries) only return - any available RRsets, not *all* the RRsets, because the caches do not - necessarily have all the RRsets and have no way of guaranteeing that - they have all the RRsets. Therefore, to get both A and AAAA records - reliably, two separate queries must be made. - - -2. DNS Considerations about Special IPv6 Addresses - - - There are a couple of IPv6 address types which are somewhat special; - these are considered here. - - - - - - -Durand, et al. Expires February 7, 2005 [Page 5] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -2.1 Limited-scope Addresses - - - The IPv6 addressing architecture [RFC3513] includes two kinds of - local-use addresses: link-local (fe80::/10) and site-local (fec0::/ - 10). The site-local addresses have been deprecated - [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in - Appendix A. - - - Link-local addresses should never be published in DNS (whether in - forward or reverse tree), because they have only local (to the - connected link) significance - [I-D.ietf-dnsop-dontpublish-unreachable]. - - -2.2 Temporary Addresses - - - Temporary addresses defined in RFC3041 [RFC3041] (sometimes called - "privacy addresses") use a random number as the interface identifier. - Publishing (useful) DNS records relating to such addresses would - defeat the purpose 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 hexadecimal format), as described in [RFC3041]. - - -2.3 6to4 Addresses - - - 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps - 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 - 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 - autonomous reverse-delegation system that anyone being capable of - communicating using a specific 6to4 address would be able to set up a - reverse delegation to the corresponding 6to4 prefix. This could be - deployed by e.g., Regional Internet Registries (RIRs). This is a - practical solution, but may have some scalability concerns. - - -2.4 Other Transition Mechanisms - - - 6to4, above, is mentioned as a case of an IPv6 transition mechanism - requiring special considerations. In general, mechanisms which - include a special prefix may need a custom solution; otherwise, for - example when IPv4 address is embedded as the suffix or not embedded - at all, special solutions are likely not needed. This is why only - 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described. - - - Note that it does not seem feasible to provide reverse DNS with - - - - -Durand, et al. Expires February 7, 2005 [Page 6] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - another automatic tunneling mechanism, Teredo; this is because the - IPv6 address is based on the IPv4 address and UDP port of the current - NAT mapping which is likely to be relatively short-lived. - - -3. Observed DNS Implementation Misbehaviour - - - Several classes of misbehaviour in DNS servers, load-balancers and - 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. - - -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 - [I-D.ietf-dnsop-misbehavior-against-aaaa]: 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 AAAA records, the - problems are aggravated by the fact that AAAA records are being - queried instead of (mainly) A records. - - - The problems are serious because when looking up a DNS name, typical - 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 to (instead of properly - returning 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. - - - The solution is to fix or retire those misbehaving implementations, - but that is likely not going to be effective. There are some - 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 is included in Section 5. - - -3.2 Misbehaviour of DNS Resolvers - - - Several classes of misbehaviour have also been noticed in DNS - resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem - to directly impair IPv6 use, and are only referred to for - completeness. - - - - - -Durand, et al. Expires February 7, 2005 [Page 7] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -4. Recommendations for Service Provisioning using DNS - - - 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 - smoothly as possible. - - -4.1 Use of Service Names instead of Node Names - - - When a node provides multiple services which should not be - fate-sharing, or might support different IP versions, one should keep - them logically separate in the DNS. Using SRV records [RFC2782] - would avoid these problems. Unfortunately, those are not - sufficiently widely used to be applicable in most cases. Hence an - operation technique is to use service names instead of node names - (or, "hostnames"). This operational technique is not specific to - IPv6, but required to understand the considerations described in - Section 4.2 and Section 4.3. - - - For example, assume a node named "pobox.example.com" provides both - SMTP and IMAP service. Instead of configuring the MX records to - point at "pobox.example.com", and configuring the mail clients to - look up the mail via IMAP from "pobox.example.com", one should use - 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 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 - addresses. (Obviously, when wanting to reach a specific node, one - should use the hostname rather than a service name.) - - - This is a good practice with IPv4 as well, because it provides more - flexibility and enables easier migration of services from one host to - 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 - one service to be IPv6-visible while keeping some others as - IPv4-only, improving flexibility. - - -4.2 Separate vs the Same Service Names for IPv4 and IPv6 - - - The service naming can be achieved in basically two ways: when a - service is named "service.example.com" for IPv4, the IPv6-enabled - service could be either added to "service.example.com", or added - separately under a different name, e.g., in a sub-domain, like, - "service.ipv6.example.com". - - - These two methods have different characteristics. Using a different - - - - -Durand, et al. Expires February 7, 2005 [Page 8] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - name allows for easier service piloting, minimizing the disturbance - to the "regular" users of IPv4 service; however, the service would - not be used transparently, without the user/application explicitly - 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 - services are deployed within a restricted network (e.g., inside an - enterprise), it's possible to prefer them transparently, at least to - a degree, by modifying the DNS search path; however, this is a - suboptimal solution. Using the same service name is the "long-term" - solution, but may degrade performance for those clients whose IPv6 - performance is lower than IPv4, or does not work as well (see Section - 4.3 for more). - - - 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 - confident enough that the service level will not degrade for the - users unaware of IPv6. - - -4.3 Adding the Records Only when Fully IPv6-enabled - - - The recommendation is that AAAA records for a service should not be - added to the DNS until all of following are true: - - - 1. The address is assigned to the interface on the node. - - - 2. The address is configured on the interface. - - - 3. The interface is on a link which is connected to the IPv6 - infrastructure. - - - 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 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 - that it should not have an address in the DNS. - - - Consider the case of two dual-stack nodes, which both have IPv6 - enabled, but the server does not have (global) IPv6 connectivity. As - 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 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 - quality, using the appropriate metrics for the service (e.g., - latency, throughput, low packet loss, general reliability, etc.) -- - - - - -Durand, et al. Expires February 7, 2005 [Page 9] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - this is typically very important especially for interactive or - real-time services. In many cases, the quality of IPv6 connectivity - may not yet be equal to that of IPv4, at least globally -- this has - to be taken into consideration when enabling services - [I-D.savola-v6ops-6bone-mess]. - - -4.4 Behaviour of Additional Data in IPv4/IPv6 Environments - - -4.4.1 Description of Additional Data Scenarios - - - Consider the case where the query name is so long, the number of the - additional records is so high, or for other reasons that the entire - response would not fit in a single UDP packet. In some cases, the - responder truncates the response with the TC bit being set (leading - to a retry with TCP), in order for the querier to get the entire - response later. - - - There are two kinds of additional data: - - - 1. glue, i.e., "critical" additional data; this must be included in - all scenarios, with all the RRsets as possible, 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. This data must - never cause setting of the TC bit. - - - The responding server can algorithmically determine which type the - additional data is by checking whether it's at or below a zone cut. - - - 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. In particular, - 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 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, some or all of it - need to be removed [RFC2181]; if some is left in the response, the - issue is which data should be retained. When there is too much - - - - -Durand, et al. Expires February 7, 2005 [Page 10] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - critical additional data, TC bit will have to be set, and some or all - of it need to be removed; if some is left in the response, the issue - is which data should be retained. - - - If the implementation decides to keep as much data as possible, 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. - - - 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. - - -4.4.2 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. - - - However, with critical additional data, the alternatives are either - returning nothing (and requiring a retry with TCP) or returning - something (possibly obviating the need for a retry with TCP). 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. - - - 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 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. - - - - -Durand, et al. Expires February 7, 2005 [Page 11] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - 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, - potentially leading to omitting RRsets from the additional section; - this could happen to both critical and "courtesy" additional data. - This section discusses another problem with the latter, 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 - different RRsets of the same name requires explicit discussion. For - example, let's consider a part of a zone: - - - example.com. 300 IN MX foo.example.com. - foo.example.com. 300 IN A 192.0.2.1 - foo.example.com. 100 IN AAAA 2001:db8::1 - - - When a caching resolver asks for the MX record of example.com, it - gets back "foo.example.com". It may also get back either one or both - of the A and AAAA records in the additional section. So, there are - three cases about returning records for the MX in the additional - section: - - - 1. We get back no A or AAAA RRsets: this is the simplest case, - because then we have to query which information is required - explicitly, guaranteeing that we get all the information we're - interested in. - - - 2. We get back all the RRsets: this is an optimization as there is - no need to perform more queries, causing lower latency. However, - it is impossible to guarantee that in fact we would always get - back all the records (the only way to ensure that is to send a - AAAA query for the name after getting the cached reply with A - - - - -Durand, et al. Expires February 7, 2005 [Page 12] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - records or vice versa). - - - 3. We only get back A or AAAA RRsets even if both existed: this is - indistinguishable from the previous case, and may have problems - at least in certain environments as described in the previous - section. - - - As the third case was considered in the previous section, we assume - we get back both A and AAAA records of foo.example.com, or the stub - resolver explicitly asks, in two separate queries, both A and AAAA - records. - - - 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 - 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. The behaviour in - this scenario is unspecified. - - - 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 - 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 be still aware that there could be a AAAA record for - "foo.example.com". That is, the application should try to fetch the - missing records itself if it needs the record. - - -4.6 IPv6 Transport Guidelines for DNS Servers - - - As described in Section 1.3 and - [I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue to - be at least one authoritative 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 preferable, but this is the - minimum recommendation; also see [RFC2182].) - - -5. Recommendations for DNS Resolver IPv6 Support - - - When IPv6 is enabled on a node, there are several things to consider - to ensure that the process is as smooth as possible. - - - - - - -Durand, et al. Expires February 7, 2005 [Page 13] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -5.1 DNS Lookups May Query IPv6 Records Prematurely - - - The system library that implements the getaddrinfo() function for - looking up names is a critical piece when considering the robustness - of enabling IPv6; it may come in basically three flavours: - - - 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 - records with getaddrinfo() and AF_UNSPEC hint when the system is - upgraded to a system library version which supports IPv6. - - - 2. The system library might start to perform IPv6 queries with - getaddrinfo() only when IPv6 has been enabled in the kernel. - However, this does not guarantee that there exists any useful - IPv6 connectivity (e.g., the node could be isolated from the - other IPv6 networks, only having link-local addresses). - - - 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 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 - 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 - introduce a component of unreliability. - - - One option here could be to do the queries partially in parallel; for - example, if the final response to the AAAA query is not received in - 0.5 seconds, start performing the A query while waiting for the - result (immediate parallelism might be unoptimal, at least without - information sharing between the look-up threads, as that would - probably lead to duplicate non-cached delegation chain lookups). - - - 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 [I-D.ietf-v6ops-v6onbydefault]. - In some cases, the implementation may attempt to connect or send a - datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], - incurring very long protocol timeouts, instead of quickly failing - back to IPv4. - - - Now, we can consider the issues specific to each of the three - - - - -Durand, et al. Expires February 7, 2005 [Page 14] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - possibilities: - - - 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 - anyway. (The only exception is where the application desires to know - what's in the DNS, but not use the result for communication.) One - 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 - application is programmed properly, the application can fall - gracefully back to IPv4 [I-D.ietf-v6ops-application-transition]. - - - 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 - not been provided yet; similar considerations apply, with the - exception that IPv6 records, when returned, will be actually tried - first which may typically lead to long timeouts. - - - 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 - different lookup services which getaddrinfo() may support), as the - link-locals are typically automatically generated when IPv6 is - enabled, and do not indicate any form of IPv6 connectivity. That is, - performing DNS lookups only when a non-link-local address has been - configured on any interface could be beneficial -- this would be an - indication that either the address has been configured either from a - router advertisement, DHCPv6 [RFC3315], or manually. Each would - indicate at least some form of IPv6 connectivity, even though there - would not be guarantees of it. - - - These issues should be analyzed at more depth, and the fixes found - consensus on, perhaps in a separate document. - - -5.2 Obtaining a List of DNS Recursive Resolvers - - - In scenarios where DHCPv6 is available, a host can discover a list of - DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" - option [RFC3646]. This option can be passed to a host through a - subset of DHCPv6 [RFC3736]. - - - The IETF is considering the development of alternative mechanisms for - obtaining the list of DNS recursive name servers when DHCPv6 is - unavailable or inappropriate. No decision about taking on this - development work has been reached as of this writing (Aug 2004) - [I-D.ietf-dnsop-ipv6-dns-configuration]. - - - In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms - under consideration for development include the use of well-known - - - - -Durand, et al. Expires February 7, 2005 [Page 15] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - addresses [I-D.ohta-preconfigured-dns] and the use of Router - Advertisements to convey the information - [I-D.jeong-dnsop-ipv6-dns-discovery]. - - - Note that even though IPv6 DNS resolver discovery is a recommended - procedure, it is not required for dual-stack nodes in dual-stack - networks as IPv6 DNS records can be queried over IPv4 as well as - IPv6. Obviously, nodes which are meant to function without manual - configuration in IPv6-only networks must implement the DNS resolver - discovery function. - - -5.3 IPv6 Transport Guidelines for Resolvers - - - As described in Section 1.3 and - [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers - should be IPv4-only or dual-stack to be able to reach any IPv4-only - DNS server. Note that this requirement is also fulfilled by an - IPv6-only stub resolver pointing to a dual-stack recursive DNS - resolver. - - -6. Considerations about Forward DNS Updating - - - 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 - IPv6, it should be considered especially due to the advent of - Stateless Address Autoconfiguration [RFC2462]. - - - Typically forward DNS updates are more manageable than doing them in - 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 - with the DNS name and the node which is allowed to update it to point - to a new address. - - - A more complex form of DNS updates -- adding a whole new name into a - DNS zone, instead of updating an existing name -- is considered out - of scope for this memo as it could require zone-wide authentication. - Adding a new name in the forward zone is a problem which is still - being explored with IPv4, and IPv6 does not seem to add much new in - that area. - - -6.1 Manual or Custom DNS Updates - - - The DNS mappings can also be maintained by hand, in a semi-automatic - fashion or by running non-standardized protocols. These are not - considered at more length in this memo. - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 16] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -6.2 Dynamic DNS - - - Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized - mechanism for dynamically updating the DNS. It works equally well - with stateless address autoconfiguration (SLAAC), DHCPv6 or manual - address configuration. It is important to consider how each of these - behave if IP address-based authentication, instead of stronger - mechanisms [RFC3007], was used in the updates. - - - 1. manual addresses are static and can be configured - - - 2. DHCPv6 addresses could be reasonably static or dynamic, depending - on the deployment, and could or could not be configured on the - DNS server for the long term - - - 3. SLAAC addresses are typically stable for a long time, but could - require work to be configured and maintained. - - - As relying on IP addresses for Dynamic DNS is rather insecure at - best, stronger authentication should always be used; however, this - requires that the authorization keying will be explicitly configured - using unspecified operational methods. - - - 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"). - DHCP-initiated DDNS updates have been extensively described in - [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and - [I-D.ietf-dnsext-dhcid-rr]. - - - 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 authoritative 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. - - - Care should be observed when updating the addresses not to use longer - TTLs for addresses than are preferred lifetimes for the addresses, so - - - - -Durand, et al. Expires February 7, 2005 [Page 17] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - 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 - preferred lifetime of an address expires, the TTL of the record needs - be modified unless it was already done before the expiration. For - 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 - start lowering the DNS TTL if it seems like the address has not been - renewed/refreshed in a while. Some discussion on how an - administrator could manage the DNS TTL is included in - [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to - (smart) hosts as well. - - -7. Considerations about Reverse DNS Updating - - - Updating the reverse DNS zone may be difficult because of the split - authority over an address. However, first we have to consider the - applicability of reverse DNS in the first place. - - -7.1 Applicability of Reverse DNS - - - Today, some applications use reverse DNS to either look up some hints - about the topological information associated with an address (e.g. - resolving web server access logs), or as a weak form of a security - check, to get a feel whether the user's network administrator has - "authorized" the use of the address (on the premises that adding a - reverse record for an address would signal some form of - authorization). - - - One additional, maybe slightly more useful usage is ensuring that the - 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 - 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, - it is typically accompanied by other mechanisms, such as a user/ - password login; the main purpose of the reverse+forward 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 may also be desirable to store IPsec keying material corresponding - to an IP address to the reverse DNS, as justified and described in - [I-D.ietf-ipseckey-rr]. - - - 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 - more sense to use proper mechanisms for security (or topological - information lookup) in the first place. At minimum, the applications - which use it as a generic authorization (in the sense that a record - - - - -Durand, et al. Expires February 7, 2005 [Page 18] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - exists at all) should be modified as soon as possible to avoid such - lookups completely. - - - The applicability is discussed at more length in - [I-D.ietf-dnsop-inaddr-required]. - - -7.2 Manual or Custom DNS Updates - - - 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 - 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 - reverses of the prefix 2001:db8:f00::/48 to point to one name using a - wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR - site.example.com." Naturally, such a name could not be verified from - the forward DNS, 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 manually - configuring a generic name. - - -7.3 DDNS with Stateless Address Autoconfiguration - - - Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in - some regard, while being more difficult in another, as described - below. - - - The address space administrator decides whether the hosts are trusted - to update their reverse DNS records or not. If they are, a simple - address-based authorization is typically sufficient (i.e., check that - the DNS update is done from the same IP address as the record being - updated); stronger security can also be used [RFC3007]. If they - aren't allowed to update the reverses, no update can occur. (Such - address-based update authorization operationally requires that - ingress filtering [RFC3704] has been set up at the border of the site - where the updates occur, and as close to the updater as possible.) - - - Address-based authorization is simpler with reverse DNS (as there is - a connection between the record and the address) than with forward - 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 - an association with the domain. Note that the user may roam to - different networks, and does not necessarily have any association - with the owner of that address space -- so, assuming stronger form of - authorization for reverse DNS updates than an address association is - generally unfeasible. - - - - -Durand, et al. Expires February 7, 2005 [Page 19] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Moreover, the reverse zones must be cleaned up by an unspecified - janitorial process: the node does not typically know a priori that it - will be disconnected, and cannot send a DNS update using the correct - source address to remove a record. - - - A problem with defining the clean-up process is that it is difficult - to ensure that a specific IP address and the corresponding record are - no longer being used. Considering the huge address space, and the - unlikelihood of collision within 64 bits of the interface - identifiers, a process which would remove the record after no traffic - has been seen from a node in a long period of time (e.g., a month or - year) might be one possible approach. - - - To insert or update the record, the node must discover the DNS server - to 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 (e.g., through SOA record) 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. - - - One should note that Cryptographically Generated Addresses - [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of - treatment. CGAs are addresses where the interface identifier is - calculated from a public key, a modifier (used as a nonce), the - subnet prefix, and other data. Depending on the usage profile, CGAs - might or might not be changed periodically due to e.g., privacy - reasons. As the CGA address is not predicatable, a reverse record - can only reasonably be inserted in the DNS by the node which - generates the address. - - -7.4 DDNS with DHCP - - - 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 - can assume similar practice may become commonplace with DHCPv6 as - well; all such mappings would be pre-configured, and would require no - updating. - - - If a more explicit control is required, similar considerations as - with SLAAC apply, except for the fact that typically one must update - a reverse DNS record instead of inserting one (if an address - assignment policy that reassigns disused addresses is adopted) and - updating a record seems like a slightly more difficult thing to - secure. However, it is yet uncertain how DHCPv6 is going to be used - for address assignment. - - - Note that when using DHCP, either the host or the DHCP server could - - - - -Durand, et al. Expires February 7, 2005 [Page 20] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - perform the DNS updates; see the implications in Section 6.2. - - - If disused addresses were to be reassigned, host-based DDNS reverse - updates would need policy considerations for DNS record modification, - as noted above. On the other hand, if disused address were not to be - assigned, host-based DNS reverse updates would have similar - considerations as SLAAC in Section 7.3. Server-based updates have - similar properties except that the janitorial process could be - integrated with DHCP address assignment. - - -7.5 DDNS with Dynamic Prefix Delegation - - - In cases where a prefix, instead of an address, is being used and - updated, one should consider what is the location of the server where - DDNS updates are made. That is, where the DNS server is located: - - - 1. At the same organization as the prefix delegator. - - - 2. At the site where the prefixes are delegated to. In this case, - the authority of the DNS reverse zone corresponding to the - delegated prefix is also delegated to the site. - - - 3. Elsewhere; this implies a relationship between the site and where - DNS server is located, and such a relationship should be rather - straightforward to secure as well. Like in the previous case, - the authority of the DNS reverse zone is also delegated. - - - In the first case, managing the reverse DNS (delegation) is simpler - as the DNS server and the prefix delegator are in the same - administrative domain (as there is no need to delegate anything at - all); alternatively, the prefix delegator might forgo DDNS reverse - capability altogether, and use e.g., wildcard records (as described - in Section 7.2). In the other cases, it can be slighly more - difficult, particularly as the site will have to configure the DNS - server to be authoritative for the delegated reverse zone, implying - automatic configuration of the DNS server -- as the prefix may be - dynamic. - - - Managing the DDNS reverse updates is typically simple in the second - case, as the updated server is located at the local site, and - arguably IP address-based authentication could be sufficient (or if - not, setting up security relationships would be simpler). As there - is an explicit (security) relationship between the parties in the - third case, setting up the security relationships to allow reverse - DDNS updates should be rather straightforward as well (but IP - address-based authentication might not be acceptable). In the first - case, however, setting up and managing such relationships might be a - lot more difficult. - - - - -Durand, et al. Expires February 7, 2005 [Page 21] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -8. Miscellaneous DNS Considerations - - - This section describes miscellaneous considerations about DNS which - seem related to IPv6, for which no better place has been found in - this document. - - -8.1 NAT-PT with DNS-ALG - - - The DNS-ALG component of NAT-PT mangles A records to look like AAAA - records to the IPv6-only nodes. Numerous problems have been - identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues]. - This is a strong reason not to use NAT-PT in the first place. - - -8.2 Renumbering Procedures and Applications' Use of DNS - - - One of the most difficult problems of systematic IP address - renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] 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. - - -9. Acknowledgements - - - Some recommendations (Section 4.3, Section 5.1) about IPv6 service - provisioning were moved here from [I-D.ietf-v6ops-mech-v2] 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. Jefsey Morfin, Ralph Droms, - Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and - Rob Austein provided useful feedback during the WG last call. Thomas - Narten provided extensive feedback during the IESG evaluation. - - -10. Security Considerations - - - This document reviews the operational procedures for IPv6 DNS - - - - -Durand, et al. Expires February 7, 2005 [Page 22] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - operations and does not have security considerations in itself. - - - 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 -- they could only be considered - in the environments where ingress filtering [RFC3704] has been - deployed. On the other hand, it should be noted that setting up an - authorization mechanism (e.g., a shared secret, or public-private - keys) between a node and the DNS server has to be done manually, and - may require quite a bit of time and expertise. - - - To re-emphasize which was already stated, the reverse+forward DNS - check provides very weak security at best, and the only - (questionable) security-related use for them may be in conjunction - with other mechanisms when authenticating a user. - - -11. References - - -11.1 Normative References - - - [I-D.ietf-dnsop-ipv6-dns-configuration] - Jeong, J., "IPv6 Host Configuration of DNS Server - Information Approaches", - draft-ietf-dnsop-ipv6-dns-configuration-02 (work in - progress), July 2004. - - - [I-D.ietf-dnsop-ipv6-transport-guidelines] - Durand, A. and J. Ihren, "DNS IPv6 transport operational - guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02 - (work in progress), March 2004. - - - [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-ipv6-deprecate-site-local] - Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work - in progress), March 2004. - - - [I-D.ietf-v6ops-application-transition] - Shin, M., "Application Aspects of IPv6 Transition", - draft-ietf-v6ops-application-transition-03 (work in - progress), June 2004. - - - [I-D.ietf-v6ops-renumbering-procedure] - - - - -Durand, et al. Expires February 7, 2005 [Page 23] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Baker, F., Lear, E. and R. Droms, "Procedures for - Renumbering an IPv6 Network without a Flag Day", - draft-ietf-v6ops-renumbering-procedure-01 (work in - progress), July 2004. - - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - - [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC 2182, - July 1997. - - - [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC 3041, - January 2001. - - - [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains - via IPv4 Clouds", RFC 3056, February 2001. - - - [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, - August 2001. - - - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and - M. Carney, "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - - [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. - Hain, "Representing Internet Protocol version 6 (IPv6) - Addresses in the Domain Name System (DNS)", RFC 3363, - August 2002. - - - [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) - Support for Internet Protocol version 6 (IPv6)", RFC 3364, - August 2002. - - - - - -Durand, et al. Expires February 7, 2005 [Page 24] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. - - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October - 2003. - - - [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. - - - [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. - - -11.2 Informative References - - - [I-D.durand-v6ops-natpt-dns-alg-issues] - Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", - draft-durand-v6ops-natpt-dns-alg-issues-00 (work in - progress), February 2003. - - - [I-D.huitema-v6ops-teredo] - Huitema, C., "Teredo: Tunneling IPv6 over UDP through - NATs", draft-huitema-v6ops-teredo-02 (work in progress), - June 2004. - - - [I-D.huston-6to4-reverse-dns] - Huston, G., "6to4 Reverse DNS", - draft-huston-6to4-reverse-dns-02 (work in progress), April - 2004. - - - [I-D.ietf-dhc-ddns-resolution] - Stapp, M., "Resolution of DNS Name Conflicts Among DHCP - Clients", draft-ietf-dhc-ddns-resolution-07 (work in - progress), July 2004. - - - [I-D.ietf-dhc-fqdn-option] - Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", - draft-ietf-dhc-fqdn-option-07 (work in progress), July - 2004. - - - [I-D.ietf-dnsext-dhcid-rr] - Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for - encoding DHCP information (DHCID RR)", - draft-ietf-dnsext-dhcid-rr-08 (work in progress), July - 2004. - - - [I-D.ietf-dnsop-bad-dns-res] - - - - -Durand, et al. Expires February 7, 2005 [Page 25] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Larson, M. and P. Barber, "Observed DNS Resolution - Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in - progress), July 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] - Senie, D., "Requiring DNS IN-ADDR Mapping", - draft-ietf-dnsop-inaddr-required-05 (work in progress), - April 2004. - - - [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-05 (work in - progress), June 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] - Wiljakka, J., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in - progress), May 2004. - - - [I-D.ietf-v6ops-mech-v2] - Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms - for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-04 - (work in progress), July 2004. - - - [I-D.ietf-v6ops-onlinkassumption] - Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery - On-Link Assumption Considered Harmful", - draft-ietf-v6ops-onlinkassumption-02 (work in progress), - May 2004. - - - [I-D.ietf-v6ops-v6onbydefault] - Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack - IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 - (work in progress), July 2004. - - - - -Durand, et al. Expires February 7, 2005 [Page 26] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - [I-D.jeong-dnsop-ipv6-dns-discovery] - Jeong, J., "IPv6 DNS Discovery based on Router - Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02 - (work in progress), July 2004. - - - [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] - Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01 (work in progress), - 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 - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - - [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - - [RFC2826] Internet Architecture Board, "IAB Technical Comment on the - Unique DNS Root", RFC 2826, May 2000. - - - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed - Networks", BCP 84, RFC 3704, March 2004. - - - -Authors' Addresses - - - Alain Durand - SUN Microsystems, Inc. - 17 Network circle UMPL17-202 - Menlo Park, CA 94025 - USA - - - EMail: Alain.Durand@sun.com - - - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 27] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm - Sweden - - - EMail: johani@autonomica.se - - - - Pekka Savola - CSC/FUNET - Espoo - Finland - - - EMail: psavola@funet.fi - - -Appendix A. Site-local Addressing Considerations for DNS - - - As site-local addressing has been deprecated, the considerations for - site-local addressing are discussed briefly here. Unique local - addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed - as a replacement, but being work-in-progress, it is not considered - further. - - - 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 - 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. - - - To faciliate reverse DNS (if desired) with site-local addresses, the - stub resolvers must look for DNS information from the local DNS - servers, not e.g. starting from the root servers, so that the - site-local information may be provided locally. Note that the - experience of private addresses in IPv4 has shown that the root - servers get loaded for requests for private address lookups in any - case. - - -Appendix B. Issues about Additional Data or TTL - - - [[ note to the RFC-editor: remove this section upon publication. ]] - - - This appendix tries to describe the apparent rought consensus about - additional data and TTL issues (sections 4.4 and 4.5), and present - questions when there appears to be no consensus. The point of - - - - -Durand, et al. Expires February 7, 2005 [Page 28] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - recording them here is to focus the discussion and get feedback. - - - Resolved: - - - a. If some critical additional data RRsets wouldn't fit, you set the - TC bit even if some RRsets did fit. - - - b. If some courtesy additional data RRsets wouldn't fit, you never - set the TC bit, but rather remove (at least some of) the courtesy - RRsets. - - - c. DNS servers should implement sanity checks on the resulting glue, - e.g., to disable circular dependencies. Then the responding - servers can use at-or-below-a-zone-cut criterion to determine - whether the additional data is critical or not. - - - Open issues (at least): - - - 1. if some critical additional data RRsets would fit, but some - wouldn't, and TC has to be set (see above), should one rather - remove the additional data that did fit, keep it, or leave - unspecified? - - - 2. if some courtesy additional data RRsets would fit, but some - wouldn't, and some will have to be removed from the response (no - TC is set, see above), what to do -- remove all courtesy RRsets, - keep all that fit, or leave unspecified? - - - 3. is it acceptable to use the transport used in the DNS query as a - hint which records to keep if not removing all the RRsets, if: a) - having to decide which critical additional data to keep, or b) - having to decide which courtesy additional data to keep? - - - 4. (this issue was discussed in section 4.5) if one RRset has TTL of - 100 seconds, and another the TTL of 300 seconds, what should the - caching server do after 100 seconds? Keep returning just one - RRset when returning additional data, or discard the other RRset - from the cache? - - - 5. how do we move forward from here? If we manage to get to some - form of consensus, how do we record it: a) just in - draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational - category only!), b) a separate BCP or similar by DNSEXT WG(?), - clarifying and giving recommendations, c) something else, what? - - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 29] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -Intellectual Property Statement - - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - 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 - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - -Disclaimer of Validity - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Copyright Statement - - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - -Acknowledgment - - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - -Durand, et al. Expires February 7, 2005 [Page 30]
\ No newline at end of file |
