New .fr name server added, in Prague

First, some background

One of Afnic’s most mission-critical tasks is to ensure that names in the .fr domain can always be resolved, i.e. useful technical information can always be obtained for a given domain name. If I write  to jeanne.dupont@dila.gouv.fr, the email server I use will have to find my recipient’s server and this will occur through DNS resolution. Almost all of our online activities start with DNS resolution which is why this service is so critical, and has to be both robust and fast.

Resolution is performed by machines known as “authoritative DNS servers”¹. A domain such as .fr has several of these servers, to reduce the risk of failure. Failure of one of these servers does not interfere with name resolution. Moreover, each of these servers is comprised of a number of physical machines, distributed across various sites around the world. Consequently, the d.nic.fr server, one of the authoritative servers for .fr, is actually located in Paris, Lyon, Saint-Denis, New York, etc. The same IP address is used for all of these sites, a technique called anycast.

How do the machines that need to query this server know where to find it? Routing on the Internet works using a communication protocol named BGP (which stands for Border Gateway Protocol). BGP operates through announcements, whereby a router tells neighbouring routers “I can reach the IP addresses 2001:678:c::/48″ and this information is then propagated between adjoining routers in the same way. In the case of anycasting, more than one router worldwide will make the same announcement, and the other routers will choose the announcement closest to them. Machines in the United States will therefore favour the server that is in New York, those in Réunion the server in Saint-Denis, and so on.

That’s the theory. In practice, the Internet is a complex arena, with no centralised management, and each operator has control over their own routing policy. DNS requests do not therefore necessarily reach the closest machine, and one of the BGP engineer’s tasks is to look at traffic distribution and intervene to improve things, for example by adjusting the options allowed by BGP, or by adding new sites, as was done this January 9th.

Another question is that of finding out the destination site of our DNS request. Which machine (in the case of anycasting, an instance is the term used) was queried? Internet professionals reading this article will certainly be thinking of using the traceroute tool, but there is another option specific to DNS, namely NSID (Name Server IDentifier). This option, standardised in a document entitled RFC 5001, makes it possible to request that the server queried reveal its identity. Let’s use the dig program  to query d.nic.fr from my location in Paris, adding the NSID request (+nsid on the command line):

% dig @d.nic.fr +nsid fr SOA

…

;; OPT PSEUDOSECTION:

; NSID: 64 6e 73 2e 74 68 32 2e 6e 69 63 2e 66 72 ("dns.th2.nic.fr")

…

