Résilience

de serveurs racine DNS.

Le premier changement technique s’est manifesté par l’ajout de bureaux d’enregistrement concurrents et avec le système de registres DNS partagés. Le DNS Internet original n’avait que 13 serveurs racine pour tout l’Internet ; ces 13 serveurs pointaient directement vers les serveurs délégués pour chaque domaine enregistré. Le nombre de serveurs racine a été fixé à 13 par la conception de l’enregistrement de requête DNS ; il n’a de la place que pour 13 adresses IP dans une réponse de requête racine.

Quand les registres multiples sont apparus, on a ajouté une autre couche de serveurs racine : une couche prévue pour un maximum de 13 pour chaque TLD (voir l’encadré « Principe de fonctionnement de DNS »,). Cela sollicitait davantage chaque requête DNS, mais cette charge de travail était répartie sur des centaines de serveurs racine. Le deuxième changement a consisté à disperser la première couche des serveurs de noms racine dans le monde entier, plutôt que de les concentrer tous aux Etats-Unis. C’est ainsi qu’il existe maintenant des serveurs racine de première couche à Beijing, Hong Kong, Madrid, Moscou, Prague, Rome et Séoul, pour ne citer que les principaux. L’objectif est l’existence de plusieurs copies de la base de données de noms racine, afin qu’Internet puisse continuer à fonctionner même si une catastrophe venait à le fragmenter.

Un troisième changement a consisté à appliquer aux requêtes DNS ciblant des serveurs de noms racine de première couche, un traitement spécial sur Internet. Comme le format d’enregistrement DNS n’a pas changé, la limite de 13 adresses IP reste en vigueur. En quelque sorte, ces 13 adresses IP doivent satisfaire les quelques centaines de serveurs de noms racine. A cet effet, il a fallu prendre la décision (non officielle) de transgresser l’une des principales règles de IP (Internet Protocol) : celle qui stipule que chaque adresse IP est unique.

La règle continue à s’appliquer sur la plus grande partie d’Internet, mais dans le cas des serveurs de noms racine, de nombreux serveurs utilisent la même adresse IP selon un schéma appelé anycast. Avec anycast, tous les serveurs racine communiquent leurs adresses à Internet en utilisant le protocole BGP (Border Gateway Protocol). Normalement, ces annonces dupliquées poseraient un problème, car les utilisateurs finaux pourraient être acheminés d’abord vers un serveur puis vers un autre, au hasard. Mais, comme chacun des serveurs contient les mêmes données et comme chaque session DNS est constituée d’un paquet UDP unique et d’une réponse UDP unique, peu importe quel serveur répond en définitive à une requête racine donnée. C’est juste le résultat déplaisant et non prévu du comportement actuel d’Internet.

Un quatrième changement technique a réduit spectaculairement le temps nécessaire pour protéger les changements des serveurs de noms racine et d’enregistrements DNS. Dans l’ancien DNS, le changement du serveur DNS délégué pouvait se propager pendant plusieurs jours. Les requêtes étaient traitées à certains intervalles de temps, et si l’on ratait la coupure pour un jour particulier, le changement était ralenti pendant plusieurs heures. Il fallait attendre d’abord qu’une mise à jour se produise dans le registre puis dans les serveurs de noms racine et, finalement, la propagation vers tous les serveurs DNS d’utilisateurs finaux. Aujourd’hui, pratiquement tous les changements d’enregistrements mettent à jour le registre immédiatement et les changements de serveurs de noms racine se propagent en une heure ou moins. Le seul facteur temps qui doit continuer à vous préoccuper désormais est la valeur TTL, directement sous votre contrôle. Avant d’effectuer une modification d’enregistrement ressource DNS, donnez un intervalle plus court à TTL – par exemple, 10 minutes – et vos révisions remplaceront l’information mise en cache, dans ce laps de temps. Simplement, n’oubliez pas de remettre le TTL à sa valeur originale, une heure environ après la mise à jour.

L’infrastructure DNS a reçu un dernier changement visant à la renforcer contre une attaque délibérée. Le réseau DNS original ne prêtait aucune intention malveillante aux auteurs de requêtes. Mais plusieurs défaillances partielles de DNS ont fait les gros titres et mis en lumière la nécessité de protéger les serveurs de noms racine des attaques par déni de service (DoS) et autres. Aucune attaque n’a jamais immobilisé DNS complètement, et avant que l’une d’elles ne réussisse, les administrateurs des serveurs de noms racine ont renforcé les pare-feu et autres protections pour atténuer les effets d’un assaut. La meilleure redondance des serveurs racine accentue la résilience et les serveurs racine emploient une variété de moteurs logiciels pour traiter les requêtes DNS. On réduit ainsi la probabilité de voir un seul défaut entraîner l’effondrement total de l’infrastructure DNS.