Kaveh Ranjbar

RIPE NCC Technical Services 2017 - Part Two: Focus on DNS

Kaveh Ranjbar
0 You have liked this article 0 times.

This is the second part of the technical services update. In this article we're focusing on our DNS services: providing reverse DNS; providing secondary services for ccTLDs; and maintaining K-root.

The RIPE NCC is responsible for the operation of K-root, one of the thirteen root name servers. This is perhaps the best known of the RIPE NCC's DNS related services. In addition to this, though, we also provide secondary services for country code Top Level Domains (ccTLDs), develop various DNS related tools, and provide reverse DNS for the IP address space for which we are responsible. 

General DNS Services

First and foremost, we operate a few zones that are required for the day to day operations of the RIPE NCC; for example ripe.net, and a few other domains. The DNS service for ripe.net and the other associated zones is provided via anycasted servers in three European locations run by the RIPE NCC. In addition, our zones are traditionally served by secondary DNS service from our fellow RIRs. During 2016 we have selected, through a public and open RFP process, a DNS service provider with DDoS mitigation capabilities to further strengthen the service capacity for our DNS zones.

We already had a well-provisioned DNS service for ripe.net, but that said, during the past years, we have seen an increase in the occurrence of large-scale attacks to our DNS infrastructure. Such incidents are expected to increase. Since we have a number of high-availability services running under our domain - including RIPE Whois, the LIR Portal and RPKI Repository services, as well as some important informational services like RIPEstat, RIPE Atlas and the RIPE document store - we considered it prudent to ensure very high resilience levels for the ripe.net zone.


Secondary Services to ccTLDs

We traditionally provide secondary DNS service from our own DNS infrastructure for certain ccTLD zone owners. This is an important service that has helped many ccTLD operators start their services and provide stability and resilience during their initial phase of operations.

One of our initiatives was to clarify and re-organise the service that we provide to these ccTLD operators. We worked with the community to establish a set of clear eligibility criteria for receiving these services from RIPE NCC. This was clarified and documented as RIPE document 663.

Based on the criteria provided by ripe-663, we have started reviewing our current arrangements with ccTLDs and their eligibility under the new guidelines. We found that a significant number (31) of ccTLDs  are no longer eligible and we are working with the relevant zone owners to move to alternative service providers. So far, eighteen ccTLDs have moved away to alternative service providers and the others are preparing to do so. We are also taking this opportunity to renew existing contracts with all ccTLDs who are in a position to continue using our service. We will implement a process to regularly monitor ccTLDs against the eligibility criteria, in order to be pro-active in our communication with remaining ccTLD operators.

Reverse DNS Services

At the RIPE NCC, we also operate the authoritative servers for the reverse zones for resources within RIPE NCC service region. This is a complex service in nature, as delegating the authority to the resource holder might involve more than one RIR and can also involve allowing the resource holder to define their authoritative name servers directly.

The process of requesting reverse delegation has historically been quite elaborate and error prone. We have recently simplified the delegation process for end-users quite significantly by creating a wizard in the LIR portal to allow easy creation and modification of DOMAIN objects for reverse delegation. More information about the wizard can be found here.

It is worth mentioning that we had a hiccup in the provisioning of reverse zones. Although this affected a limited number of users (a relatively small subset of the whole reverse zone we are in charge of), it highlighted multiple issues with the current provisioning system. In Reverse DNS Outage for Out-of-Region Address Space, we published our post-mortem analysis of the issue and have initiated work with other RIRs to improve the overall system behind the scenes. We will publish our improvement plans and further inform the community along the way.

Operating K-root

During the RIPE NCC Services Working Group meeting at RIPE 70, we announced our plans for a new model for hosting and further expanding the K-Root infrastructure. In the background article, New Architecture Model for K-root Local Instances, we explained that under this new model we have two type of instances:

  • Core nodes, which are purchased and fully owned by the RIPE NCC
  • Hosted nodes, for which the hardware is provided by parties interested in hosting a K-root node

