Remote K-root node in Selectk

The increase in the number of Internet users in developing countries entails the need to develop appropriate infrastructure, including DNS servers.



Over the past few years, the geography of root DNS servers has been significantly expanded. Not so long ago, working root server nodes were mainly concentrated in Europe and the USA, but today they appear in the countries of Asia, Africa, and South America. This year, one of the K-Root server nodes was installed even in Iran , from which Western sanctions have not yet been completely lifted.

')

The question of expanding the root DNS system is also relevant for Russia. We were able to make a definite contribution to his decision: in August of this year we had one of the nodes of the root K-Root DNS server. In this article we will tell about its architecture and participation in the competition for its placement.

Root DNS Servers: A Brief Reference

As you know, the DNS system is used on the Internet to provide communication between domain names and IP addresses. The highest level of the DNS hierarchy is occupied by root servers. They contain information about all top-level domains (TLDs). This information indicates which authoritative NS servers need to send a subsequent request to recursively resolve the domain name.



DNS was created in the 1980s. From this time until 2000, the root DNS server system consisted of a primary server (first called ns.internic.net, but later renamed to a.root-servers.net) and its replicas, later named after Letters of the Latin alphabet: b.root-servers.net, c.root-servers.net and so on - to m.root-servers.net. Each of the thirteen root servers is managed by a separate operator.



Since the beginning of the 2000s, Anycast technology has been used in the root server system. This contributed to a significant expansion of its geography and increase the level of reliability. Around each root server is a system of serving nodes located around the world.



The operator of the K-root server system is the non-profit organization RIPE NCC . Let's take a closer look at how the K-root system works from an architectural point of view.

K-root system architecture

In the spring of this year, the K-root system switched to a new, modernized architecture. To better understand the essence of all the recent changes, let us briefly consider how everything was arranged before.



In the old architecture, all K-root nodes were divided into two types: core (core nodes) - powerful DNS servers with a separate system of routers and switches and local (local nodes). The structure of each local node included the following elements:

• a router that announced the k.root network to participants of a traffic exchange point;
• two NS servers for processing requests;
• switch.

Graphically, this scheme can be represented as follows:





In the new architecture, the concept of “local node” is absent altogether. Instead, it uses the concept of a “remote node” (hosted node).

Remote nodes are based on Dell servers. There is no network equipment in the remote nodes.

Servers on which specialized software is installed set up a BGP session with the routers of the hosting provider and announce K.Root prefixes on behalf of AS25152. Thanks to Anycast technology , the difference between main and remote nodes is essentially leveled.







Ansible ( presentation of the RIPE NCC engineer ) is used for configuration management, which allows you to speed up and automate software deployment processes. BIND , NSD and Knot are used as working software.



You can find out which server is installed on your nearest k.root site using the dig utility:

$ dig @k.root-servers.net version.bind chaos txt +short "Knot DNS 1.6.4" $ dig @k.root-servers.net version.bind chaos txt +short "NSD 4.1.3" 

Exabgp is used to announce prefixes.

Technical requirements for local nodes

For servers acting as local K-root nodes, the RIPE NCC has the following requirements:

• Dell Power Edge 2xx family model (preferably R320 or R420);
• at least 16 GB of RAM;
• multi-core processor;
• at least 2 Ethernet ports with a total bandwidth of 2 GB / s;
• RAID controller PERC H310
• two SATA-drives with a capacity of 500 GB each;
• availability of an integrated remote access controller iDRAC 7 Enterprise;
• the server has two power supplies;
• IP address allocation (both IPv4 and IPv6).

The potential hoster must provide the RIPE NCC server with the characteristics described above. In our case, we installed an additional power supply for connecting the server to different power inputs.

K-root hosting: how it happened with us

The DNS root server system is constantly expanding. Organizations that control root servers periodically announce a competition for new servicing nodes. Any telecom operator whose technical infrastructure meets the requirements set by the operator can take part.



We learned about plans to expand the K-root system in April 2015. Among the candidates for the location of new K-root system sites, a competition was held, during which the technical and organizational capabilities of potential hosts were evaluated. An important selection criterion for this competition is the presence of good connectivity. Only good connectivity can be a guarantee that a new server will be able to serve a large number of clients.



We issued all the necessary documents, and soon our candidacy was approved.



After that, we ordered a server that meets the requirements of the RIPE NCC, and by August it was installed in one of our data centers.



Placing the K-root node is a completely non-commercial project. Before installing the server, we signed a protocol of mutual understanding with the RIPE NCC (a sample in English can be found here ), which explicitly states that both parties are interested in improving the connectivity of the DNS system - and not a word about the monetary component.



The K-root Hosting Agreement is perpetual. Both we and the RIPE NCC are interested in developing partnerships.

What does it give us

What advantages does participation in this non-commercial project give us?



The only obvious advantage is the notorious plus in karma: we made a small, but still a contribution to the development of the DNS system and to increasing its resiliency.



We hope that in the future we will be able to take part in other large-scale Internet development projects.