Ajout d’un nouveau serveur de noms de .fr, à Prague

Un peu de contexte pour commencer

Une des tâches les plus critiques de l’Afnic est de s’assurer qu’on puisse en permanence résoudre les noms sous .fr, résoudre, c’est-à-dire obtenir des informations techniques utiles pour un nom de domaine donné. Si j’écris à jeanne.dupont@dila.gouv.fr, le serveur de messagerie que j’utilise devra trouver le serveur de ma correspondante et cela se fera via une résolution DNS. Quasiment toutes nos activités en ligne commencent par une résolution DNS et c’est pourquoi ce service est si critique, et doit être robuste et rapide.

La résolution se fait via des machines nommées « serveurs DNS faisant autorité¹ ». Un domaine comme .fr a plusieurs de ces serveurs, pour diminuer le risque de panne. L’arrêt d’un de ces serveurs ne gêne pas la résolution de noms. En outre, chacun de ces serveurs est composé de plusieurs machines physiques, réparties sur plusieurs sites dans le monde. Le serveur d.nic.fr, un des serveurs faisant autorité pour .fr, est ainsi à Paris, à Lyon, à Saint-Denis, à New-York, etc. Sur chacun de ces sites, la même adresse IP est utilisée, une technique qui est nommée anycast.

Comment est-ce que les machines qui ont besoin d’interroger ce serveur savent où le joindre ? Le routage dans l’Internet est assuré par un protocole de communication nommé BGP (pour Border Gateway Protocol). BGP fonctionne par des annonces où un routeur dit à ses voisins « je sais joindre les adresses IP 2001:678:c::/48 » et cette information se propage ensuite de proche en proche. Dans le cas de l’anycast, plusieurs routeurs dans le monde vont clamer la même information et les autres routeurs vont choisir l’annonce la plus proche d’eux. Les machines aux États-Unis vont donc privilégier le serveur qui est à New-York, celles qui sont à la Réunion celui de Saint-Denis, etc.

Ça, c’est la théorie. En pratique, l’Internet est un monde complexe, sans direction centralisée et chaque opérateur est maitre de sa politique de routage. Les requêtes DNS n’arrivent donc pas forcément à la machine la plus proche et une des tâches de l’ingénieure BGP est de regarder la répartition du trafic et d’intervenir pour améliorer les choses, par exemple en ajustant les options permises par BGP, ou bien en ajoutant de nouveaux sites, comme cela a été fait ce 9 janvier.

D’ailleurs, comment savoir à quel site est allé notre requête DNS ? Quelle machine (dans le cas de l’anycast, on dit une instance) a été interrogée ? Les professionnelles de l’Internet, à la lecture de cet article, ont certainement pensé à utiliser l’outil traceroute mais il existe une autre possibilité, spécifique au DNS, le NSID (Name Server IDentifier). Cette option, normalisée dans un document nommé RFC 5001, permet de demander au serveur interrogé de dévoiler son identité, s’il le veut bien. Utilisons le programme dig pour interroger d.nic.fr depuis chez moi à Paris, en rajoutant la demande NSID (+nsid sur la ligne de commande) :

% 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)

L’identité de cette instance de d.nic.fr est dns.th2.nic.fr. Chaque opérateur de serveurs DNS choisit comment nommer ses machines et on trouve des schémas de nommage variés, et qui ne sont pas forcément évidents si on ne travaille pas pour l’opérateur en question. Ici, l’information importante est le « th2 », qui veut dire « Telehouse 2 » et qui indique que cette instance se trouve dans le centre de données de ce nom, à Paris. On voit donc que le routage, ici, a produit le résultat prévu, je vais à une instance proche.

Retournons sur notre nouveau site

Il est situé dans un centre de données à Prague, en République Tchèque. Il est connecté à deux points d’échange² tchèques, NIX.CZ (Figure 1, Sur le site Web du point d’échange tchèque, les derniers clients arrivés) et PEERING.CZ³. Dans les jours qui précèdent l’activation, la machine, un PC avec un système d’exploitation de la famille GNU/Linux, a été soigneusement testée, pour vérifier notamment qu’elle se mettait bien à jour lors d’un changement des données de .fr (il y a en permanence de nouveaux sous-domaines de .fr, et des changements dans ceux qui existent). Le serveur parle BGP au routeur, pour n’annoncer les adresses IP que lorsque le serveur de noms est opérationnel⁴. Le 9 janvier, l’instance, dont les tests étaient satisfaisants, a été mise en service. Une ligne dans le fichier de configuration du routeur a été ajoutée à 09h05 UTC pour annoncer au monde (via le protocole BGP) les adresses IP de d.nic.fr. Le trafic DNS a, logiquement, tout de suite décollé, passant de zéro à 200 requêtes par seconde (Figure 2, Augmentation du trafic DNS lorsque les adresses IPv6 ont été annoncées).

Sur l’instance, le premier domaine demandé a été _.mosaic.fr. Le tiret bas au début du nom est le résultat de la minimisation des requêtes (QNAME minimisation), une technique normalisée dans le RFC 9156 pour mieux protéger la vie privée, et qui peut être mise en œuvre de diverses façons. L’ajout du tiret bas indique sans doute que la machine qui interrogeait le serveur utilisait le logiciel Knot, très répandu en République Tchèque.

