Internet Engineering Task Force Alain Durand INTERNET-DRAFT SUN Microsystem July 13, 2001 (editor) Expires Jan. 14, 2002 NGtrans IPv6 DNS operational requirements draft-ietf-ngtrans-dns-ops-req-00.txt Status of this memo This memo provides information to the Internet community. It does no specify an Internet standard of any kind. This memo is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes IPv6 DNS operational needs. It is the result of discussion from members of the NGtrans wg. 1. IPv6 transition: Dual-stack vs IPv6 only nodes vs IPv6-mostly nodes Transition to IPv6 can happen following two different strategies: 1.1. Incremental deployment on existing network. This needs to be done without disturbing IPv4 service. This strategy relies heavily on dual-stack nodes and tunnels. It is foresee that this scenario is likely to happen in corporate networks. 1.2. Large scale deployment of new infrastructure This scenario envision large to very large networks where public IPv4 address space is not available and private address is not practical. Nodes in this scenario will very likely be IPv6-only or IPv6-mostly (getting an IPv4 address only on demand). This scenario is likely to happen in the wireless/3G world. So the requirements discussed in this memo are not targeted at transitioning the DNS from IPv4 only to IPv6 only, but more at the transition to a mixed environment, where some systems will be IPv4 only, some will be IPv6 only and others will be dual- stacked. 2. Rationale why DNS servers needs to be accessible via IPv6 When IPv6-only and IPv6-mostly devices send DNS queries, per configuration/implementation they have little choice but to use IPv6 transport. For example, it may be too expensive, too slow or just not possible to get an IPv4 address for just that purpose. 3. Architecture A key point in the architecture required is to make sure not to partition the Internet from a DNS perspective. In an ideal world, provisions should be made that any system, regardless of its IP version, could get information about any other system, even if some of the queried DNS zone can only be accessible only using one particular version of IP. This requirements is stronger for new IPv6 systems than for existing IPv4 systems. That is, it may be acceptable for old IPv4 systems to fail to discover information about some new IPv6 systems, however, any new IPv6 system should be able to get DNS information about any IPv4 system. Also, it should be strongly encourage that new IPv4 system should be able to also query information about IPv6 systems. 3.1 IPv6 stub-resolver IPv4 and IPv6 stub resolvers are expected to send DNS queries with The RD (Recursion Desire) bit ON to a DNS server that will act as caching resolver. The rest of the discussion will not consider the stub-resolver case. 3.2 Architecture number 1: All IPv6 DNS resolver send all DNS queries using IPv4. This architecture impose a dual-stack model for all DNS resolvers and will not scale. It will not be further considered. 3.2 Architecture number 2: IPv6/IPv4 DNS general forwarder In this architecture, all IPv6 DNS resolver are configure to forward all their DNS queries over IPv6 with the RD bit ON to a small number of dual-stack DNS servers which will accept to relay their queries over IPv4 or IPv6 on their behalf. Such relays may decide to use caching techniques to speed-up request. It is perceived that an enormous amount of memory Would be needed to do so. Also, if negative caching is also used, great care is needed in the choice of the TTL of the records in the negative cache. This solution has obvious scaling problems and can only be used in the beginning of the transition to the mixed environment. 3.3 Architecture number 3: Pure IPv6 DNS solution In this architecture, all DNS queries originating from IPv6 resolvers are made over IPv6. This will require not only a root DNS server accessible via IPv6, but also a DNS server accessible via IPv6 for all possible DNS zone in the Internet. This solution would result today on the partition of the Internet into at least two separated world from a DNS perspective, and is not acceptable as is. However, in a long term perspective, having all zones accessible via both IPv4 and IPv6 will be a desireable goal. One way to make progress toward that direction is to ensure that, each time a new zone is delegated, both IPv4 and IPv6 glue are provided. There would then be an opportunity for some people to offer dual- stack DNS secondary hosting. 3.4 Architecture number 4: Last resort, fallback forwarder This architecture is a mix of the two previous ones. The lookup of name starts out by following the referrals from the root down until either the answer is found or following the referral requires a transport (IPv4 or IPv6) that is not available. When this happens the query is "forwarded" to a dual stack forwarder as a last resort. Without changing anything in the DNS protocols, this will impose the fall back DNS forwarder to accept recursive queries and redo the complete query by following the hint chain again from the root. Good caching techniques may help to reduce the load on the forwarder. Should the recursive fall-back forwarder not be a viable solution because of scalability or other reasons, which seem likely, then a more complicated design will be necessary. A new protocol that forwards both the query and the destination nameserver to a non-recursive "lookup-proxy" is needed. The lookup-proxy forwards the query directly to the destination nameserver, thereby achieving much better scalability. The more zones will be accessible via dual-stack transport, the less this fall-back mechanism will be used. And, as the top level zones in a label string are always the first to be queried, there is a big incentive to get them accessible via IPv6 as soon as possible. 3.5 Recommended architecture Architecture 1 is not acceptable, architecture 2 does not scale beyond early deployment, architecture 3 is only a long term goal, so there is a need to implement architecture 4 before large scale deployment takes place. The rest of this document focus on steps needed to implement it. 4. Needs for a root name server accessible via IPv6 The first DNS query an IPv6-only or IPv6-mostly DNS server will do is for a root name server, thus there is a need for at least one well known, well maintained, root DNS server accessible via IPv6. 5. Needs for TLDs servers accessible via IPv6 Having the capability to query a root name server using IPv6 is just the first step. The next one is to query a TLD for a NS record pointing to a domain name. Thus, to make sure that at least some label strings are resolvable with IPv6 without using the fall-back mechanism, some TLD servers need to be accessible via IPv6 from the beginning. Note that this is already the case for .jp and .cc. Also note that great care should be taken when adding IPv6 glue in the TLD delegation by the root. 6. Needs for IPv6 NS delegations under TLDs Domains under TLDs are usually under the control of customers who can manage their own zone. However, they need to be able to specify an IPv6 address to their registrars for their name server (NS) delegation. 7. Needs for reverse path DNS servers Reverse DNS queries should also be supported in IPv6, for the same reasons as direct queries. Today's resolvers do reverse nibbles queries under the ip6.int tree. This may in the future be moved to ip6.arpa. So there is a need for at least one server for int/ip6.int and arpa/ip6.arpa to be accessible via IPv6 Having both ip6.int and ip6.arpa reachable via IPv6 as early as possible will simplify any transition from one to the other. 8. AAAA vs A6 This question will not be discussed here. 9. Security considerations Fall-back DNS, especially in the non-recursive solution, could be misused to create denial of service attacks on external DNS servers. Some provision should be made in the design of those forwarder to deal with this issue. 10. Editor address Alain Durand SUN Microsystems, Inc 901 San Antonio Road MPK17-202 Palo Alto, CA 94303-4900 USA Mail: Alain.Durand@sun.com 11. References