IETF DNSOP Working Group S. Lee Internet-Draft C. Park Intended status: Informational W. Kim Expires: June 7, 2007 NIDA December 4, 2006 A Model of IPv4/IPv6 Dual Stack Anycast DNS Service draft-lee-anycastdns-service-00.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 June 7, 2007. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract This memo shows an example of how to provide and implement IPv4/IPv6 dual stack anycast DNS services, which are based on the experience of IPv4/IPv6 anycast DNS implementation. In order to provide a reference model to DNS operators who have a plan to deploy IPv4/IPv6 anycast DNS services onto their own DNS servers in the future, this memo mainly specifies a way to configure IPv6-related functions without IPv4-related matters. Lee, et al. Expires June 7, 2007 [Page 1] Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IPv6 Anycast DNS . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. IPv6 Anycast Address Issue . . . . . . . . . . . . . . . . 4 2.2. IPv6 Anycast Prefix Assignment . . . . . . . . . . . . . . 4 3. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Internal Routing . . . . . . . . . . . . . . . . . . . . . 6 3.2. External Routing . . . . . . . . . . . . . . . . . . . . . 6 4. Managements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. BGP Routing Management . . . . . . . . . . . . . . . . . . 7 4.2. Remote System Management . . . . . . . . . . . . . . . . . 7 4.3. DNS Zone-transfer Management . . . . . . . . . . . . . . . 7 4.4. DNS Daemon Management . . . . . . . . . . . . . . . . . . 7 5. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Lee, et al. Expires June 7, 2007 [Page 2] Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006 1. Introduction DNS service is one of the most important Internet infrastructure, and anycast [1] based DNS service [2] has been discussed within DNS operation relevant areas for providing stable DNS services to the users. In general, anycast-base DNS service has various advantages, such as effective dealing with DDoS attack, overcoming a limitation of authoritative name server's physical numbers and improvement of service stability and performance through a distribution of DNS traffic; all of these are described at more length in other anycast- related documents. Because of these merits, the several DNS nodes(e.g., Root DNS, TLD DNS and sub-level authoritative DNS) have been expanded with using ancyast-based DNS architecture, and also, kr DNS has been deploying and providing a IPv4 anycast DNS commercial services since July 2005. In case of IPv6 anycast, due to outstanding two regulations [3], it was substantially impossible to deploy at the real IPv6 Internet environment. However, as the related rules were removed, as described in [4], IPv6 anycast-based DNS service could be applicable to name servers on real IPv6 Internet. NIDA(National Internet Development Agency of Korea) has implemented IPv4/IPv6 anycast-based kr DNS service on this above background since July 2006. The implementation of IPv4/IPv6 anycast DNS service has capability of redundant service architecture, traffic load-balancing among DNS servers. Futhermore, it supports overall DNS service improvement, such as robustness, redundancy and resiliency of DNS Services. 2. IPv6 Anycast DNS IPv6 anycast-based DNS, which would be selected as an authoritative name server located in the nearest path on the routing environment, can be divided into two parts, one is BGP routing-based anycast service and the other is IGP routing-based anycast service. This memo specifies the implementation of IPv6 anycast DNS service which uses a BGP-based routing. This section describes an IPv6 anycast address issue and IPv6 anycast prefix assignment for IPv6 anycast DNS service. Lee, et al. Expires June 7, 2007 [Page 3] Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006 2.1. IPv6 Anycast Address Issue In order to deploy an IPv6 anycast address to the name server served in the IPv6 environment, there were two restrictions as follows [3]. o An anycast address must not be used as the source address of an IPv6 packet. o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only. Because of these restrictions, it was impossible to apply an IPv6 anycast to DNS service in the IPv6 Internet environment until now. However, the above restrictions were removed by RFC4291[4]. Therefore, an anycast address can be used as the source address of an IPv6 packet and an anycast address can be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router also. This means that it is possible to apply an IPv6 anycast-based DNS service to name server, and NIDA has been providing IPv4/IPv6 anycast DNS service following the new specification. 2.2. IPv6 Anycast Prefix Assignment IPv6 anycast address just uses a global IPv6 unicast address, that is, it is taken from the unicast address spaces (of any scope) and is not syntactically distinguishable from unicast address (RFC4291[4]), for service of TLD anycast DNS server. IPv6 anycast node should advertise an address block(prefix) which has no problem with global routing. IPv6 anycast prefix assigned to TLD DNS is decided by RIR's address allocation policy. In general, a determination of BGP filtering block size is also based on this policy. In case of kr DNS, it was assigned /32 IPv6 address block by APNIC's IPv6 address allocation policy [5]. Other RIRs(e.g., RIPE-NCC and ARIN) have /48 allocation policy for that. About this IPv6 address block(prefix) assignment(or allocation) policy issue, it is necessary to discuss among RIRs or in IETF in the future. 3. Topology The architecture was considered to have stability and scalability for providing IPv4/IPv6 anycast DNS service. This will be divided into two parts. Lee, et al. Expires June 7, 2007 [Page 4] Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006 First, an active/standby system was implemented by using IGP protocol internally. Second, a BGP routing based anycast system was implemented by BGP protocol externally. Figure 1 shows an configuration of this service architecture. In aspect of external routing, that has redundant architecture by usage of BGP4+ between Router_1 and Router_A and between Router_2 and Router_B. In aspect of internal routing, the traffic route was duplicated for stability of DNS service. Router_A and Router_B have been configured by cross-connections to DNS servers through Switch_A and Switch_B, and divided IPv6 networks into two parts to enable DNS traffics to be distributed by DNS server. This architecture is configured with consideration of scalability of routers and servers, and it would be easy to expand the numbers of routers and servers according to increasing of throughput in the future. IPv6 Internet IPv6 Internet | | | | +----------+ +----------+ | Router_1 | ASN X | Router_2 | +----------+ +----------+ ______|________________________________|______ | Anycast site | +----------+ +----------+ | Router_A | ASN XX | Router_B | +----------+ +----------+ | | | | | | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| | | |_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | | | | | | | | | +----------+ +----------+ | Switch_A | IGP | Switch_B | +----------+ +----------+ | | | | | | _ _ _ _ _ _ _ _ _ _ _ __ _ _ _| | | |_|_ _ _ _ _ _ _ _ _ _ _ __ _ _ _ | | | | | Subenet1--| |--Subnet2 Subenet1--| |--Subnet2 +----------+ +----------+ | DNS_A | | DNS_S | +----------+ +----------+ Figure 1 : DNS anycast mirror site topology Lee, et al. Expires June 7, 2007 [Page 5] Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006 3.1. Internal Routing Internal IPv6 network is connected with two subnets(subnet1, subnet2) between DNSs(DNS_A, DNS_S) with IGP routing process running and routers(Router_A, Router_B). IPv6 anycast prefix can be dynamically delivered to IGP routing table of routers(Router_A, Router_B) through the message of IGP routing protocol in this area. Also, as IGP routing is configured on DNS, it is important to configure and reflect the anycast address prefix to the routing table. The IPv6 address of physical interface is assigned with unique local IPv6 addresses(FC00::/7) (RFC4193 [6]) for IGP routing among equipments. But, these addresses should never be advertised by IGP protocol toward external Internet. 3.2. External Routing The anycast address(/32 prefix) on IGP routing table is dynamically delivered to routing table of Router_A and Router_B. As Router_A and Router_B advertise IPv6 anycast address to external routers(Router_1, Router_2), these routers are just configured to export only an anycast prefix to the external site(ASN X). If certain failures occur, such as DNS daemon down, failure of DNS interface or removing of IPv6 anycast prefix on routing table of IGP routing protocol, the IPv6 anycast prefix should be automatically removed on BGP routing table of Router_A and Router_B. In this case, IPv6 anycast prefix is never advertised to peering site(ASN X). In consequence, this means that a status of anycast DNS service should be immediately reflected to upper-side nodes and then DNS query traffics are forwarded to the next closest DNS site instead of forwarding to anycast DNS site with failure. It is possible to provide DNS service, which is served by the closest DNS server in aspect of clients, through the implementation of BGP routing-based anycast. It shows that anycast DNS locally handles DNS query traffics through a routing based distribution mechanism and makes preparation against DNS service failures by DDoS attack. 4. Managements When anycast DNS is added on remote site to provide more effective service rather than generic DNS service, there are several general guidelines to consider. This section lists recommendations for stable operation and maintenance from remote site. Lee, et al. Expires June 7, 2007 [Page 6] Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006 4.1. BGP Routing Management To manage and check the BGP routing status, the well-known monitoring tools, such as BGP looking glass and BGPlay [7], supporting IPv6 protocol can be used for monitoring the global routing status and seeing how things will shape up. 4.2. Remote System Management For monitoring the remote system, The console server based on TCP/IP protocol can be used, and a back-up access network based on PSTN is also be able to be used for preparation against console server's failure. 4.3. DNS Zone-transfer Management In case of anycast DNS service, anycast IP address is recommended not to be used as a source address for zone-transfer, because zone- transfer works based on TCP connection with unicast address. Therefore, management IP address is recommended to download zone files from the master server. 4.4. DNS Daemon Management Whenever a DNS service daemon is failed on anycast DNS, It requires that DNS damon status checking program spontaneously works to avoid a incoming DNS query packet by using a mechanism that reflects that failure status on the routing table. 5. Considerations Confirmation of the network status of IPv6 peering site(ASN X): The BGP peering site's service line status between anycast DNS site(ASN XX) and BGP-peering site(ASN X), and the overall status of BGP peering site internetworked with upper-side transit-ISPs or IX should be checked before the installation of anycast DNS site. BGP filtering: The BGP filtering and packet access rules on the upper-side network of anycast site(ASN XX) should be checked in advance. BGP security configuration: As setting up the BGP configuration, the authentication algorithm, such as MD5(Message Digest Algorithm 5) is recommend to be configured on BGP peering session, and then prepared the various malicious attacks. Lee, et al. Expires June 7, 2007 [Page 7] Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006 6. References [1] Partridge, C., "Host Anycasting Service", RFC 1546, November 1993. [2] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, April 2002. [3] Hinden, R., "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [4] Hinden, R., "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [5] "APNIC Policy document, IPv6 Address Allocation and Assignment Policy", May 2005. [6] Hinden, R., "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [7] "BGPlay RIPE NCC Site, http://www.ris.ripe.net/bgplay". Authors' Addresses Seunghoon Lee National Internet Development Agency of Korea (KTF Bldg, 3F) 1321-11, Secho-2Dong Secho-Gu Seoul 137-857 Republic of Korea Email: sehlee@nida.or.kr Chanki Park National Internet Development Agency of Korea (KTF Bldg, 3F) 1321-11, Secho-2Dong Secho-Gu Seoul 137-857 Republic of Korea Email: ckp@nida.or.kr Lee, et al. Expires June 7, 2007 [Page 8] Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006 Weon Kim National Internet Development Agency of Korea (KTF Bldg, 3F) 1321-11, Secho-2Dong Secho-Gu Seoul 137-857 Republic of Korea Email: wkim@nida.or.kr Lee, et al. Expires June 7, 2007 [Page 9] Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lee, et al. Expires June 7, 2007 [Page 10]