Une faible latence DNS est un facteur clĂ© pour un fonctionnement rapide sur Internet. Pour la minimiser, il est important de choisir soigneusement les serveurs DNS et . Mais avant tout, il faut se dĂ©barrasser des requĂȘtes inutiles.
C'est pourquoi le DNS a été à l'origine conçu comme un protocole fortement caché. Les administrateurs de zones définissent le temps de vie (TTL) pour chaque enregistrement, et les résolveurs utilisent cette information pour stocker des enregistrements en mémoire afin d'éviter un trafic inutile.
Le caching est-il efficace ? Il y a quelques années, ma petite recherche a montré qu'il n'était pas parfait. Examinons l'état actuel des choses.
Pour recueillir des informations, j'ai patchĂ© pour conserver la valeur TTL de la rĂ©ponse. Celle-ci est dĂ©finie comme le TTL minimum de ses enregistrements, pour chaque requĂȘte entrante. Cela donne une bonne vue d'ensemble de la rĂ©partition des TTL du trafic rĂ©el, tout en tenant compte de la popularitĂ© des requĂȘtes individuelles. La version patchĂ©e du serveur a fonctionnĂ© quelques heures.
L'ensemble de données résultant se compose de 1 583 579 enregistrements (name, qtype, TTL, timestamp). Voici la répartition globale des TTL (l'axe X représente le TTL en secondes) :
à l'exception d'un léger pic à 86 400 (principalement pour les enregistrements SOA), il est assez évident que les TTL se situent dans une fourchette basse. Regardons de plus prÚs :
Eh bien, les TTL de plus d'une heure ne sont statistiquement pas significatifs. Concentrons-nous donc sur la fourchette de 0 Ă 3600 :
La plupart des TTL se situent entre 0 et 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 :
Dans la moitié des réponses DNS, le TTL est de 1 minute ou moins, et pour les trois quarts, il est de 5 minutes ou moins.
Mais attendez, en réalité, c'est encore pire. Car ce sont des TTL provenant de serveurs autoritatifs. Cependant, les résolveurs clients (par exemple, les routeurs, les caches locaux) obtiennent des TTL de résolveurs en amont, et ce TTL diminue chaque seconde.
Ainsi, le client peut en rĂ©alitĂ© utiliser chaque enregistrement pendant en moyenne la moitiĂ© du TTL initial, aprĂšs quoi il enverra une nouvelle requĂȘte.
Peut-ĂȘtre que ces TTL trĂšs bas concernent seulement des requĂȘtes inhabituelles, et non des sites web et des API populaires ? Voyons voir :
L'axe X reprĂ©sente le TTL, l'axe Y reprĂ©sente la popularitĂ© des requĂȘtes.
Malheureusement, les requĂȘtes les plus populaires sont aussi celles qui se cachent le moins bien.
Approchons :
Verdict : c'est vraiment mauvais. C'était déjà mauvais, et c'est devenu 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 fournisseur (pour des raisons valables), l'augmentation de la latence devient plus perceptible.
La mise en cache DNS n'est devenue utile que pour le contenu que personne ne visite.
Veuillez Ă©galement noter que le logiciel peut les TTL bas.
Pourquoi cela ?
Pourquoi un TTL aussi bas est-il défini pour les enregistrements DNS ?
- Les équilibreurs de charge obsolÚtes sont restés avec les paramÚtres par défaut.
- Il existe des mythes selon lesquels l'équilibrage de charge DNS dépend du TTL (ce n'est pas le cas - depuis l'époque du Netscape Navigator, les clients choisissent une adresse IP au hasard dans un ensemble RR et essaient de maniÚre transparente une autre adresse s'ils ne peuvent pas se connecter)
- Les administrateurs souhaitent appliquer les modifications immédiatement, car il est plus facile de planifier ainsi.
- L'administrateur du serveur DNS ou de l'équilibreur de charge considÚre sa tùche comme déployer efficacement la configuration demandée par les utilisateurs, et non d'accélérer le fonctionnement des sites et services.
- Des TTL bas apportent une tranquillité d'esprit.
- Les gens mettent initialement des TTL bas pour les tests et oublient ensuite de les modifier.
Je n'ai pas inclus la « gestion des pannes » dans la liste, car cela est de moins en moins pertinent. Si vous devez rediriger les utilisateurs vers un autre réseau juste pour afficher une page d'erreur lorsque tout le reste est cassé, un délai de plus de 1 minute est probablement acceptable.
De plus, un TTL d'une minute signifie que si les serveurs DNS autoritaires sont bloqués pendant plus d'une minute, personne ne pourra plus accéder aux services dépendants. Et la redondance n'aidera pas si la cause est une erreur de configuration ou un piratage. D'un autre cÎté, avec des TTL 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 TTL bas, surtout lorsqu'ils combinent CNAME avec de petits TTL et des enregistrements avec des TTL tout aussi petits (mais indépendants) :
$ 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 qu'un CNAME ou l'une des entrĂ©es A expire, il faut envoyer une nouvelle requĂȘte. Les deux ont un TTL de 30 secondes, mais ils ne coĂŻncident pas. Le vĂ©ritable TTL moyen sera de 15 secondes.
Mais attendez ! C'est encore pire. Certains résolveurs se comportent trÚs mal dans une telle situation avec deux bas TTL liés :
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Le rĂ©solveur Level3 fonctionne probablement sur BIND. Si vous continuez Ă envoyer cette requĂȘte, un TTL Ă©gal Ă 1 sera toujours renvoyĂ©. En substance, raw.githubusercontent.com n'est jamais mis en cache.
Voici un autre exemple de cette 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. Ouf. L'un d'eux a un TTL décent, mais c'est tout à fait inutile. Dans les autres CNAME, le TTL initial est de 60 secondes, mais pour les domaines akamai.net le TTL maximal est de 20 secondes, et aucun d'eux n'est synchronisé.
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
Le mĂȘme problĂšme qu'avec Firefox, et le TTL restera la plupart du temps Ă 1 seconde en utilisant le rĂ©solveur Level3.
Dropbox ?
$ drill client.dropbox.com @8.8.8.8 client.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.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Pour l'enregistrement safebrowsing.googleapis.com la valeur du TTL est de 60 secondes, tout comme pour 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 minimal ?
En utilisant le nom, le type de requĂȘte, le TTL et l'horodatage initialement enregistrĂ©, j'ai Ă©crit un script pour simuler 1,5 million de requĂȘtes passant par un rĂ©solveur de cache afin d'Ă©valuer le volume de requĂȘtes superflues envoyĂ©es en raison de l'expiration d'un enregistrement de cache.
47,4 % des requĂȘtes ont Ă©tĂ© effectuĂ©es aprĂšs l'expiration de l'enregistrement existant. C'est excessivement Ă©levĂ©.
Quel sera l'impact sur le caching si un TTL minimal est défini ?
L'axe X représente les valeurs minimales de TTL. Les enregistrements avec des TTL supérieurs à cette valeur ne sont pas affectés.
L'axe Y indique le pourcentage de requĂȘtes provenant d'un client qui a dĂ©jĂ un enregistrement mis en cache, mais dont la durĂ©e de vie a expirĂ©, ce qui entraĂźne une nouvelle requĂȘte.
La part des « requĂȘtes superflues » diminue de 47 % Ă 36 % simplement en rĂ©glant le TTL minimum Ă 5 minutes. En fixant le TTL minimum Ă 15 minutes, ce nombre descend Ă 29 %. Un TTL minimum d'une heure les rĂ©duit Ă 17 %. Une diffĂ©rence significative !
Que diriez-vous de ne rien changer du cÎté serveur, mais plutÎt de définir des TTL minimaux dans les caches DNS des clients (routeurs, résolveurs locaux) ?
Le nombre de requĂȘtes nĂ©cessaires 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 d'une heure. Peut-ĂȘtre que la valeur optimale est de 40 minutes.
L'impact de ce léger changement est énorme.
Quelles en sont les conséquences ?
Bien sĂ»r, le service peut ĂȘtre migrĂ© vers un nouveau fournisseur cloud, un nouveau serveur, un nouveau rĂ©seau, demandant aux clients d'utiliser les derniers enregistrements DNS. Un TTL suffisamment bas permet de faciliter cette transition sans heurts. Mais lors du passage Ă une nouvelle infrastructure, personne ne s'attend Ă ce que les clients passent Ă de nouveaux enregistrements DNS en une minute, cinq minutes ou quinze minutes. Fixer la durĂ©e de vie minimale Ă 40 minutes au lieu de 5 minutes n'empĂȘche pas les utilisateurs d'accĂ©der au service.
Cependant, cela permettra de rĂ©duire considĂ©rablement la latence et d'amĂ©liorer la confidentialitĂ© et la fiabilitĂ©, en Ă©vitant les requĂȘtes inutiles.
Bien sûr, les RFC stipulent qu'il faut respecter strictement le TTL. Mais la réalité est que le systÚme DNS est devenu trop inefficace.
Si vous travaillez avec des serveurs DNS autoritaires, veuillez vérifier vos TTL. Avez-vous vraiment besoin de valeurs aussi ridiculement basses ?
Il y a bien sûr des raisons valables d'installer de petits TTL pour les enregistrements DNS. Mais pas pour 75 % du trafic DNS qui change à peine.
Et si pour une raison quelconque, vous devez vraiment utiliser de faibles TTL pour le DNS, assurez-vous Ă©galement que la mise en cache est dĂ©sactivĂ©e sur votre site. Pour les mĂȘmes raisons.
Si vous avez un cache DNS local, tel que , qui permet de définir un TTL minimum, utilisez cette fonction. Cela va bien. Rien de mal ne se produira. Définissez un TTL minimum d'environ 40 minutes (2400 secondes) à 1 heure. Une plage tout à fait raisonnable.
Source : habr.com
