Résolveurs DNS FAI vs. local : Quid des performances ?

Un vieux (faux) débat

La justice a recémment étendu le blocage du site t411.io. Comme d'habitude, la méthode choisie par les FAI concernés par ce jugement (les sempiternels Free, Orange, Bouygues Télécom et Numéricable/SFR - les autres FAI, qu'ils soient associatifs, réservés aux entreprises ou uniquement trop petits, passant à travers les mailles du filet) est celle du DNS menteur. Les utilisateurs de ces services se verront donc redirigé vers le localhost de leur machine en lieu et place du site demandé.

Une nouvelle fois suite à ce genre de décisions, après les topics de forums et les tweets exortant à passer sur les résolveurs public de Google ou d'OpenDNS, est apparue la question d'utiliser son propre résolveur hébergé avec amour sur sa propre machine. Un des corrolaires habituel de cette question est celle des performances : accéder à mes vidéos de chatons sera-t-il plus lent ou plus rapide ? La question n'est pas si simple à trancher. D'un côté, un cache distant alimenté par les requêtes de milliers d'utilisateur et de l'autre une machine avec un cache initialement vide, regénéré uniquement par les requêtes au mieux de quelques utilisateurs si le résolveur est utilisé par toutes les machines connectées au routeur du réseau local (ce qui est mon cas). En face, beaucoup de sites web, notamment ceux ayant un fort trafic, utilisant des TTL très court sur leur domaine (600s pour google.com, 30 (!) pour twitter.com...). Dans ce genre de cas, le résolveur d'un FAI aura bien plus de chances d'avoir la réponse en cache comparé un serveur auto-hébergé mais on perd bien sûr l'avantage du serveur maison qui est de fournir une réponse en moins de 5ms si la réponse est connue.

Mais trèves de péroraisons. Qu'en est-il dans la pratique ? Pour répondre à cette question j'ai donc mesuré ce qu'il en était en utilisant les DNS de mon FAI (OVH Télécom pour ne pas le citer) et en utilisant le résolveur installé sur mon Raspberry Pi 2. Les tests se sont déroulés sur 2 après-midi - un par test - aux même heures, sur des durées différentes mais sur un nombre de requêtes identique (1008 et 1007 pour être précis). Mon résolveur maison est un Unbound doté d'une configuration très proche de celles fournies dans ce tutoriel (notamment le cache-min-ttl à 3600 - pour contrer en partie le problème des TTL trop court, et tant pis si Twitter devient inaccessible pour 59min59s au lieu de 29s - et le prefetch activé). La capture est faite depuis mon PC sous Ubuntu grâce à Wireshark et son filtre dns.time. Ce dernier mesure le temps entre la dernière occurence d'une requête et l'arrivée de la réponse. Ce test n'est donc pas réalisable sous Windows car si la réponse d'une requête ne lui parvient pas au bout d'une seconde il l'a renvoie et les résultats sont donc faussés puisque dns.time mesurera le temps entre cette deuxième occurence et l'arrivée de la réponse. Si vous souhaitez réaliser ce test mais que vous êtes sous Windows, installez donc une VM sous un vrai OS. Le trafic DNS généré est quasiment entièrement du à de la navigation Web.

A noter que le test est réalisé de manière pratique : il s'agit de requêtes issues de 2 séances de navigation web différentes sur à peu près les mêmes sites. J'aurai pu enregistrer les requêtes issues de la première séance de test et les rejouer sur mon résolveur local, mais cela complique un peu la tâche pour des résultats qui auraient été identiques à ceux que j'ai obtenus.

Résultats

Nous constatons qu'en moyenne les réponses sont 2 fois plus lentes à parvenir. Nous remarquons par ailleurs le même ratio sur le temps total d'attente des réponses. Les temps médians sont en revanches peu ou prou équivalents grâce au 48% de requêtes qui tapent dans le cache. Ce nombre peut paraître élevé mais on constate que Firefox semble passer son temps à demander l'IP des sites pour lesquels il a un onglet ouvert (il faudrait d'ailleurs vérifier si ce comportement est général ou bien uniquement lié à certains sites abusant de l'auto-refresh). Cela génère donc des requêtes supplémentaires mais lui permet d'être à peu près sûr d'avoir la bonne IP lorsque l'utilisateur revient sur l'onglet et continue sa navigation dans le site. A noter que ma ligne ADSL est dans un piteux état (réponse au ping mesuré par mon FAI très fluctuante et pertes de synchro récurrentes par exemple) et qu'il serait intéressant de faire le test sur une ligne de meilleure qualité - typiquement sur de la fibre optique. Autre point ayant pu jouer en ma défaveur : DNSSEC. En effet, mon résolveur valide les réponses, celui de mon FAI non. Même si DNSSEC est encore (malheureusement) peu déployé, il serait intéressant de mesurer son impact sur les temps de réponse.

Et au final ?

Au final, je pourrais parfaitement rester sur les résolveurs de mon FAI. Ce dernier étant petit dans le domaine de la fourniture d'accès Internet (chaque abonnement reçoit une adresse IPv4, or seul un préfixe /16 est aujourd'hui annoncé. OVH Télécom à donc au maximum 65536 abonnés), il passe donc sous le radar des décisions de justice (leur résolveur me donne les bonnes IP pour t411 ou The Pirate Bay par exemple) et la censure administrative (nulle Main Rouge observée). Ceci dit, cela sera-t-il toujours le cas ? D'autre part, l'absence de validation DNSSEC m'irrite, ce qui est un argument supplémentaire pour utiliser mon propre résolveur. Et tant pis si ma vidéo de chatons met 200ms de plus à s'afficher.