This is an experiment to see if we can increase the capacity and resiliency of the RIPE NCC's authoritative DNS service (AS197000). This service hosts all the reverse DNS zones, ripe.net and provides secondary service for various ccTLDs.
RIPE NCC's Authoritative DNS Service
The RIPE NCC operates two distinct DNS services. One of these, K-root, is well known. However, although the other service is less well known, it is just as important as K-root, if not more so.
The authoritative DNS service (or AuthDNS) carries over 4,000 zones, including:
- ripe.net and other RIPE NCC infrastructure domains
- The reverse DNS zones of address space allocated to the RIPE NCC (eg. 193.in-addr.arpa)
- The reverse DNS zones of address space allocation to the other RIRs (secondary DNS)
- Over 30 ccTLDs (secondary DNS)
- ENUM (e164.arpa)
- Large reverse DNS zones of some of our LIRs (only if the zone is for an IPv4 /16-sized prefix, or a /32-sized IPv6 prefix)
- Some miscellaneous infrastructure domains, such as root-servers.org and as112.net
AuthDNS is quite distinct from K-root. It has its own AS number (AS197000) and address prefixes and its routers and servers are separate from those of K-root. So, apart from some common elements in our configuration management, K-root and AuthDNS are completely independent.
Current Locations and Query Load
This AuthDNS service is currently anycasted from three locations in Europe:
At each site, we have networking gear connected to three servers. These nine servers across three sites handle about 90,000 q/s, with peaks of over 120,000 q/s.
Wider Anycast Experiment
While our three locations are serving us fairly well, we feel that we can add even more capacity to this service by introducing more locations. This would also provide more DDoS resiliency, while lowering the latency from DNS resolvers to the zones hosted on this service.
We have been quite successful at increasing the K-root network by cooperating with hosts who provide a single server in their network, from which to announce K-root prefixes. We are therefore about to start an experiment using a similar model of deploying a single server, which provides the DNS service as well as handling the BGP peerings. Our host for this experiment is Anexia IT, which has its main office in Vienna. We will start by announcing AuthDNS prefixes from a server in their network in Vienna, and observe the effects of it on routing, query load distribution and any other effects. We expect to run this experiment for three months, at the end of which we can decide if this model is worth pursuing.
If you have any questions of comments about the experiment, or would like to find out more, please feel free to let us know in the comments section below.