On sait que le DNS est un des services d'infrastructure les
plus essentiels de l'Internet. Il est, par
exemple, crucial que les serveurs DNS faisant
autorité soient correctement gérés, et robustes face aux
problèmes qui peuvent survenir. Ce RFC donne un certain nombre de conseils (juste
des conseils, il ne s'agit pas d'une norme) aux opérateurs de ces
serveurs.
Il n'est pas obligatoire de suivre ces conseils mais il faut
noter qu'ils sont tous fondés sur des articles publiés dans des
revues techniques avec examen par les pairs. Donc, c'est quand même
sérieux, même si ce RFC n'a pas le statut de norme. Le RFC vise
surtout les « gros » serveurs faisant autorité, par exemple les
serveurs de TLD importants. Ces serveurs sont typiquement
anycastés ( et ). Si le vôtre est
unicast et ne sert qu'à trois visiteurs de temps
en temps, vous n'êtes pas forcément concerné·e.
Au passage, cette distinction entre serveurs faisant autorité
et résolveurs est cruciale dès
qu'on parle du DNS. La section 2 du RFC commence d'ailleurs par
un rappel de cette distinction. D'autre part, cette même section
insiste sur l'importance du DNS pour le vécu de l'utilisatrice. Par
exemple la latence perçue par celle-ci
dépend en bonne partie du DNS. Voici un exemple :
% curl-timing https://www.nic.af/
DNS: 0,920891 s
TCP connect: 1,124164 s
TLS connect: 1,455578 s
Start transfer: 1,598288 s
Total: 1,735741 s
On voit que la résolution DNS a pris plus de la moitié du temps
total. (La commande curl-timing est définie par
alias curl-timing='curl --silent --output /dev/null
--write-out "DNS: %{time_namelookup} s\nTCP connect: %{time_connect}
s\nTLS connect: %{time_appconnect} s\nStart transfer:
%{time_starttransfer} s\nTotal: %{time_total} s\n"'.) Sur
ce sujet de la latence, voir aussi l'article « The
Internet at the Speed of Light ». La latence dépend
en grande partie de la distance géographique, et la réduire impose
donc une présence mondiale.
Et ces performances, et cette robustesse sont menacées, entre
autres, par les nombreuses attaques par déni de
service qui visent le DNS, comme celle décrite dans
l'article « Anycast vs.
DDoS: Evaluating the November 2015 Root DNS
Event ».
La section 3 est le cœur du RFC, contenant les recommandations,
numérotées de C1 à C6. Commençons par C1, le conseil de n'avoir que
des serveurs
anycast. L'anycast
est indispensable pour répartir très largement les serveurs,
assurant la performance et la robustesse de la résolution DNS. Bien
sûr, on peut se contenter d'avoir plusieurs enregistrements
NS mais cela ne suffit pas : diverses raisons
font qu'on ne peut pas avoir des centaines d'enregistrements dans un
ensemble NS, alors que certains nuages anycast
atteignent cette taille. Donc, avoir plusieurs enregistrements NS
est nécessaire mais cela ne dispense pas de
l'anycast.
C'est d'autant plus vrai que, parmi les enregistrements NS, la
sélection de celui utilisé est faite par le résolveur. Les
résolveurs corrects mesurent la latence et choisissent le serveur
faisant autorité le plus rapide. Mais il y a d'autres résolveurs qui
n'utilisent pas de bons algorithmes de sélection
(cf. « Recursives
in the Wild: Engineering Authoritative DNS
Servers »). Avec l'anycast, la
sélection de l'instance utilisée est faite par le réseau, via
BGP, et peut
donc être meilleure. Du fait de ces résolveurs sous-performants, un
opérateur a donc intérêt à ce que tous les serveurs faisant autorité
soient anycastés. S'il y a un « maillon faible »,
unicast et mal connecté, il sera quand même
consulté par certains résolveurs, et dégradera donc la latence dans
certains cas. Par exemple, le TLD.nl est passé en tout
anycast en 2018.
Maintenant, C2, le conseil de travailler son
routage. Une fois qu'on a décidé de mettre de
l'anycast partout, il reste à
optimiser. BGP
ne garantit pas du tout, contrairement à ce qu'on lit parfois, que
la route la plus rapide sera choisie. BGP fait ce que les
administrateurs réseau lui demandent de faire. On voit régulièrement
des traceroute qui montrent qu'on ne va pas à
l'instance anycast la plus proche. Certains
opérateurs DNS compensent en ajoutant davantage d'instances mais
l'article « Anycast
Latency: How Many Sites Are Enough? » montre, en
testant des serveurs de la racine depuis des
sondes RIPE Atlas, que le
nombre d'instances compte moins que le soin apporté au routage. (On
ne parle ici que de performances ; pour la résistance aux attaques
par déni de service, le nombre d'instances reste essentiel.) Ici, le
temps de réponse des serveurs faisant autorité pour
.fr, depuis une machine
en France (il y a une instance proche pour chaque serveur) :
% check-soa -i fr
d.nic.fr.
2001:678:c::1: OK: 2230506452 (4 ms)
194.0.9.1: OK: 2230506452 (0 ms)
e.ext.nic.fr.
193.176.144.22: OK: 2230506434 (15 ms)
2a00:d78:0:102:193:176:144:22: OK: 2230506434 (15 ms)
f.ext.nic.fr.
194.146.106.46: OK: 2230506434 (6 ms)
2001:67c:1010:11::53: OK: 2230506452 (11 ms)
g.ext.nic.fr.
2001:678:4c::1: OK: 2230506434 (2 ms)
194.0.36.1: OK: 2230506434 (2 ms)
Le conseil C3 porte sur un concept très important lorsqu'on fait
de l'anycast, celui de bassin d'attraction. Ce
terme désigne l'ensemble des réseaux qui vont envoyer leurs paquets
vers une instance donnée. Si toutes les instances ont à peu près les
mêmes capacités de traitement des requêtes, on souhaite en général
placer les instances et configurer BGP de manière à ce que toutes les
instances reçoivent à peu près la même quantité de requêtes. Mais en
pratique c'est rarement le cas : le réseau est une chose
compliquée. Il existe des méthodes pour améliorer les choses
(cf. l'article « Broad and
Load-Aware Anycast Mapping with Verfploeter », qui
décrit l'outil Verfploeter)
mais ce n'est jamais parfait. Au moins, un outil comme Verfploeter
permet de procéder plus scientifiquement qu'au pifomètre, et d'avoir
une idée de ce que produiront des changements de configuration BGP
pour faire du traffic engineering (par exemple,
allonger le chemin d'AS dans les annonces, pour diminuer le trafic
d'une instance).
Le conseil C4, quant à lui, porte sur les attaques par
déni de service (comme celle décrite dans
« Anycast vs.
DDoS: Evaluating the November 2015 Root DNS
Event ») et sur le comportement des serveurs soumis
à un stress intense. Que peut faire l'opérateur lorsque
Mirai ou un de ses semblables attaque ?
Essayer de diminuer le trafic entrant, soit en faisant du
traffic engineering BGP pour envoyer le trafic
vers une autre instance, si certaines ont davantage de capacité, ou
bien ne sont pas attaquées, voire, si on n'a pas de réserves, en
arrêtant complètement d'annoncer les routes (ce qui arrête le
service - ce qui était le but de l'attaquant - mais cela peut être
nécessaire s'il y a d'autres services au même endroit et qu'on
veut les épargner),Ou bien encaisser en silence, sachant qu'on perdra des
requêtes et qu'on ne pourra pas répondre à tout. Si l'attaque ne
frappait que certaines instances, cela peut permettre d'épargner
les instances non attaquées.
Le conseil C4 est donc d'avoir des plans prêts à l'avance,
permettant de prendre une décision en cas de crise, et de l'appliquer.
Et les TTL ? Ils ne
sont pas oubliés. La mémorisation des réponses, pendant une durée
maximale égale au TTL, est un point essentiel du DNS, et un facteur
de performance crucial. Même si un serveur faisant autorité répond
souvent en moins de 50 ms, la réponse de la mémoire d'un résolveur,
qui peut arriver en 1 ms, sera encore préférable. Ce rôle a été
largement étudié (voir par exemple « Modeling
TTL- based Internet Caches » ou, plus récemment,
« When the Dike
Breaks: Dissecting DNS Defenses During DDoS »). Une
étude des conséquences du choix du TTL sur les performances est la
base du conseil C5, l'étude « Cache
Me If You Can: Effects of DNS Time-to- Live ». Elle
montre que :
Des TTL plus longs diminuent le temps de réponse (puisque
les données sont conservées plus longtemps dans la mémoire des
résolveurs), cf. par exemple l'expérience faite sur
.uy citée dans
l'article ci-dessus,Ces TTL plus longs diminuent le trafic DNS, pour la même
raison, (logiquement, les gens qui s'inquiètent de l'empreinte
environnementale du numérique devraient mettre des TTL longs sur
leurs domaines),Et ils améliorent la robustesse face aux attaques par déni
de service (même si tous les serveurs faisant autorité ont du mal
à répondre, les résolveurs pourront continuer à servir les
données),D'un autre côté, et comme il n'existe pas de solution
parfaite, juste des choix et des compromis, des TTL plus longs
empêchent de changer rapidement sa configuration ; si le
changement était planifié, ce n'est pas grave (on abaisse le TTL
avant le changement et on le remonte après), mais si on veut le
faire en urgence, c'est plus gênant,C'est d'autant plus gênant que certains services d'atténuation
des attaques par déni de service fonctionnent en utilisant le DNS
pour envoyer le trafic vers l'atténuateur ; des TTL longs limitent
cette possibilité (et la planification ne change rien dans ce cas,
puisque les attaquants ne se signalent pas forcément à
l'avance),Même problème avec la répartition de
charge utilisant le DNS.
Bref, on ne peut pas faire une recommandation quantitative
appliquable à tous les cas. Le conseil C5 est donc plus complexe :
Pour un domaine ordinaire, des TTL d'au moins une heure, et
de préférence d'au moins huit heures sont recommandés,Pour les gros registres (par exemple
registres de TLD), la plupart des résolveurs utiliseront de
toute façon les TTL indiqués dans la zone fille ; pour le bien des
autres résolveurs, le RFC recommande un TTL d'au moins une
heure,Pour les zones « terminales » qui utilisent des répartiteurs
de charge ou des services d'atténuation d'attaques qui reposent sur
le DNS, on peut se contenter de TTL de 5 minutes, mais le RFC
recommande quand même au moins 15 minutes.
Et si les TTL entre la zone parente et la zone fille diffèrent ?
La question se pose typiquement pour les enregistrements
NS. Par exemple, les enregistrements NS dans la zone
racine ont un TTL de 48 heures, alors que dans les zones des TLD,
l'ensemble NS a presque toujours un TTL plus faible (une heure pour
.cl, par exemple). Selon
que le résolveur est parent-centric (une
minorité) ou child-centric (la grande majorité),
il utilisera le TTL de la zone parente ou bien celui de la zone
fille. Le conseil C6 : on ne peut pas compter que le TTL qu'on a mis
soit respecté partout, si l'enregistrement existe aussi dans la zone
parente avec des TTL différents. Attention donc lorsqu'on veut
changer quelque chose, à intégrer le TTL de la zone parente.
Un bon résumé en anglais de ce RFC a été écrit
par un des auteurs. Il inclut un récit de la création du RFC
et du processus suivi.