Une heure après, les adresses IPv4 ont été ajoutées, et le trafic bondit à nouveau, atteignant 2 500 requêtes par seconde (Figure 3, Le trafic DNS, réparti par version d’IP).

Vu par les clients

L’opérateur d’un serveur DNS faisant autorité (ici, l’Afnic), peut regarder l’activité de son serveur facilement. Mais pour avoir le point de vue des clients, des machines qui interrogent d.nic.fr, nous utilisons les sondes RIPE Atlas. Ce sont des petits boitiers que des volontaires installent un peu partout dans le monde et qui peuvent effectuer des mesures actives (ici, des requêtes DNS) à la demande⁵. On peut créer ces mesures via l’interface Web d’Atlas ou bien via leur API (Application Programming Interface, interface de programmation réseau). Ici, on va utiliser le logiciel Blaeu pour parler à l’API et lancer des mesures. Commençons avant l’activation de l’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

(Vous pouvez aussi voir le résultat de cette mesure sur le site Web de RIPE Atlas.) Ici, on a demandé 200 sondes en République Tchèque, pour qu’elles interrogent  2001:678:c::1 (c’est l’adresse IP de d.nic.fr) avec l’option NSID. On voit que la majorité des sondes sont tombées sur l’instance dns.fra.nic.fr, située à Francfort-sur-le-Main, au grand point d’échange allemand, le DE-CIX. C’est tout à fait raisonnable. Mais quelques sondes arrivent en France, illustration de la décentralisation de l’Internet : chaque opérateur choisissant librement sa politique de routage, ce dernier peut être parfois considéré comme non-optimal d’un point de vue géographique.

Mais la situation avant l’activation de la nouvelle instance était moins bonne pour IPv4 :

% 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⁶

Cette fois (vous pouvez aussi regarder le site Web d’Atlas), une bonne partie des sondes allaient interroger dns.nyc.nic.fr, l’instance de New-York⁷. C’était dû au fait qu’un opérateur étatsunien important relayait les annonces BGP vues dans son pays jusqu’à Prague. Ce genre de problèmes, et les conséquences néfastes qui en résultent pour la latence des communications⁸ n’est pas rare mais on va voir qu’il a été résolu par la nouvelle instance.

Les annonces BGP se propagent en quelques minutes⁹. On voit ici que la majorité des sondes RIPE Atlas en République Tchèque (82 sondes) se sont mises à utiliser dns.prg.nic.fr, l’instance de Prague, une fois le nouveau site annoncé :

% 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 accomplie, donc, la nouvelle instance sert (cf. le site Web de RIPE Atlas), la latence diminue, et même chose en 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

L’instance de New-York est désormais peu utilisée (voir sur le site Web d’Atlas), ce qui était un des buts de l’opération.

L’activité BGP de l’Internet public étant publique, on peut visualiser l’opération avec des services comme RIPE Stat. Ici, on voit bien que les activations se sont traduites par un surcroit d’activité BGP, les routeurs réajustant leurs préférences en recevant la nouvelle annonce, et en la transmettant à leurs voisin (Figure 4, L’activité BGP, où les deux activations successives (IPv4 et IPv6) sont bien marquées).

La nouvelle instance ne sert pas qu’aux Tchèques. Les sondes RIPE Atlas montrent que des pays voisins, comme la Slovaquie, vont également profiter de 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

J’espère que cet article vous aura montré que, comme pour toute infrastructure complexe, il faut des gens qui s’en occupent et que maintenir une infrastructure en état de marche et aux performances optimales est un travail permanent.

^{1 – Il existe une autre catégorie de serveurs DNS, les résolveurs, mais nous n’en parlons pas ici.}

^{2 – Un point d’échange est un lieu neutre où les acteurs de l’Internet se connectent entre eux.}

^{3 – Ainsi qu’à deux opérateurs de transit, pour pouvoir répondre à tous les clients, et pour la liaison avec l’Afnic en France.}

^{4 – Le logiciel utilisé pour cela est FRRouting.}

^{5 – Outre des observations ponctuelles comme ici, l’Afnic utilise ces sondes pour superviser en permanence les performances des serveurs DNS de .fr, et utilise ces mesures d’une tierce partie comme base de ses rapports au gouvernement.}

^{6 – Une sonde ne voit pas de NSID du tout dans la réponse. C’est probablement dû à un équipement réseau qui détourne automatiquement le trafic DNS vers un serveur de leur choix.}

^{7 – Installée, on le notera, dans une ancienne usine de biscuits, où un célèbre cookie aurait été inventé.}

^{8 -La latence est le temps mis pour aller d’un point à un autre, mesurée ici en milli-secondes. Ici, on affiche plutôt le RTT (Round-Trip Time), le temps d’aller-retour. La latence et le RTT sont des paramètres cruciaux pour les performances perçues par l’utilisateur, même si les médias et les annonces commerciales ne parlent en général que de la capacité (en mégabits ou gigabits par seconde). Les deux connexions du serveur de Prague sont à 10 gigabits par seconde.}

^{9 – Les experts DNS noteront que, si l’annonce BGP se propage très rapidement, le trafic DNS réel, pas celui des mesures RIPE Atlas, ne suit pas aussi vite. Les clients DNS, les résolveurs, gardent en mémoire le serveur le plus rapide et l’interrogent systématiquement. Ils mettent un certain temps à re-tester et à découvrir que d.nic.fr est désormais le plus rapide.}