Une faible latence DNS est la clé d’une navigation Internet rapide. Pour le minimiser, il est important de sélectionner soigneusement les serveurs DNS et . Mais la première étape consiste à se débarrasser des requêtes inutiles.
C'est pourquoi DNS a été conçu à l'origine comme un protocole hautement mis en cache. Les administrateurs de zone définissent une durée de vie (TTL) pour les entrées individuelles, et les résolveurs utilisent ces informations lors du stockage des entrées en mémoire pour éviter un trafic inutile.
La mise en cache est-elle efficace ? Il y a quelques années, mes petites recherches ont montré que ce n'était pas parfait. Jetons un coup d'œil à l'état actuel des choses.
Pour collecter les informations que j'ai corrigées pour enregistrer la valeur TTL de la réponse. Il est défini comme la durée de vie minimale de ses enregistrements pour chaque demande entrante. Cela donne un bon aperçu de la répartition TTL du trafic réel et prend également en compte la popularité des requêtes individuelles. La version corrigée du serveur a fonctionné pendant plusieurs heures.
L'ensemble de données résultant comprend 1 583 579 enregistrements (nom, qtype, TTL, horodatage). Voici la distribution globale du TTL (l'axe X correspond au TTL en secondes) :
Mis à part une légère augmentation à 86 400 (principalement pour les enregistrements SOA), il est assez clair que les TTL se situent dans la fourchette basse. Regardons de plus près:
D'accord, les TTL supérieurs à 1 heure ne sont pas statistiquement significatifs. Concentrons-nous ensuite sur la plage 0−3600 :
La plupart des TTL durent de 0 à 15 minutes :
La grande majorité est de 0 à 5 minutes :
Ce n'est pas très bon.
La distribution cumulative rend le problème encore plus évident :
La moitié des réponses DNS ont 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. Après tout, il s'agit de TTL provenant de serveurs faisant autorité. Cependant, les résolveurs clients (par exemple les routeurs, les caches locaux) reçoivent une durée de vie des résolveurs en amont, et elle diminue chaque seconde.
Ainsi, le client peut réellement utiliser chaque entrée pour, en moyenne, la moitié de la durée de vie initiale avant d'envoyer une nouvelle requête.
Peut-être que ces TTL très faibles ne s’appliquent qu’aux requêtes inhabituelles et non aux sites Web et API populaires ? Jetons un coup d'oeil :
L'axe X est le TTL, l'axe Y est la popularité des requêtes.
Malheureusement, les requêtes les plus populaires sont aussi les pires à mettre en cache.
Zoomons :
Verdict : c'est vraiment mauvais. C'était déjà mauvais avant, mais c'est encore pire. La mise en cache DNS est devenue pratiquement inutile. Comme de moins en moins de personnes utilisent le résolveur DNS de leur FAI (pour de bonnes raisons), l'augmentation de la latence devient plus perceptible.
La mise en cache DNS est devenue utile uniquement pour le contenu que personne ne visite.
Veuillez également noter que le logiciel peut interpréter les faibles TTL.
Pourquoi est-ce?
Pourquoi les enregistrements DNS sont-ils définis sur une durée de vie si faible ?
- Les anciens équilibreurs de charge ont conservé leurs paramètres par défaut.
- Il existe des mythes selon lesquels l'équilibrage de charge DNS dépend du TTL (ce n'est pas vrai - depuis l'époque de Netscape Navigator, les clients ont choisi une adresse IP aléatoire parmi un ensemble de RR et en ont essayé une autre de manière transparente s'ils ne peuvent pas se connecter)
- Les administrateurs souhaitent appliquer les modifications immédiatement, ce qui facilite la planification.
- L'administrateur d'un serveur DNS ou d'un équilibreur de charge considère que sa tâche consiste à déployer efficacement la configuration demandée par les utilisateurs, et non à accélérer les sites et les services.
- Les faibles TTL vous offrent une tranquillité d'esprit.
- Les gens définissent initialement des durées de vie faibles pour les tests, puis oublient de les modifier.
Je n'ai pas inclus le "failover" dans la liste car cela devient de moins en moins pertinent. Si vous devez rediriger les utilisateurs vers un autre réseau simplement pour afficher une page d'erreur alors qu'absolument tout le reste est cassé, un délai de plus d'une minute est probablement acceptable.
De plus, une durée de vie d'une minute signifie que si les serveurs DNS faisant autorité sont bloqués pendant plus d'une minute, personne d'autre ne pourra accéder aux services dépendants. Et la redondance n’aidera pas si la cause est une erreur de configuration ou un hack. En revanche, avec des durées de vie raisonnables, de nombreux clients continueront à utiliser la configuration précédente et ne remarqueront jamais rien.
Les services CDN et les équilibreurs de charge sont en grande partie responsables des faibles durées de vie, en particulier lorsqu'ils combinent des CNAME avec des durées de vie faibles et des enregistrements avec des durées de vie tout aussi faibles (mais indépendantes) :
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Chaque fois que le CNAME ou l'un des enregistrements A expire, une nouvelle demande doit être envoyée. Les deux ont un TTL de 30 secondes, mais ce n'est pas la même chose. La durée de vie moyenne réelle sera de 15 secondes.
Mais attendez! C'est encore pire. Certains résolveurs se comportent très mal dans cette situation avec deux TTL faibles associés :
$ percer raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 EN CNAME github.map.fastly.net. github.map.fastly.net. 1 DANS UN 151.101.16.133
Le résolveur Level3 fonctionne probablement sur BIND. Si vous continuez à envoyer cette demande, un TTL de 1 sera toujours renvoyé. raw.githubusercontent.com n'est jamais mis en cache.
Voici un autre exemple d’une telle situation avec un domaine très populaire :
$ drill detectportal.firefox.com @1.1.1.1 detectportal.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.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Au moins trois enregistrements CNAME. Oui. On a un TTL décent, mais c'est complètement inutile. Les autres CNAME ont une durée de vie initiale de 60 secondes, mais pour les domaines akamai.net le TTL maximum est de 20 secondes et aucun d'entre eux n'est en phase.
Qu’en est-il des domaines qui interrogent constamment les appareils Apple ?
$ drill 1-courier.push.apple.com @4.2.2.2 1-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.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Même problème que Firefox et TTL seront bloqués à 1 seconde la plupart du temps lors de l'utilisation du résolveur Level3.
Boîte de dépôt ?
$ percer client.dropbox.com @8.8.8.8 client.dropbox.com. 7 DANS CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ forage client.dropbox.com @4.2.2.2 client.dropbox.com. 1 EN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 DANS UN 162.125.64.3
A l'enregistrement safebrowsing.googleapis.com La valeur TTL est de 60 secondes, comme les domaines Facebook. Et encore une fois, du point de vue du client, ces valeurs sont réduites de moitié.
Que diriez-vous de définir un TTL minimum ?
En utilisant le nom, le type de requête, la durée de vie et l'horodatage stocké à l'origine, j'ai écrit un script pour simuler 1,5 million de requêtes passant par un résolveur de mise en cache afin d'estimer le volume de requêtes inutiles envoyées en raison d'une entrée de cache expirée.
47,4 % des demandes ont été faites après l'expiration d'un dossier existant. C’est déraisonnablement élevé.
Quel sera l'impact sur la mise en cache si la durée de vie minimale est définie ?
L'axe X correspond aux valeurs TTL minimales. Les enregistrements dont la durée de vie source est supérieure à cette valeur ne sont pas affectés.
L'axe Y représente le pourcentage de requêtes provenant d'un client qui a déjà une entrée en cache, mais qui a expiré et qui fait une nouvelle requête.
La part des requêtes « supplémentaires » est réduite de 47 % à 36 % en fixant simplement le TTL minimum à 5 minutes. En fixant le TTL minimum à 15 minutes, le nombre de ces requêtes chute à 29 %. Un TTL minimum de 1 heure les réduit à 17%. Différence significative!
Que diriez-vous de ne rien changer côté serveur, mais plutôt de définir le TTL minimum dans les caches DNS des clients (routeurs, résolveurs locaux) ?
Le nombre de requêtes requises passe de 47 % à 34 % avec un TTL minimum de 5 minutes, à 25 % avec un minimum de 15 minutes et à 13 % avec un minimum de 1 heure. Peut-être que 40 minutes sont optimales.
L’impact de ce petit changement est énorme.
Quelles en sont les implications?
Bien entendu, le service peut être déplacé vers un nouveau fournisseur de cloud, un nouveau serveur, un nouveau réseau, obligeant les clients à utiliser les derniers enregistrements DNS. Et un TTL assez petit permet d'effectuer une telle transition en douceur et imperceptiblement. Mais avec la transition vers une nouvelle infrastructure, personne ne s'attend à ce que les clients migrent vers de nouveaux enregistrements DNS en 1 minute, 5 minutes ou 15 minutes. Définir la durée de vie minimale à 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é et la fiabilité en évitant les demandes inutiles.
Bien entendu, les RFC disent que le TTL doit être strictement respecté. Mais la réalité est que le système DNS est devenu trop inefficace.
Si vous travaillez avec des serveurs DNS faisant autorité, veuillez vérifier vos TTL. Avez-vous vraiment besoin de valeurs aussi ridiculement basses ?
Bien entendu, il existe de bonnes raisons de définir de petites durées de vie pour les enregistrements DNS. Mais pas pour les 75 % du trafic DNS qui restent quasiment inchangés.
Et si, pour une raison quelconque, vous avez vraiment besoin d'utiliser des TTL faibles pour le DNS, assurez-vous en même temps que la mise en cache n'est pas activée sur votre site. Pour les mêmes raisons.
Si vous disposez d'un cache DNS local en cours d'exécution, tel que qui vous permet de définir des TTL minimum, utilisez cette fonction. C'est bon. Rien de grave n’arrivera. Réglez la durée de vie minimale sur environ 40 minutes (2400 1 secondes) et XNUMX heure. Une fourchette tout à fait raisonnable.
Source: habr.com