Choose the nearest nodes in the network

Network latencies have a significant impact on the performance of applications or services that interact with the network. The less latency, the higher the performance. This is true for any network service, starting from a regular site and ending with a database or network storage.

A good example is the domain name system (DNS). DNS is inherently a distributed system, the root nodes of which are scattered throughout the planet. To just go to any site, you first need to get its IP address.

I will not describe the whole process of recursive passage through the “tree” of domain zones, but I will limit myself to the fact that to convert a domain into an IP address we need a DNS resolver that will do all this work for us.

So where to get the resolver DNS address?

1. The ISP provides the address of its DNS resolver.
2. Find the address of a public resolver on the Internet.
3. Raise your own or use the built-in router in your home.

Any of these options will allow you to enjoy carefree surfing on the World Wide Web, but if you have a need to convert a large number of domains to IP, then the choice of resolver should be approached more carefully.

As I already wrote, in addition to the resolver of the Internet provider, there are many public addresses, for example, you can find this list here. Some of them may be much more preferable because they have better network connectivity than the default resolver.

When the list is small, you can easily “ping” it with your hands and compare the time of delays, but if you even take the list mentioned above, this activity will become unpleasant.

Therefore, to facilitate this task, I, full of impostor syndrome, sketched a proof-of-concept of my idea on the Go called get-closer .

As an example, I will not check the entire list of resolvers, but restrict myself to the most popular ones.

$ get-closer ping -f dnsresolver.txt -b=0 --count=10
Closest hosts:
	1.0.0.1 [3.4582ms]
	8.8.8.8 [6.7545ms]
	1.1.1.1 [12.6773ms]
	8.8.4.4 [16.6361ms]
	9.9.9.9 [40.0525ms]

At one time, when I chose a resolver for myself, I limited myself to checking the main addresses (1.1.1.1, 8.8.8.8, 9.9.9.9), because they are so beautiful, and what to expect from reserve ugly addresses.

But since there was an automated way to compare delays, why not expand the list ...

As the test showed, the “backup” Cloudflare address suits me better, since it is stuck in spb-ix, which is much closer to me than msk-ix, which stuck in beautiful 1.1.1.1

The difference, as you can see, is significant, because even the fastest ray of light does not manage to run from St. Petersburg to Moscow in less than 10 ms.

In addition to simple ping, PoC also has the ability to compare delays using other protocols, such as http and tcp, as well as the time it takes to convert domains to IP through a specific resolver.

The plans have the task of comparing the number of nodes between hosts using traceroute, so that it is easier to find hosts to which there is a shorter path.

The code is raw, there aren’t enough heaps of checks, but it works reasonably well on clean data. I would be grateful for any feedback, stars on the github , and if anyone liked the idea of ​​the project, then wellcome to the contributors.