We're steadily expanding the capacity of our Authoritative DNS (AuthDNS) cluster to ensure it keeps providing resilient and speedy service. Here's a look at what the cluster does and the steps we're taking towards its expansion.
The operation of our Authoritative DNS (AuthDNS) cluster is an important part of the broader range of services we provide to our members and the wider Internet community. Not only does the cluster serve ripe.net and other domains we manage, but it also plays a crucial part in our provision of Reverse DNS and Secondary DNS services.
At present, the cluster is composed of three core instances located in Amsterdam, London and Stockholm, as well as two hosted instances in Vienna and Rome. It announces 193.0.9.0/24 and 2001:67c:e0::/48 from AS 197000.
What AuthDNS Does
In all, the cluster serves over 4,000 zones. These zones fall into the following categories:
- ripe.net and related zones
The ripe.net zone is quite important. All of the services we offer at the RIPE NCC have names ending in ripe.net. Additionally, we also manage zones such as menog.org, enog.org, enumdata.org, nro.net, nro.org and rob-blokzijl-foundation.org. All these zones are served from this AuthDNS cluster.
-
Reverse DNS
Our primary function as an RIR is to allocate IP addresses to members, and these IP addresses require reverse DNS mapping. In particular, IPv4 addresses are mapped to names in the in-addr.arpa zone, while IPv6 addresses are mapped to names in the ip6.arpa zone. These two zones are managed by ICANN. For more details on this, refer to RFC 5855.
ICANN operates one server for these zones, and has an agreement with each of the five RIRs to run a server. Thus, there are six name servers in total for these zones. Of these, we run the server named F.in-addr-servers.arpa and F.ip6-servers.arpa.
Additionally, each RIR is responsible for managing the reverse DNS zones corresponding to address space allocated to it. For example, we manage the zones 193.in-addr.arpa (corresponding to 193.0.0.0/8) and 0.a.2.ip6.arpa (corresponding to 2a00::/12).
Users can request reverse DNS delegation (NS records) in these zones by creating domain objects in the RIPE Database.
-
Secondary DNS for RIRs
In addition to serving all the reverse DNS zones corresponding to RIPE NCC address space, we also provide secondary DNS for the reverse DNS zones of the other four RIRs in a reciprocal agreement.
-
Secondary DNS for ccTLDs
We provide secondary DNS service to a number of small and developing ccTLDs, according to the criteria in RIPE-663.
-
Secondary DNS for LIRs
Members who have /16-sized IPv4 or /32-sized IPv6 allocations are allowed to use our server ns.ripe.net as a secondary DNS server for their reverse DNS zones.
Capacity Concerns
When we built the cluster back in 2010, the query rate was much lower than it is now, and we worked out that a cluster of three instances would be enough. Each instance has a router that spreads the DNS queries across three servers, running a mix of BIND, Knot DNS and NSD. The routers are connected to Internet exchanges at 1 Gbit/s.
Back then, the query rate was no more than about 50,000 q/s. Over the years, the traffic to this cluster has been increasing, as more and more resolvers have become active on the Internet and as DNS traffic in general has increased. These days, the cluster receives about 160,000 q/s, with peaks of up to 200,000 q/s. The link utilisation at the busiest site (London) is around 40%. This means that even a moderate increase in the query rate can start to clog the link. In fact, we have observed bursts of traffic that have caused the link utilisation to come close to 100%.
It is therefore necessary to expand the capacity of this cluster in order to keep providing a resilient and speedy service.
Expansion Strategy
Our expansion will happen using two parallel approaches:
Core Instance Expansion
The first will be to expand the capacity of the core sites by upgrading the routers and connecting them at 10 Gbit/s links. At the same time, we will replace the servers with newer ones with faster processors. We may also add more servers to some of the core instances, such as London. We are also looking at adding one more core site this year.
Hosted Instances
The second strategy involves co-operating with our community, as we do with K-root.
In 2017, we accepted an offer from Anexia IT to host an instance in Vienna. More recently in June 2020, we accepted a similar offer from NaMeX to host an instance in Rome. Both of these are now operational and helping to distribute the query load.
We are currently making internal preparations to accept more such applications. We will invite applications from anyone who can provide a single server and host it in their network or at an Internet exchange. We will install, configure and operate this server, and it will announce the AuthDNS cluster prefixes from ASN 197000. This approach spreads instances even more widely around the Internet, and lowers the DNS lookup latency even further. We are especially interested in hosting such instances in the Americas and Asia.
This second approach also has two further advantages. In cases of partial network outages, it can allow downstream clients of this server to continue resolving DNS queries for many important zones. Additionally, if there is a surge of queries, such as a distributed denial of service attack (DDoS), an instance like this can absorb the queries and limit the effects of such an attack.
More Information
As mentioned above, we'll be opening the application process for those who are interested in hosting an AuthDNS instance on their network soon. Expect more news on this in the near future. For now, further information on our AuthDNS service is available in the DNS section of our website. If you have specific questions, please feel free to leave a comment below, or contact us at dns@ripe.net.
Comments 0
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.