IETF DNSOP Working Group Y. Morishita Internet-Draft S. Sato Expires: January 12, 2006 T. Matsuura JPRS July 11, 2005 BGP Anycast Node for Authotitative Name Server Requirements draft-morishita-dnsop-anycast-node-requirements-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 January 14, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract IP anycasting [1] is a technology for sharing an IP address for Internet services in multiple servers. It is now being deployed for authoritative name servers, especially root name servers. RFC 3258 [2] describes a set of practices to provide for IP anycasting. And operators of authoritative name servers can also refer to RFC 2182 [3] and 2870 [4] for general guidance on appropriate practice Morishita, et al. Expires January 14, 2006 [Page 1] Internet-Draft Anycast Node Requirements July 2005 for authoritative name servers. This memo describes details of requirements and preconditions for making authoritative name servers which are needed in real Internet, to realize the practices in RFC 2182, 2870 and 3258. 1. Introduction Applying IP anycasting to DNS, name server operators can increase and distribute authoritative name servers topologically and geographically, without violating the DNS protocol [5] [6]. This improves the robustness against DoS attack and/or name server down. And this improves the DNS total performance by decreasing RTT for authoritative name server, and distributing authoritative name servers' load. But in IP anycasting environment, IP address does not specify the end point in the Internet communication, then it means that IP address does not specify the real communicating peer. That is, when destination IP address is in under IP anycast mesh, client can not control which anycast node process the sending datagrams. Then, for example, if a part of IP anycast nodes are corrupted, it is hard to determine which nodes are bad, especially the bad nodes which answer the bad response. It is a risk of the deployment of IP anycasting. Of course, DNS is one of an important infrastructure of the Internet, introducing IP anycasting MUST NOT decrease the total availability and reliability of DNS. This memo describes a set of requirements and preconditions for making IP anycast nodes for authoritative name servers, which are widely distributed. In this memo, authors focus on BGP anycast. Because in general, it has more widely distributed locations than IGP anycast. But the basic point of view can apply to IGP anycast, too. 2. BGP anycast and DNS service BGP anycast is a part of IP anycasting technology. It uses a shared IP address and a shared AS number for each BGP anycast nodes, and their nodes are placed in the Internet. Reachability of each nodes are served by BGP routing protocol [7]. Each anycast nodes propagate the routing information of shared IP address and AS number by BGP. Each BGP routers in the Internet choose 'nearest' node by BGP's best route selection algorithm. That is, the access for the shared IP address is distributed to each Morishita, et al. Expires January 14, 2006 [Page 2] Internet-Draft Anycast Node Requirements July 2005 anycast nodes, it depends on each clients' location. BGP anycast can control each anycast nodes are configured as 'local node' or 'global node' by using BGP's routing framework. Concretely, use of the 'no-export' BGP community [8], the 'local node' operators can limit distributing the routing information of anycast node except for directly peering nodes. By using this, the 'local node' can localize the access for anycast node. On the other hand, the 'global node' operators apply the normal BGP anycast for its node. In this memo, authors focus on 'global node' as main target, but authors believe it can be applied as 'local node' also. When one of BGP anycast node is down, routing information is automatically recalculated and the datagrams for anycast node are automatically detoured to another anycast node. Then, BGP anycast provides redundancy for Internet service. And current BGP anycast is hard to apply for TCP-based service. But almost of DNS service is based on a single UDP packet, then BGP anycast is being deployed on authoritative name server. As an important point, BGP anycast MUST need an exclusive IP address which is a provider independent CIDR block and AS number for making each anycast nodes. 3. Requirements and preconditions for making BGP anycast nodes As described before, BGP anycast is one of effective way for making distributed authoritative name server environment. In recent authoritative name server, especially large TLD servers, they MUST serve more data then other name servers, and they require more frequent updating frequency of data and higher reliability. Then, when BGP anycast is applied to their servers, the requirements and preconditions which described by this memo would be more important. In this section, this memo describes requirements and preconditions for making BGP anycast node for authoritave name servers in the following two point of views, the Internet access service, and data center. 3.1 Choosing the Internet access service When making BGP anycast nodes distributed in the wide area, it is important for making network environment with geographical and networking diversity. In case of making such network environment, each anycasting nodes SHOULD have Internet connectivity from different Internet access Morishita, et al. Expires January 14, 2006 [Page 3] Internet-Draft Anycast Node Requirements July 2005 service provider (hereafter, called ISP) for ensuring network diversity. And as described before, in case of ensuring BGP connectivity. That is, when chooing the Internet access service, the owner of authoritative name servers MUST consider the following preconditions and requirements. 3.1.1 Reliability of the backbone network When making an important authoritative name server, for example, serving for root and/or TLD zone, high reliability for ISP's network itself is needed. For implementing this, it is desirable for ISP itself to have owned and managed its backbone network. An ISP which owns and manages the backbone network itself, has stronger responsibility for network stability then it doesn't. Then it is expectable that the stability of a network is higher. Of course, it is not absolute requirement, but it will surely be one of the important elements. 3.1.2 Connectivity of outside area In case of authoritative name service, especially root and/or TLD zone, there are many accesses including outside of its country and local area. Then, connectibity for them MUST be needed. That is, in the same reason of Section 3.1.1, it is desirable that an ISP which owns and manages the outside area connectivity. 3.1.3 Peering When ensuring highly reliable Internet connectivity, it is an important element to ensuring the diversity of Internet routes including many alternative paths. Moreover, providing DNS service to many ISP networks efficiently, it is desirable for ISP to have many BGP peers with other ISPs. 3.1.4 Connectivity for provider independent CIDR block and AS number When making BGP anycast node, a provider independent CIDR block and an AS number MUST be prepare in advance, and they MUST be used for DNS service at each anycast nodes. It is also needed for making the multihomed connectivity. In this case, ISP MUST support propagating CIDR block and AS number for anycasting service to the Internet widely, and ISP MUST provide connectivity for them from the Internet, concretely, ISP MUST provide transit service. Morishita, et al. Expires January 14, 2006 [Page 4] Internet-Draft Anycast Node Requirements July 2005 3.1.5 Connectivity for administration And as RFC 3258 described, it MUST be needed an Internet connectivity for anycast node administration which is different for IP anycasting. 3.1.6 Connectivity for IPv6 There is no standard for IPv6 anycasting, but in near future, IP anycasting for IPv6 would be needed. That is, the anycast node owner SHOULD ensure IPv6 connectivity. 3.2 Choosing the location For choosing BGP anycast node location, RFC 2182 and 2870 can be refered for useful guidance on appropriate practice for authoritative name servers. By referencing them, when choosing the location for BGP anycast node, the owner of authoritative name servers MUST consider the following preconditions and requirements. 3.2.1 Providing higher security level To realize the high defense performance to physical destruction and/or the intrusion from the outside, the location MUST provide higher security level. 3.2.2 Providing higher redundancy of electrical power supply DNS service requires high continuity and stability, the location MUST provide higher redundancy of electrical power supply and urgent power supply equipment for emergency. 3.2.3 Providing higher tolerance against disasters For the same reason of Section 3.2.2, the location MUST provide higher tolerance against disasters, for example fire, earthquake and others. 3.2.4 Providing the diversity of locations For ensuring torerance and redundancy, the diversity of locations is needed. Concretely, if a fatal disaster occurred at one location, the continuity of DNS service MUST be ensured. 4. Cost issue In technical, BGP anycast nodes can be made in many locations. But it is not realistic to prepare it over necessity. In general, for satisfying the preconditions and requirements which is previously Morishita, et al. Expires January 14, 2006 [Page 5] Internet-Draft Anycast Node Requirements July 2005 described, BGP anycast node needs high cost, including financial and human resources. In the current condition, this cost is mandatory for making BGP anycast node. Especially, the guaranteed the quality of service level, for example SLA (Service Level Agreement), makes higher cost than normal Internet connectivity. This is one of big burden for operating BGP anycast node. This is one of in the future issue for deploying IP anycasting. Furthermore, for administrating remote anycast nodes smoothly, more human recources are needed, including local and remote technical staff. When making BGP anycast node, the owner of authoritative name servers MUST consider about this issue. 5. Measurement issue For verifying selection is appropriate or not, objective measurement from another network place is very important. When making BGP anycast mesh in the wide area, the measurement MUST also be carried out by the wide area. In such case, there is a effective guideline defined by ICANN, it is called as "CNNP test" [9]. This helps for making BGP anycast node. And as typical notable project, RIPE NCC's DNSMON service [10]. The continuity is an important point for measurement. And operators SHOULD verify that the continuity of DNS service is ensured by measurement. 6. Security Considerations TBD 7. Acknowledgements The authors gratefully acknowledge the many helpful suggestions of the members of JPRS Research and Development Department and System administration Department. This memo is included the research activities funded by National Institute of Information and Communications Technology (NICT). 8. References [1] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. Morishita, et al. Expires January 14, 2006 [Page 6] Internet-Draft Anycast Node Requirements July 2005 [2] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, April 2002. [3] Elz, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", RFC 2182, July 1997. [4] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", RFC 2870, June 2000. [5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [6] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 1035, November 1987. [7] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [8] Chen, E. and J. Stewart, "A Framework for Inter-Domain Route Aggregation", RFC 2519, February 1999. [9] "Unsponsored TLD Agreement: Appendix D (.info)", May 2001. [10] "RIPE-NCC/DNS Server Monitoring", . Authors' Addresses Yasuhiro Orange Morishita Research and Development Department, Japan Registry Services Co.,Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Email: yasuhiro@jprs.co.jp Shinta Sato System Administration Department, Japan Registry Services Co.,Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Email: shinta@jprs.co.jp Morishita, et al. Expires January 14, 2006 [Page 7] Internet-Draft Anycast Node Requirements July 2005 Takayasu Matsuura System Administration Department, Japan Registry Services Co.,Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Email: matuura@jprs.co.jp Morishita, et al. Expires January 14, 2006 [Page 8] Internet-Draft Anycast Node Requirements July 2005 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 (2005). 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. Morishita, et al. Expires January 14, 2006 [Page 9]