Internet Engineering Task Force Alain Durand INTERNET-DRAFT SUN Microsystem September 6, 2001 Johan Ihren Expires March 7, 2002 Autonomica AB NGtrans IPv6 DNS operational requirements and roadmap draft-ietf-ngtrans-dns-ops-req-02.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 deployment roadmap. It is the result of discussion from members of the IPv6, NGtrans, DNSops and DNSext working groups. The DNS is looked as a critical part of the Internet infrastructure and is used for much more purposes than name to address resolution. Thus a smooth operation of the DNS is critical in the IPv6 transition. Discussion of this memo should happen in the NGtrans mailling list. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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. Note that those networks will still need to communicate with the rest of the Internet. Given the two above scenarios, the requirements discussed in this memo are not targeted at transitioning the DNS from IPv4 only to IPv6 only, but more at the transition of IPv4 only to a mixed environment, where some systems will be IPv4 only, some will be IPv6 only and others will be dual-stacked. 2. Issues with the standard resolution process 2.1 Following the referral chain 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. 2.2 Examples of problems for an IPv6 only resolver This problem shows for IPv6 only resolver trying to fetch data from a zone that is served by IPv6 servers when somewhere in the referral chain, the list of name servers pointed at does not contain any IPv6 reachable server. Hints for the root: X.ROOT-SERVERS.NET IN A 100.100.100.101 X.ROOT-SERVERS.NET IN AAAA 3ffe:ffff:100:100::1 In the root zone: org. IN NS dot-org.X.ROOT-SERVERS.NET dot-org.X.ROOT-SERVERS.NET IN A 100.100.100.102 In the .org zone: foobar.org. IN NS ns.foobar.org ns.foobar.org IN A 200.200.200.201 ns.foobar.org IN AAAA 3ffe:ffff:200:200::201 In the foobar.org zone: www.foorbar.org IN AAAA 3ffe:ffff:200:200::202 Although the zone foobar.org and the root are served by an IPv6 server, an IPv6 only resolver can not resolve www.foobar.org because there is no IPv6 server for the parent zone .org. 2.3 Examples of problems for an IPv4 only resolver Another instance of the problem shows for an IPv4 only MTA trying to send mail to someone in an IPv6 only domain which has made provision to have an IPv4 reachable MX. In the .org zone: foobar.org. IN NS ns.foobar.org ns.foobar.org IN AAAA 3ffe:ffff:200:200::201 3rd_party_dualstack_mail.org. IN NS ns.3rd_party_dualstack.org. ns.3rd_party_dualstack.org. IN A 100.100.100.103 in the foobar.org zone: foobar.org IN MX 10 mail6.foobar.org. foobar.org IN MX 20 mail4.3rd_party_dualstack.org. mail6.foobar.org. IN AAAA 3ffe:ffff:200:200::202 in the 3rd_party_dualstack_mail.org zone: mail4.3rd_party_dualstack.org. IN A 100.100.100.104 An IPv4 only host cannot get the information about the IPv4 MX relay mail4.3rd_party_dualstack_mail.org because the foobar.org zone is not served by an IPv4 DNS server. 3. IPv4 constraints Due to the very large IPv4 deployment phase, any solution that will require any change either on the resolver binary or resolver configuration is out of scope. 4. IPv6 constraints 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 only on remote systems that are not available over local transport. 5. Requirements The DNS is looked as a critical part of the Internet infrastructure and is used for much more purposes than name to address resolution. Thus, failures such as described earlier are to be prevented, and some kind of bridging between the two world is necessary. However, it should be noted that, even though bridging has to work both ways, it is not strictly necessary to use the same technique in each direction. 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. However, it is not clear if more than one bridging systems in a particular direction is a good thing or not. 5.1 IPv4 requirements Also, it may be the case that no bridging solution is possible to bridge an unmodified IPv4 resolver to an IPv6 only name server. In that case, there will be a requirement that any zone be served by at least one IPv4 DNS server. 5.2 IPv6 requirements The bridging systems that enable an IPv6 resolver to query data on an IPv4 server will have to be in place for a long time, will be a key part of the IPv6 transition and will heavily be used. Thus, the bridging systems MUST have good scaling properties. The IPv6 resolver MUST have a way to discover the bridging systems. This discovery mechanism MUST also have good scaling properties. The bridging systems MUST be able to bridge any zones and, in particular in the absence of IPv6 name servers for the root, the bridging systems MUST be able to bridge the root. 6. Roadmap for DNS service in a mixed environment IPv4/IPv6 6.1 Bridging system A robust, scalable bridging system MUST be in place prior to large scale deployment IPv6 DNS deployment. 6.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 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. 6.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. Also note that great care should be taken when adding IPv6 glue in the TLD delegation by the root. 6.4 IPv6 glue at TLD registries. Whenever glue is needed, 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. 6.5 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. [RFC3152] has deprecated ip6.int, thus reverse DNS queries MUST be moved to ip6.arpa. So, as in 6.2 and 6.3, although not strictly speaking a technical requirement, it is important to have at least one server for ip6.arpa accessible via IPv6. 7. Security considerations Any bridging system, acting as open relay, could be misused to create denial of service attacks on external DNS servers. Some provision should be made in the design of those relay 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 199 [RFC3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August 2001