In addition to the existing global and local instances of K-root, we propose member instances of K-root. This article describes the benefits and how this will be implemented during the pilot phase.
Evolving Deployment of K.root-servers.net
The RIPE NCC operates one of the DNS root name servers: k.root-servers.net or K-root. Currently this service is provided by an anycast cloud that consists of five global instances and about a dozen local instances (see Figure 1).
Figure 1: Global and local instances of K-root
Global instances are routed globally and serve the whole Internet. Local instances are routed in a limited area and serve specific communities. Our operational experience shows that the number of global instances is sufficient to provide the service reliably at this time. We are constantly receiving requests for local instances. However, expanding the number of local instances increases the complexity of BGP anycasting and monitoring. In order to limit the operational complexity we have therefore not expanded the number of local instances in the recent past.
(If you want to learn more about operating K-root, you can click on the image below for more information.)
In order to satisfy the demand for local instances without the associated routing complexity, we propose to add a third category of instances: the member instance. A member instance serves the networks operated by a RIPE NCC member; it is not announced in BGP routing at all. A K-root member instance will respond to DNS queries at the k.root-servers.net service addresses over IPv6 and IPv4. The member may route queries from their networks towards the instance, but not announce the service addresses via BGP to other autonomous systems. Member instances will be monitored as any other k-root instance and m onitoring data will be available to the member. Queries originating from sources outside the member network will be flagged; this allows tracing of unintended route leakage and spoofing attacks.
Through k-root member instances users of the member networks will enjoy a very stable and low-latency root name service that is independent of any external connectivity fluctuations.
Figure 3: Comparison of response times for DNS SOA queries to all the root DNS servers
Pilot Phase
We will evaluate IGP routing architectures with the members in a pilot. The aim is to keep routing as simple as possible and to minimise the risk of unintended leakage. There also needs to be a mechanism to withdraw a member instance from service such that its clients fall back to the BGP anycast cloud.
The member instance will be operated by the RIPE NCC on hardware supplied, owned and hosted by the member. In order to limit complexity and to save operating costs this hardware will have to meet very specific specifications, especially regarding out-of band access and manageability. For the pilot deployment we will specify one specific server configuration. The division of responsibilities between the member and the RIPE NCC will be covered by a formal agreement that builds on the experience we gained with the operation of k-root instances, TTM boxes and RIS route collectors . One specific requirement worth noting is the replacement of the hardware after 36 months of operation.
Other RIPE NCC services can be made available on the same hardware on request of the member. Initially we will offer RIPE Atlas Ancho r functionality. Other such services will be developed later; examples we are considering are local instances of the RIPE whois service and local presentations of network measurement data. Once the hardware is deployed and operated, the incremental cost of bringing more RIPE NCC services closer to the member will be low.
We welcome all comments on the concept of K-root member instances. Spread the word and let us know what you think. If you are interested to participate in the pilot deployment and if you are a RIPE NCC member already, please contact kroot-member-pilot@ripe.net . Romeo Zwart and Daniel Karrenberg are available to answer any questions you may have.
Comments 2
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
WW144 •
The boundary condition(s) as laid in the text seem to indicate the (technical) assumption that the network which is related to a member, i.e. an LIR, is expected to consist of ONE (and only one AS). Multi-AS networks would not be eligible?
Daniel Karrenberg •
We are very open to requirements from the membership. Our intention with the member instances is to provide stable service to clients from the member network and to know exactly which addresses these clients have. This allows us to ground any reflection attacks from the member network close to the source and possibly later suppress reflection attacks via anycast servers on targets served by a member instance. Developing specific routing soloutions is what we want to do in the pilot. No member is excluded a-priori from the pilot. So if you are interested, let us know and include a description of your routing set-up. If you have a preferred routing soloution, let us know that also. Keep the goal in mind. We are aiming for as diverse a pilot as possible.