La latence du système de noms de domaine (DNS) est un élément clé pour avoir une bonne expérience en ligne. Et pour minimiser la latence DNS, choisir soigneusement les serveurs DNS et les relais d’anonymisation joue un rôle important.
Mais la meilleure façon de minimiser la latence est d’éviter d’envoyer des requêtes inutiles pour commencer. C’est pourquoi le DNS a été conçu, dès le premier jour, pour être un protocole fortement cachable. Les enregistrements individuels ont une durée de vie (TTL), définie à l’origine par les administrateurs de zone, et les résolveurs utilisent ces informations pour conserver ces enregistrements en mémoire afin d’éviter le trafic inutile.
La mise en cache est-elle efficace ? Une étude rapide que j’ai faite il y a quelques années a montré qu’il y avait place à l’amélioration. Aujourd’hui, je veux jeter un nouveau regard sur la situation actuelle.
Pour ce faire, j’ai patché un serveur DNS crypté pour stocker le TTL d’origine d’une réponse, défini comme le TTL minimum de ses enregistrements, pour chaque requête entrante. Cela nous donne un bon aperçu de la distribution TTL du trafic réel, mais explique également la popularité des requêtes individuelles.
Cette version corrigée a été laissée à fonctionner pendant quelques heures. L’ensemble de données résultant est composé de 1 583 579 tuples (nom, qtype, TTL, horodatage). Voici la distribution TTL globale (l’axe X est le TTL en secondes) :
Outre une bosse négligeable à 86 400 (principalement pour les enregistrements SOA), il est assez évident que les TTL sont dans la gamme basse. Zoomons:
D’accord, les TTL supérieurs à 1 heure sont statistiquement insignifiants. Concentrons–nous sur la plage 0-3 600:
Et où la plupart des TTL se situent entre 0 et 15 minutes:
La grande majorité est comprise entre 0 et 5 minutes:
Ce n’est pas génial. La répartition cumulative peut rendre le problème encore plus évident:
La moitié d’Internet a un TTL de 1 minute ou moins, et les trois quarts ont un TTL de 5 minutes ou moins.
Mais attendez, c’est en fait pire. Ce sont des TTL tels que définis par des serveurs faisant autorité. Cependant, les TTL récupérés à partir de résolveurs clients (par exemple, les routeurs, les caches locaux) obtiennent un TTL que les résolveurs en amont décrémentent toutes les secondes. Ainsi, en moyenne, la durée réelle qu’un client peut utiliser une entrée mise en cache avant d’exiger une nouvelle requête est la moitié du TTL d’origine.
Peut-être que ces TTL très faibles n’affectent que les requêtes rares, et non les sites Web et les API populaires. Jetons un coup d’œil:
Malheureusement, les requêtes les plus populaires sont également les plus inutiles à mettre en cache. Zoomons:
Verdict: c’est vraiment mauvais, ou plutôt c’était déjà mauvais, et ça a empiré. La mise en cache DNS est devenue presque inutile. Avec moins de personnes utilisant le résolveur DNS de leur FAI (pour de bonnes raisons), la latence accrue devient plus perceptible. La mise en cache DNS n’est devenue utile que pour le contenu que personne ne visite. Notez également que les logiciels peuvent interpréter différemment les TTL faibles.
Pourquoi?
Pourquoi les enregistrements DNS sont-ils définis avec des TTL aussi faibles ?
- Les équilibreurs de charge hérités sont laissés avec les paramètres par défaut.
- La légende urbaine selon laquelle l’équilibrage de charge basé sur DNS dépend de TTL (ce n’est pas le cas).
- Les administrateurs souhaitent que leurs modifications soient appliquées immédiatement, car cela peut nécessiter moins de travail de planification.
- En tant qu’administrateur DNS ou d’équilibreur de charge, votre devoir est de déployer efficacement la configuration demandée par les utilisateurs, pas de rendre les sites Web et les services rapides.
- Les TTL faibles donnent la tranquillité d’esprit.
Je n’inclus pas ‘pour le basculement’ dans cette liste, car cela est devenu de moins en moins pertinent. Si l’intention est de rediriger les utilisateurs vers un autre réseau uniquement pour afficher une page de baleine défaillante alors qu’absolument tout le reste est en feu, un délai de plus d’une minute est probablement acceptable.
Les CDN et les équilibreurs de charge sont largement à blâmer, en particulier lorsqu’ils combinent des enregistrements CNAME avec des TTL courts avec des enregistrements ayant également des TTL courts (mais indépendants) :
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
Une nouvelle requête doit être envoyée chaque fois que le CNAME ou l’un des enregistrements A expire. Ils ont tous deux un TTL de 30 secondes mais ne sont pas en phase. Le TTL moyen réel sera de 15 secondes.
Mais attendez! C’est pire. Certains résolveurs se comportent assez mal dans une telle situation de bas-TTL-CNAME + bas-TTL-records :
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
C’est le résolveur de Level3, qui, je pense, exécute BIND. Si vous continuez à envoyer cette requête, le TTL retourné sera toujours 1. Essentiellement, raw.githubusercontent.com ne sera jamais mis en cache.
Voici un autre exemple de situation d’enregistrements à faible TTL -CNAME + à faible TTL, avec un nom très populaire:
$ drill detectportal.firefox.com @1.1.1.1detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net.detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net.detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net.a1089.dscd.akamai.net. 10 IN A 104.123.50.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Pas moins de trois enregistrements CNAME. Ouch. L’un d’eux a un TTL décent, mais c’est totalement inutile. Les autres CNAMEs ont un TTL d’origine de 60 secondes ; le akamai.net les noms ont un TTL maximum de 20 secondes et rien de tout cela n’est en phase.
Que diriez-vous de celui que vos appareils Apple interrogent constamment?
$ drill 1-courier.push.apple.com @4.2.2.21-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net.1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net.gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
La même configuration que Firefox et le TTL est collé à 1 la plupart du temps lors de l’utilisation du résolveur de Level3.
Qu’en est-il de Dropbox ?
$ drill client.dropbox.com @8.8.8.8client.dropbox.com. 7 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 59 IN A 162.125.67.3$ drill client.dropbox.com @4.2.2.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com a un TTL de 60 secondes. Les noms Facebook ont un TTL de 60 secondes. Et, encore une fois, du point de vue du client, ces valeurs devraient être réduites de moitié.
Que diriez-vous de définir un TTL minimum?
En utilisant le nom, le type de requête, le TTL et l’horodatage initialement stockés, j’ai écrit un script qui simule les plus de 1,5 million de requêtes passant par un résolveur de mise en cache pour estimer le nombre de requêtes envoyées en raison d’une entrée de cache expirée. 47,4 % des requêtes ont été effectuées après l’expiration d’une entrée existante mise en cache. C’est excessivement élevé.
Quel serait l’impact sur la mise en cache si un TTL minimum était défini ?
L’axe X est le TTL minimum qui a été défini. Les enregistrements dont le TTL d’origine était supérieur à cette valeur n’ont pas été affectés. L’axe Y est le pourcentage de requêtes effectuées par un client qui avait déjà une entrée en cache, mais une nouvelle requête a été effectuée et l’entrée en cache a expiré.
Le nombre de requêtes passe de 47% à 36% simplement en définissant un TTL minimum de 5 minutes. La définition d’un TTL minimum de 15 minutes fait chuter le nombre de requêtes requises à 29%. Un TTL minimum de 1 heure le fait tomber à 17%. C’est une différence significative!
Que diriez-vous de ne rien changer côté serveur, mais de faire en sorte que les caches DNS clients (routeurs, résolveurs locaux et caches instead) définissent un TTL minimum à la place ?
Le nombre de requêtes requises passe de 47% à 34% en définissant un TTL minimum de 5 minutes, à 25% avec un minimum de 15 minutes et à 13% avec un minimum de 1 heure. 40 minutes peut-être un bon endroit. L’impact de ce changement minimal est énorme.
Quelles en sont les implications ?
Bien entendu, un service peut basculer vers un nouveau fournisseur de cloud, un nouveau serveur, un nouveau réseau, obligeant les clients à utiliser des enregistrements DNS à jour. Et avoir des TTL raisonnablement faibles aide à rendre la transition sans friction. Cependant, personne ne s’attend à ce que les clients utilisent les nouveaux enregistrements DNS en 1 minute, 5 minutes ou 15 minutes.
Définir un TTL minimum de 40 minutes au lieu de 5 minutes n’empêchera pas les utilisateurs d’accéder au service. Cependant, cela réduira considérablement la latence et améliorera la confidentialité (plus de requêtes = plus d’opportunités de suivi) et la fiabilité en évitant les requêtes inutiles.
Bien sûr, les RFC disent que les TTL doivent être strictement respectés. Mais la réalité est que le DNS est devenu inefficace.
Si vous utilisez des serveurs DNS faisant autorité, veuillez revoir vos TTL. Avez-vous vraiment besoin que ceux-ci soient ridiculement bas?
Lire: Comment choisir les valeurs TTL DNS
Bien sûr, il existe des raisons valables d’utiliser des TTL DNS faibles. Mais pas pour 75% d’Internet pour servir du contenu qui est pour la plupart immuable, mais inutile à mettre en cache. Et si, pour une raison quelconque, vous devez vraiment utiliser des TTL DNS faibles, assurez-vous également que le cache ne fonctionne pas non plus sur votre site Web. Pour les mêmes raisons.
Si vous utilisez un cache DNS local tel que dnscrypt-proxy qui permet de définir des TTL minimaux, utilisez cette fonctionnalité. C’est bon. Rien de mal ne se passera. Réglez ce TTL minimum à quelque chose entre 40 minutes (2400 secondes) et 1 heure; c’est une plage parfaitement raisonnable.
Adapté de l’article original paru le 00f.net