Compte rendu de lectures : CoDNS
Pour commencer, on va discuter performances du DNS.
Les problématiques de performances du DNS sont un sujet bien connu et bien documenté ([1], [2], [3] pour ne citer que 3 études (allez, disons [4])).
Je fais ici un focus sur [1] et la solution proposée au problème de performances du DNS, à savoir CoDNS ainsi que sur un ensemble d’articles/de billets/… qui parlent de solutions similaires.
Le DNS souffre de problèmes de performances constatés par les auteurs. Ils indiquent que bien que le temps de réponse soit acceptable dans la majorité des cas (de l’ordre de la centaine de millisecondes), on retrouve systématiquement de fortes latences sur certaines requêtes, avec des temps de réponse de l’ordre de la seconde voire de la dizaine de seconde pour les pires cas.
La principale cause identifiée par les auteurs est la perte du paquet DNS au niveau du serveur due à une surcharge de celui-ci. Ce problème est fréquent mais ne pose pas de problème dans la plupart des cas puisque les couches de transport incluent des mécanismes de rétablissement en cas d’erreur au niveau de la communication. Cependant les auteurs ont décidé de s’intéresser à la possibilité d’accélérer ces délais de réponses afin de prévenir de tels problèmes.
La solution CoDNS proposée par l’université de Princeton implémentée sur le CDN PlanetLab proposait de résoudre ce problème de lenteur en utilisant un modèle hybride.
Dans les cas les plus classiques les requêtes passent par le processus normal (petite image). Dans le cas où la réponse tarde (après un temps t=t0, t0_default = 200ms), le serveur interroge les caches de ses pairs afin de leur demander l’information (il construira si besoin un consensus dans le cas où les réponses diffèrent.
Les auteurs proposent d’exploiter la structure du CDN pour transmettre aisément une requête DNS à ses « plus proches voisins ». La sélection des plus proches voisins se fait en maintenant un pouls (heartbeat) entre les serveurs (quelques octets chaque seconde).
Le maintien du pouls peut sembler contraignant mais l’étude précise qu’il ne présente que peu de surcharge du réseau (32 octets par seconde soit 7.5 Mo par jour)
Le PoC démontre une capacité à résoudre les problèmes de timeout. Les auteurs ont également cherché à comparer leur solution au DNS classique (en réglant le délai t0 à 0). Leur solution promet des performances similaires (voire meilleures) en moyenne ainsi qu’une résolution des problèmes de timeout. L’étude n’est pas précise sur les conséquences au niveau de la surcharge des résolveurs dans un tel contexte mais la solution a l’intérêt de fonctionner et de montrer des performances remarquables.
Il faut cependant relativiser car celles-ci exploitent quand même une infrastructure que peu d’organismes peuvent déployer (c’était d’autant plus vrai en 2004 au moment où le système a été mis au point).
Il serait intéressant de comparer cette solution aux nouveaux résolveurs DNS, introduits ces dernières années par Google, Cloudflare ou Cloud9 mais la meilleure étude sur le sujet ne peut venir que de l’intérieur et peu de documents à ce sujet sont sortis à l’heure actuelle.
Le papier CoDNS est cité encore aujourd’hui dans le cadre de travaux sur les CDN comme [5] ou [6], pour n’en citer que parmis les plus récents. Et cela, bien que la solution CoDNS ne tourne plus aujourd’hui (le projet fonctionnait sur PlanetLab entre 2004 et 2012)
—-
Quelques sources :
[1] : CoDNS: Improving DNS Performance and Reliability via Cooperative Lookups; KyoungSoo Park, Vivek S. Pai, Larry Peterson and Zhe Wang
[2] : Proactive caching of DNS records: addressing a performance bottleneck, Edith Cohen, Haim Kaplan
[3] : DNS performance and the effectiveness of caching, Jaeyeon Jung, E. Sit, H. Balakrishnan, R. Morris
[4] : Statistics About DNS Root Name Service: Some Recommendations
[5] : OnionDNS: a seizure-resistant top-level domain; Nolen Scaife, Henry Carter, Lyrissa Lidsky, Rachael L. Jones, Patrick Traynor
[6] : LDplayer: DNS Experimentation at Scale, Liang Zhu, John Heidemann
J’ajouterai surement également en commentaires (ou à la suite) les documents qui m’ont été relayés sur le sujet à la suite de la publication de cet article