Choosing the nearest nodes in the network

Choosing the nearest nodes in the network

Network latency significantly impacts the performance of applications or services that interact with the network. The lower the latency, the higher the performance. This is true for any network service, from a simple website to a database or network storage.

A good example is the Domain Name System (DNS). DNS is inherently a distributed system, with root nodes scattered across the globe. To simply visit any site, you first need to obtain its IP address.

I won't describe the entire process of recursively navigating the 'tree' of domain zones but will limit myself to stating that converting a domain to an IP address requires a DNS resolver, which will do all the work for us.

So, where can you find a DNS resolver address?

  1. Your Internet Service Provider provides the address of its DNS resolver.
  2. Find the address of a public resolver on the internet.
  3. Set up your own or use the one built into your home router.

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 IPs, you should choose a resolver more carefully.

As I mentioned, in addition to the ISP's resolver, there are many public addresses available, for instance, you can refer to this list. Some of them may prove to be much more preferable due to better network connectivity than the 'default' resolver.

When the list is small, you can easily manually 'ping' it and compare latency times, but if you consider even the list mentioned above, this task becomes unpleasant.

To simplify this task, I, filled with imposter syndrome, sketched out a proof-of-concept for my idea in Go called get-closer.

As an example, I will not check the entire list of resolvers, but will limit 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 was choosing a resolver for myself, I limited my checks to just the main addresses (1.1.1.1, 8.8.8.8, 9.9.9.9) — after all, they look so appealing, and what can you expect from backup addresses that aren't pretty.

But since an automated way to compare latencies has appeared, why not expand the list…

As the test showed, the 'backup' address from Cloudflare suits me better, as it is connected to spb-ix, which is much closer to me than msk-ix, where the pretty 1.1.1.1 is connected.

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

In addition to simple pings, the PoC also allows comparing latencies across other protocols such as HTTP and TCP, as well as the time it takes to convert domain names to IPs through a specific resolver.

There is a task planned 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 raw, lacking a ton of checks, but it works reasonably well on clean data. I would appreciate any feedback, stars on GitHub, and if anyone likes the idea of the project, welcome to contribute.

Source: habr.com

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster