Distributing K-Root Service by Anycast Routing of 193.0.14.129 Daniel Karrenberg Document ID: ripe-268 Date: 10 February 2003 Abstract This memo proposes to distribute the DNS service provided by k.root-servers.net across multiple locations in the Internet topology. It discusses the motivation for and the principles of implementation. A first inventory of detailed issues is provided in an appendix. Table of Contents * 1.0 Introduction * 2.0 Scope of this memo * 3.0 Proposal * 4.0 Operational & Funding Models + 4.1 Traditional + 4.2 Location Fees + 4.3 Operated and Funded Decentrally * 5.0 Implementation Plan + 5.1 Initial BGP change + 5.2 Move the Cold Standby to Service + 5.3 Implement Further Instances + 5.4 Spreading Further * Acknowledgements * Appendix A - Detailed Issues 1.0 Introduction DNS root name servers need to be accessible by Internet hosts in order for the DNS to function properly. Accessibility is determined by the ability of the server to handle a given query load and by the connectivity of the server to the rest of the Internet. The RIPE NCC operates k.root-servers.net (K-root) in the RIPE region in order to help safeguard the quality of the DNS in the Internet and in the RIPE region in particular. The RIPE NCC obtains guidance from RIPE. For K-root, the connectivity issue has been addressed by placing it at the LINX, a topologically very well connected point. The server load issue has been addressed by deploying successive generations of hardware with increased processing power and by distributing the load locally among a number of machines at different LINX sites. A cold spare system has been available in Amsterdam at all times to provide continuity in case of catastrophic failures at the primary server location. Over the years this set-up has provided very reliable service. However, issues about differences in connectivity to the service across the RIPE region have been raised repeatedly. A more distributed provision of the service is generally seen as positive because of: * lower network delays due to shorter paths between clients and servers, * less dependence on connectivity to a single location, * better load and DDoS attack resilience because of distributed servers, * more overall redundancy. For these reasons numerous organisations have offered to host additional servers operated by the RIPE NCC. So far this has not been considered because the number of unique IP addresses at which the service can be provided is exhausted by currently assigned servers. 2. Scope of this Memo This memo proposes to deploy multiple servers providing k.root-servers.net name service across the RIPE region, each using the same IP address. This is commonly called 'anycasting'. A detailed description of one implementation can be found in RFC3258. The intention of this memo is to establish the principles of this, inventarise the major issues and request comments from the RIPE community and other interested parties. An initial inventory of detailed issues is provided as an appendix. 3. Proposal Simply put, the RIPE NCC will provide K-root name service at multiple locations dispersed over the Internettopology but at the same IP address. No DNS client/resolver changes are necessary. The service will appear exactly the same for the users. Normal Internet routing will distribute the traffic among the different instances of K-root. This will be implemented by installing multiple copies of the current server sets at different points and announcing the current prefix 193.0.14/24 from these points. The main challenge with this set-up is to ensure consistency: * operation All servers will be operated in a consistent way by the RIPE NCC. They will have appropriate out-of-band access path to ensure that the operations centre can access them. * monitoring The availability and responses will be monitored by dedicated monitoring systems installed at multiple locations. Also the BGP propagation of the prefix 193.0.14/24 will be monitored constantly by the existing remote route collectors. [http://www.ripe.net/ris/] Users will be able to identify the particular instance they are using by published methods using DNS queries. [draft-ietf-dnsop-serverid] * correctness The correctness and authenticity of the root zone data will eventually be guaranteed using DNSSEC. Until this can be deployed the current method will need to be employed: ISPs will need to closely monitor where they route traffic to 193.0.14/24 and from where they accept traffic from that address. The RIPE NCC will publish and maintain a list with the locations of the k-root instances, the BGP autonomous system numbers of their immediate neighbours and any other information that can help ISPs and others to ensure that they reach an authentic instance of K-root. This list will be maintained until appropriate routing security technology is widely deployed. The RIPE NCC and K-root itself are well suited for this mode of operation. IANA asked the RIPE NCC to operate K-root, the geographic and topological location of K-root was not specified in any way other than "somewhere in the RIPE region". The RIPE NCC was chosen because it is neutral and professional but above all directly accountable to RIPE and its membership. The location at the LINX was subsequently chosen based on evaluation of the Internet topology in the region and arecommendation by the RIPE DNS working group. Distributing K- root over a number of places is a natural continuation of this policy. In addition to operating K-root at a remote location the RIPE NCC has considerable experience in operating distributed services. The Test Traffic Measurements Service operates more than 80 machines all over the world to collect performance measurements. Some of these can be used to monitor the DNS service of K-root as well. The Routing Information Service operates 9 remote route collectors at exchange points all over the world to collect BGP routing information. These route collectors will be used to monitor the routing of 193.0.14/24. At any point in time there is a trade-off between the added benefit of adding more servers and the difficulty of operating them consistently. The optimal number of servers depends on a large number of constantly changing factors. It needs to be evaluated continuously as things progress. 4. Operational & Funding Models For the purpose of stability and for gaining experience, all instances of K-root will be operated by the RIPE NCC. This ensures smooth transitions, consistency and correctness of root zone data. After the initial deployment, there are a number of possible