Le DNS utilise traditionnellement surtout
UDP comme protocole de
transport. TCP est
parfaitement légal mais, en pratique, il a été cantonné aux transferts
de zone et à quelques requêtes où la réponse était trop grosse pour
passer en UDP. La montée des attaques utilisant le DNS avec
réflexion et amplification a
changé les choses et de plus en plus de gens se demandent si le DNS ne
va pas utiliser TCP plus fréquemment.
Écartons d'abord un mythe encore propagé par certains ignorants :
non, le DNS n'utilise pas que
UDP. Outre les transferts de zone (cf. ), le DNS utilise TCP dès que la réponse est
de taille trop importante pour être transmise en UDP. C'est combien
d'octets, « trop importante » ? Cela dépend. Autrefois, il y avait une
limite en dur à 512 octets. Elle a été remplacée depuis longtemps par
l'extension EDNS (aujourd'hui décrite par le
) qui permet d'indiquer la taille des
réponses qu'on peut recevoir. Le serveur répondeur ayant également sa propre
limite, la taille maximale pratique est le minimum de la taille
annoncée que le demandeur et de la taille configurée dans le serveur
répondeur. Pour la plupart des logiciels DNS, ces deux tailles valent
par défaut 4 096 octets, mais peuvent être modifiées. Vous verrez
ainsi que les serveurs de noms de
.com ont une limite
configurée à 1 460 octets. Même si le demandeur propose d'avantage
(8 192 octets dans l'exemple suivant), le serveur enverra une réponse
tronquée (bit TC mis à un) et le demandeur réessaiera alors en
TCP. Voyons avec dig :
dig a automatiquement réessayé en TCP. Si on lui dit de ne pas le
faire :
Le tc dans la réponse indique qu'elle a été
tronquée (regardez le compteur ANSWER et la
taille de la réponse).
Cette possibilité de se rabattre en TCP est cruciale si la réponse
est de trop grande taille (ce qui est plus fréquent aujourd'hui, avec
IPv6, les IDN et surtout
DNSSEC). C'est pour cela qu'il est essentiel de
s'assurer que la configuration du réseau permette les requêtes et les
réponses TCP, comme exigé par le . C'est
aussi pour cela que l'outil Zonecheck a, par défaut, une
politique de tests qui impose que le serveur réponde en TCP. (Un point
qui a toujours fait l'objet d'un consensus
chez les experts à chaque discussion.)
Au fait, pourquoi le serveur a t-il une limite de taille en UDP et
pas en TCP ? Car, en UDP, on n'a aucun moyen de garantir la véracité
de l'adresse IP source utilisée. Cela permet
des attaques par réflexion + amplification, qui ne sont pas possibles
en TCP. Limiter la taille des réponses, comme le fait
.com, limite donc les dégâts.
OK, bon, on a le droit d'utiliser TCP si on veut. Si un employé ou
un consultant en sécurité dit qu'il faut débrayer / bloquer TCP, on
sait qu'on peut muter l'employé et virer le consultant, ils ne
connaissent pas leur métier. Mais le fait qu'on
puisse utiliser TCP veut-il dire qu'il le
faut ? Notons qu'un client DNS peut toujours
utiliser TCP dès le début, sans attendre une réponse tronquée :
Mais quels sont les problèmes si tous les clients DNS faisaient
ainsi ? Il y en a deux : bien des réseaux bloquent stupidement les
requêtes DNS TCP (cf. le cas du consultant en sécurité incompétent,
ainsi que les excellents tests TCP de Zonecheck, cités plus
haut). Ensuite, UDP est bien plus léger pour le serveur. Il peut être
mis en œuvre sans état (notez que ce n'est pas toujours fait ainsi sur
les systèmes modernes) et la même machine peut donc servir bien plus
de requêtes par seconde en UDP.
Au dernier atelier OARC
à Dublin, le 12 mai, deux excellents exposés
étaient revenus sur cette question. Celui de
Francis Dupont présentait le problème des performances TCP, les
réglages souhaitables sur les serveurs et les clients (ceux par défaut conviennent rarement) et les
résultats de ses mesures (après réglages, 30 kr/s en TCP sur une
machine qui en fait 130 kr/s en UDP). Cela indique que TCP reste plus
lent (ce qui est logique) mais que l'écart est peut-être supportable
(le DNS va de toute façon nécessiter des investissements, entre autre
en raison des attaques par réflexion). Et des optimisations sont
possibles, comme de laisser les connexions TCP ouvertes (c'est
l'établissement de la connexion TCP qui est coûteux, et on peut faire
passer plusieurs requêtes DNS sur une seule connexion).
Autre exposé très intéressant, celui d'Ed
Lewis, exposé très provoquant sur la sécurité du DNS, le genre
d'exposé qui remet tout à plat et où personne n'est d'accord à 100 %
mais qui disait plein de choses justes, comme le fait que nous serons
probablement amenés à dépendre de plus en plus de TCP dans le futur.
Et mon opinion ? Je pense qu'en effet, les défauts d'UDP (notamment
en cas d'attaques par réflexion) deviendront de plus en plus
insupportables avec le temps et que les problèmes de performance de
TCP doivent être relativisés : aujourd'hui, avec l'expérience des
serveurs HTTP, faire des serveurs qui
encaissent des dizaines de milliers de connexion par seconde n'est
plus de la magie noire... Experts TCP, il y aura donc peut-être
bientôt du travail pour vous dans le monde DNS.
Vous pouvez aussi lire une
bonne étude sur TCP pour le DNS, un exemple de ce qui se passe si on
bloque TCP et l'exposé de Huston sur le
pourcentage de résolveurs DNS qui savent faire du TCP.