fr.    3600 IN SOA a.nic.fr. dnsmaster.afnic.fr. (

…

;; Query time: 8 msec

;; SERVER: 2001:678:c::1#53(d.nic.fr) (UDP)

The identity of this instance of d.nic.fr is dns.th2.nic.fr. Each DNS server operator chooses how to name their machines, and there are various naming conventions, which may not be immediately clear unless you work for the operator concerned. The significant information here is “th2”, which stands for “Telehouse 2” and indicates that this instance is located in the data centre bearing that name in Paris. It can therefore be seen that the routing here has produced the expected result, going to a nearby instance.

Let us return to our new site

It is located in a data centre in Prague, in the Czech Republic. It is connected to two Czech exchange points², NIX.CZ (Figure 1: The latest clients to arrive on the Czech exchange point’s website) and PEERING.CZ³. In the days preceding activation, the machine, a PC running a GNU/Linux operating system, was thoroughly tested, particularly to ensure it updated correctly when there were changes to .fr data (there are constantly new .fr subdomains and changes to existing subdomains). The server communicates with the router using BGP, only announcing IP addresses when the name server is operational⁴. On January 9th, the instance, having passed its tests satisfactorily, was put into service. A line in the router’s configuration file was added at 09:05 UTC to announce to the world (via the BGP protocol) the d.nic.fr IP addresses. Logically enough, DNS traffic immediately took off, rising from zero to 200 queries per second (Figure 2: Increase in DNS traffic when IPv6 addresses were announced).

The first domain requested on the instance was _.mosaic.fr. The underscore at the beginning of the name is the result of query minimisation (QNAME minimisation), a technique standardised within RFC 9156 to better protect privacy, which can be implemented in various ways. The addition of the underscore is a clue that the machine querying the server was probably using Knot, which is software widely used in the Czech Republic.

One hour later, IPv4 addresses were added, and traffic surged again, reaching 2,500 requests per second (Figure 3, DNS traffic broken down by IP version).

Seen by clients

The operator of an authoritative DNS server (Afnic in this case) can easily monitor their server’s activity. But to get the viewpoint of the clients, the machines that query d.nic.fr, we use RIPE Atlas probes. These are small devices that volunteers install more or less all over the world that can perform active measurements (DNS queries in this case) on demand⁵. These measurements can be created using the Atlas web interface or through their API (Application Programming Interface, a network programming interface). Here, we will use the Blaeu software to communicate with the API and launch measurements. We will start before activation of the instance:

% blaeu-resolve --requested 200 --country CZ --displayrtt \

    --nameserver 2001:678:c::1 --nsid --type SOA fr

Nameserver 2001:678:c::1

[TIMEOUT] : 2 occurrences Average RTT 0 ms

[NSID: b'dns.lyn.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430315 3600 1800 3600000 600] : 10 occurrences Average RTT 39 ms

[NSID: b'dns.fra.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430315 3600 1800 3600000 600] : 101 occurrences Average RTT 19 ms

[NSID: b'dns.th2.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430315 3600 1800 3600000 600] : 10 occurrences Average RTT 48 ms

Test #66028925 done at 2024-01-09T08:47:44Z

(You can also see the result of this measurement on the RIPE Atlas website.) Here, we requested 200 probes in the Czech Republic to query 2001:678:c::1 (which is the IP address of d.nic.fr) using the NSID option. It can be seen that the majority of the probes reached the dns.fra.nic.fr instance in Frankfurt-am-Main, at the major German exchange point, DE-CIX. This is entirely reasonable. However, some probes arrive in France, thereby illustrating Internet decentralisation in that each operator chooses their routing policy as they see fit, and that policy can sometimes be viewed as suboptimal, geographically speaking.

But the situation for IPv4 before the new instance was activated was not so good:

% blaeu-resolve --requested 200 --country CZ --displayrtt \

          --nameserver 194.0.9.1 \

          --nsid --type SOA frNameserver 194.0.9.1

[NSID: b'dns.fra.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430315 3600 1800 3600000 600] : 34 occurrences Average RTT 15 ms

[NSID: b'dns.nyc.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430315 3600 1800 3600000 600] : 77 occurrences Average RTT 93 ms

[NSID: b'dns.th2.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430315 3600 1800 3600000 600] : 81 occurrences Average RTT 29 ms

[TIMEOUT] : 6 occurrences Average RTT 0 ms

[a.nic.fr. dnsmaster.afnic.fr. 2237430315 3600 1800 3600000 600] : 1 occurrences Average RTT 20 ms

[NSID: b'dns.ams.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430315 3600 1800 3600000 600] : 1 occurrences Average RTT 15 ms

Test #66028870 done at 2024-01-09T08:45:46Z⁶

This time (this can also be seen on the Atlas website), a significant number of probes were querying dns.nyc.nic.fr, the New York instance⁷. The cause was that a major US operator was relaying BGP announcements seen in the US all the way to Prague. Problems of this kind, and the detrimental consequences they have on communication latency⁸, are not uncommon, but as will be seen, the new instance resolved the issue.

BGP announcements propagate within a few minutes⁹. It can be seen here that the majority of RIPE Atlas probes in the Czech Republic (82 probes) began using dns.prg.nic.fr, the Prague instance, once the new site was announced:

% blaeu-resolve --requested 200 --country CZ --displayrtt \

        --nameserver 2001:678:c::1 --nsid --type SOA fr

Nameserver 2001:678:c::1

[TIMEOUT] : 2 occurrences Average RTT 0 ms

[NSID: b'dns.lyn.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430555 3600 1800 3600000 600] : 8 occurrences Average RTT 44 ms

[NSID: b'dns.prg.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430555 3600 1800 3600000 600] : 82 occurrences Average RTT 11 ms

[NSID: b'dns.th2.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430555 3600 1800 3600000 600] : 6 occurrences Average RTT 43 ms

[NSID: b'dns.fra.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430555 3600 1800 3600000 600] : 23 occurrences Average RTT 26 ms

Test #66030063 done at 2024-01-09T09:42:13Z

Mission accomplished, then, the new instance serves (see the RIPE Atlas website), latency decreases, and the same is true for IPv4:

% blaeu-resolve --requested 200 --country CZ --displayrtt \

      --nameserver 194.0.9.1 --nsid --type SOA fr

Nameserver 194.0.9.1

[NSID: b'dns.fra.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430721 3600 1800 3600000 600] : 32 occurrences Average RTT 19 ms

[NSID: b'dns.prg.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430721 3600 1800 3600000 600] : 112 occurrences Average RTT 8 ms

[NSID: b'dns.th2.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430721 3600 1800 3600000 600] : 35 occurrences Average RTT 30 ms

[TIMEOUT] : 5 occurrences Average RTT 0 ms

[NSID: b'dns.nyc.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430721 3600 1800 3600000 600] : 7 occurrences Average RTT 92 ms

[a.nic.fr. dnsmaster.afnic.fr. 2237430721 3600 1800 3600000 600] : 1 occurrences Average RTT 14 ms

Test #66031615 done at 2024-01-09T10:32:05Z

The New York instance is now little-used (see on the Atlas website), which was one of the operation’s goals.

Since the public Internet’s BGP activity is public, the operation can be viewed with services such as RIPE Stat. Here, it is clear that the activations have resulted in an increase in BGP activity, with routers adjusting their preferences upon receiving the new announcement, and transmitting it to their neighbouring routers (Figure 4, BGP activity, where the two successive activations (IPv4 and IPv6) can be clearly seen).

The new instance serves not only Czech residents. RIPE Atlas probes show that neighbouring countries, such as Slovakia, will also benefit from dns.prg.nic.fr:

% blaeu-resolve --requested 200 --country SK --displayrtt --nameserver 194.0.9.1 --nsid --type SOA fr

Nameserver 194.0.9.1

[NSID: b'dns.fra.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430668 3600 1800 3600000 600] : 12 occurrences Average RTT 18 ms

[NSID: b'dns.prg.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430668 3600 1800 3600000 600] : 20 occurrences Average RTT 12 ms

[NSID: b'dns.mrs.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430668 3600 1800 3600000 600] : 3 occurrences Average RTT 39 ms

[NSID: b'dns.nyc.nic.fr' a.nic.fr. dnsmaster.afnic.fr. 2237430668 3600 1800 3600000 600] : 5 occurrences Average RTT 94 ms

[a.nic.fr. dnsmaster.afnic.fr. 2237430648 3600 1800 3600000 600] : 1 occurrences Average RTT 10 ms

[a.nic.fr. dnsmaster.afnic.fr. 2237430668 3600 1800 3600000 600] : 1 occurrences Average RTT 13 ms

Test #66030863 done at 2024-01-09T10:12:48Z

Conclusion

I hope this article has shown you that, as with any complex infrastructure, there needs to be people who take care of it, and that keeping infrastructure in working order and at optimum performance is an ongoing job.

^{1 – There is another category of DNS servers, called resolvers, but they will not be discussed here.}

^{2 – An exchange point is a neutral place where Internet players connect with each other.}

^{3 – As well as two transit operators, to be able to respond to all customers, and for the connection with Afnic in France.}

^{4 – The software used for this is FRRouting.}

^{5 – In addition to ad-hoc observations as here, Afnic uses these probes to continuously monitor performance of the DNS servers for the .fr domain, and uses these third-party measurements as the basis for its reports to the French government.}

^{7 – Installed, it should be noted, in a former biscuit factory, where a famous cookie is said to have been invented.}

^{8 – Latency is the time taken to go from one point to another, here measured in milliseconds. In this case, the RTT (round-trip time) is displayed instead. Latency and RTT are crucial parameters in performance as perceived by the user, even if the media and advertising generally only talk about capacity (in megabits or gigabits per second). The two Prague server connections operate at 10 gigabits per second.}

^{9 – DNS experts will note that, while the BGP announcement spreads very quickly, actual DNS traffic, not that of the RIPE Atlas measurements, does not follow as swiftly. DNS clients, the resolvers, remember which is the fastest server and always query that one. It takes some time before they re-test and discover that d.nic.fr is now the fastest server and always query that one. It takes some time before they re-test and discover that d.nic.fr is now the fastest.}