Internet Engineering Task Force Alain Durand INTERNET-DRAFT SUN Microsystem July 20, 2001 Johan Ihren Expires Jan. 21, 2002 Autonomica AB NGtrans IPv6 DNS operational requirements and roadmap draft-ietf-ngtrans-dns-ops-req-01.txt Status of this memo This memo provides information to the Internet community. It does not 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 requirements and roadmap. It is the result of discussion from members of the NGtrans, DNSops and DNSext working groups. 1. IPv6 transition: Dual-stack vs IPv6 only nodes vs IPv6-mostly nodes 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 foreseen 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 some 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. With growing IPv6-only areas it will become increasingly cumbersome for such installations to maintain their DNS data on remote systems that are not available over local transport. 3. Issues with the standard resolution process The caching resolver that tries to lookup an name starts out at the root, and follows referrals until it is referred to a nameserver that is authoritative for the name. If somewhere down the chain of referrals it is referred to a nameserver that is only accessible over a type of transport that is unavailable, a traditional nameserver is unable to finish the task. When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is only a matter of time until this starts to happen and the complete DNS hierarchy starts to fragment into a graph where authoritative nameservers for certain nodes are only accessible over a certain transport. What is feared is that a node using only a particular version of IP, querying information about another node using the same version of IP can not do it because, somewhere in the chain of servers accessed during the resolution process, one or more of them will only be accessible with the other version of IP. A key requirement is that this will not happen and mechanisms must be in place to bridge the two worlds. However, it should be noted that, even though bridging has to be bi-directional, there is not strictly necessary to use the same technique both ways, although from a design perspective it would be preferrable. That is, it is perfectly acceptable to build two different mechanisms, one to enable IPv4 only hosts to query IPv6 only DNS servers and one for IPv6 only hosts to query IPv4 only DNS servers. Also, 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. 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 focus on possible architectures to enable those caching resolver to meet the above requirement. On the same idea, forwarding resolver will not be discussed here. 4. Architectures 4.1 Architecture number 1: Sent all queries with RD bit off only over IPv4 This would force all IPv6 DNS resolvers to 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. 4.2 Architecture number 2: Keep all zone data on IPv4 name servers This basically mandates an IPv6/IPv4 DNS general forwarder. In this architecture, all IPv6 DNS resolver are configure as forwarder and send 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. Furthermore, either some sort of dynamic forwarder location mechanism would be needed or significant maintenance issues would arise over time with statically configured forwarders. This solution has obvious scaling problems and can only be used in the beginning of the transition to the mixed environment. 4.3 Architecture number 3: Complete IPv4/IPv6 DNS solution This architecture require all zones to be accessible via IPv4 and IPv6. Note that, for each zone, there may be different physical servers answering queries made either with IPv4 or IPv6. Although desirable, this architecture is not implementable overnight. However, it can be a desirable long term 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. 4.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. There are serious concerns about both scalability of these fallback forwarders and mechanisms to locate them. 4.5 Architecture number 5: A lookup-proxy between transports The lookup-proxy design is based upon the following observation: When a resolver is following a chain of referrals and cannot complete because it is referred to an address it lacks transport for then it knows both the query and where to send it. It is just lacking transport. By using any kind of forwarder, half the information (the "where to send it" part) is thrown away and the referral process is restarted from the root since the forwarder is recursive. What is suggested is a new protocol that can send the tuple: {query, server} to a proxy, have the proxy send the query on (directly) to the server, collect the response and return it to the resolver. The proxy will be non-recursive, and thereby much more scalable. Furthermore, the proxy does not (or should not) know much about DNS, it should only know enough to repack the query and response in IPv4- and IPv6 packets respectively. The exact details of such a protocol and how the tuple is sent are beyond the scope of this document and should be discussed in the DNSext working group. Note that this can be done without changing the format of the actual DNS queries. The more zones will be accessible via dual-stack transport, the less this fall-back or lookup-proxy mechanisms 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. 4.6 Recommended architecture Architecture 1 is not acceptable, architecture 2 does not scale beyond early deployment, architecture 3 is only a long term perspective. Therefore there is a need to implement either architecture 4 and/or 5 before large scale IPv6 DNS deployment takes place. For lack of a better solution the rest of this document focus on steps needed to deploy IPv6 DNS capabilities based upon architecture 4+5. 5. Roadmap for DNS service in a mixed environment IPv4/IPv6 5.1 Bridging system Per paragraph 3, a bridging system must be in place prior to large scale deployment IPv6 DNS deployment. Note that fallback resolvers are easy to implement to bootstrap early deployment and can be replace later by more scalable proxy-lookup systems. 5.2 Root name service accessible via IPv6 The first DNS query a caching resolver will send is directed to a root name server. This, if the configuration of the bridging system is derived automatically from the DNS itself, there is a strong requirement to make root name service available over IPv6 transport. If the configuration is derived any other way or is done manually, there is a possibility to operate the system without an IPv6 accessible root in certain cases. However, as this document does not want to preclude any particular implementation of the bridging systems at this point, it is highly recommended that at some IPv6 enable root name server be in place as early as possible. It is an important step to show that IPv6 DNS deployment is possible. 5.3 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. Again, although not strictly necessary from a technical perspective, it is important to make sure that some TLD servers are accessible from the beginning via IPv6 so at least some label strings are resolvable with IPv6 transport without resorting to any fall-back mechanism. 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. 5.3 IPv6 glue at TLD registries. It is necessary for domains delegated from a TLD to be able to specify an IPv6 name server address to the TLD registry. This is not so much a technical issue as it is a question of management and procedures. 5.4 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 should in the future be moved to ip6.arpa. So, as in 5.2 and 5.3, although not strictly speaking a technical requirement, it is important to have at least one server for int/ip6.int and arpa/ip6.arpa accessible via IPv6. Having both zones, ip6.int and ip6.arpa, reachable via IPv6 as early as possible will simplify any transition from one to the other. 6. AAAA vs A6 This question will not be discussed here. 7. 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. 8 Editor address Alain Durand SUN Microsystems, Inc 901 San Antonio Road MPK17-202 Palo Alto, CA 94303-4900 USA Mail: Alain.Durand@sun.com Johan Ihren Autonomica AB Bellmansgatan 30 SE-118 47 Stockholm, Sweden johani@autonomica.se 9. References