Follow the DNS

What made me remember that? This year we experienced something similar while strengthening the DNS infrastructure for the .CZ domain. But let’s start from the beginning. After significant upgrades of the anycast for the .CZ domain in previous years (see for example this article), when we put into operation two DNS nodes, each with a capacity of 100 Gbps to NIX.CZ and the corresponding performance of the involved DNS stacks, we promised to change the subsequent procedure. Namely, to focus in the future on strengthening our DNS anycast in the undermaintained points with high traffic and high latency of DNS traffic. In order to be able to select such locations well, we have started to use DNS traffic analyses created thanks to the ADAM project and also the outputs of the master’s thesis of my colleague Lukáš which, addres the issue.

Simply put, using the real DNS traffic of the entire .CZ zone, we can calculate where it will be advantageous to build another DNS node so that a large part of the traffic is rerouted there and help significantly reduce communication time of the DNS resolver with our authoritative server, i.e. the above-mentioned latency. Lukáš described the method in more detail in his presentation at IT 20. In the spring of 2020, his analyses revealed that it would be appropriate to handle DNS traffic of the .CZ zone originating in the South, Southeast and East Asia region by connecting a DNS node to the SGIX peering node in Singapore, and that the dismantled node in the western United States should be replaced by an installation in Seattle and its connection to the local SIX.

To finish my story about the Sun, in the summer we solved the worsened availability of one of the four CZ DNS anycasts from the Czech Republic by installing a DNS node in Bratislava and connecting it to NIX.SK and NIX.CZ. It so happened that around one or two in the morning we could start arranging the connection of servers in Singapore, our normal working hours were “filled with Bratislava” and then closed the circle with Seattle in the evening. Of course, it’s a kind of exaggeration, but it’s hard not to respond to an e-mail when you know that postponing the answer until tomorrow means an entire day of delay. All the more so because arranging the purchase, delivery, installation and connection of servers remotely is, to put it mildly, complicated.

That would be all for my blogpost; I explained how we “Followed the Sun and DNS” in the summer and fall. But decent stories are supposed to have a good ending, and since I have one for mine, why not dish it out. The picture below shows the change in the situation with the availability of our .CZ anycast DNS between 14 days in October 2019 and 4 days in November 2020. We realize that this is a relatively inaccurate view, because the periods differ in length, but already these first data show that the weighted RTT (Round-Trip-Time – time required for mutual communication of the recursive and authoritative servers) has been significantly reduced both in SE Asia (and Asia in general) and in Europe. RTT did not change significantly in the US, which was the desired result, because last October, instead of a DNS node in Seattle, we had a node in Redwood City, California, i.e. also on the West Coast. Yes, RTT in Micronesia worsened year-on-year, but given the size of the local DNS traffic on the .CZ domain, this is an acceptable loss. The thing is, in addition to reducing RTT, we evaluate the costs incurred for all installations.

And for a better demonstration, I will list all DNS nodes that we have added or upgraded this year. In my article, I omitted part of the work for a smoother transition to “Following the Sun”. In all cases, these are installations of physical servers, and as can shown in the table, they are all different. Yes, we really care about diversity in DNS.