Core nodes consist of several servers and a physical router in a single location. Hosted nodes consist of a single server contributed by the local hosts for the node. Both types of nodes are fully controlled by the same RIPE NCC operational team.

We have since then executed this plan and added K-root local nodes at a steady pace of one or a few each month, as hardware was proposed and contributed by several tens of new local K-root hosts. Currently we have 45 K-root hosted nodes and the expansion program is still continuing as we continue to welcome new hosts every month.

Figure 1: Location of the K-root instances

Current Situation

In both scenarios, the RIPE NCC remains the sole entity in charge of running and managing the node and we make sure we have full control over the system and announcement of the K-root prefixes to the host network. On core nodes, we manage all of the peering relationships ourselves. The local host of a hosted node decides on further propagation of the K-root prefixes, but as part of the process of bringing up a new hosted node, we work closely with each new host to fine-tune the propagation of the K-root prefix to balance the new node's reach with its network and service capability.

Where we are Going?

Over the past years, we've seen a steady increase in traffic load due to normal DNS queries on our servers. However, we have seen a much stronger increase in (occasional) traffic peaks of spurious packets. As the traffic we observe (including eventual  large scale attack traffic) continues to grow, we are expanding capacity further. We do this partly by adding more K-root hosted nodes, which also brings a much more fine-grained distribution of K-root capacity and thus more compartmentalisation of eventual attack traffic. But separately, we also expand capacity on our core nodes directly. Recently, we have started upgrading all our core-nodes' uplink ports to 10GE; a process that we plan to conclude before the end of the year. 

Figure 2: K-root query load from 28 April to 4 May 2017

With the hosted nodes, we are aiming for geographical diversity within the RIPE NCC service region as well as globally. Thanks to the enthusiastic participation of many organisations in our region we have been adding nodes in many previously underserved areas in, for example, the Middle East and the CIS region. By collaborating closely with other RIRs we are also able to reach underserved countries in other regions. The cooperation with the other RIRs is looking very promising and in this way we expect to be able to reach more underserved areas in other regions in the coming period.

We are also evaluating some other expansion possibilities. For example, we are looking into the feasibility of working together with large and global network operators - with all the potential benefits and possible drawbacks of deploying K-root nodes in such an environment. As usual, we will keep you posted with regards to any findings and possible developments in this area.


To sum up, here at the RIPE NCC, we continue to make every effort to ensure that we provide effective support for all our DNS related services whilst also working to make improvements wherever we can. Since our last round of technical updates, we’ve made important modifications to the K-root architecture, developed and applied clear eligibility criteria for our ccTLD services and taken various steps to strengthen service capacity for our DNS zones as well as our Root DNS services. In all of this, ongoing collaboration with other RIRs has been, and will continue to be, essential, particularly as we look to develop better strategies for enhanced resilience.

In order to stay up to date on all the latest developments, be sure to follow RIPE Labs. Coming up, the third and final installment of our technical services articles will delve into details on a variety of tools offered by the RIPE NCC, such as RIPEstat, RIS, DNSMON and OpenIPMap.


0 You have liked this article 0 times.

You may also like

View more

About the author

Kaveh Ranjbar Based in Amsterdam

As Chief Information Officer at the RIPE NCC, I am mainly involved with the planning, operation and development of the RIPE NCC's global information services as well as research and development. This includes the RIPE NCC's authoritative DNS services as well as K-root infrastructure, data collection and measurement networks such as RIPE Atlas and RIS, data provisioning systems such as RIPEstat, and the RIPE NCC's data analysis efforts. I have been with the RIPE NCC since 2008 working in different capacities. Before the RIPE NCC, I worked for more than 12 years in the Internet services and ISP sectors, mostly in senior technical management positions. I was the engineering founder of one of the largest Iranian ISPs and helped several IT startups with their software and business process implementations. I have a M.Sc. in Software Engineering from the University of Oxford, UK and Lean Engineering/Agile Management training at MIT.

Comments 0