Selecting the nearest nodes in the network

Network delays have a significant impact on the performance of applications or services that interact with the network. The lower the delay, the better the performance. This is true for any network service, from a regular website to a database or network storage.

A good example is the Domain Name System (DNS). The DNS is, by its very nature, a distributed system with root nodes scattered all over the planet. To simply visit any site, you first need to get its IP address.

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

So, where do you get the resolver's 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 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 ISP resolver, there are many public addresses, for example, you can check out this list. 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 by hand and compare the delay times, but if you even take the list mentioned above, then this activity already becomes unpleasant.

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

As an example, I will not check the entire list of resolvers, but will limit myself to only 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 only 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 ugly backup addresses.

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

As the test showed, Cloudflare’s “backup” address is more suitable for me, since it is plugged into spb-ix, which is much closer to me than msk-ix, into which beautiful 1.1.1.1 is plugged

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

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

The plan is to compare the number of nodes between hosts using traceroute to make it easier to find hosts that have a shorter path.

The code is crude, there are not enough checks, but it works quite tolerably on clean data. I would appreciate any feedback, stars on githabe, and if anyone liked the idea of ​​the project, then welcome to the contributors.

Source: habr.com