Une faible latence DNS est un facteur clé pour une navigation Internet rapide. Pour le minimiser, il est important de sélectionner soigneusement les serveurs DNS et les relais anonymes . Mais la première chose à faire est de se débarrasser des requêtes inutiles.

C'est pourquoi DNS a été créé à l'origine comme un protocole hautement mis en cache. Les administrateurs de zone définissent une durée de vie (TTL) pour les enregistrements individuels et les résolveurs utilisent ces informations lors du stockage des enregistrements en mémoire pour éviter le 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. Jetez un œil à la situation actuelle.

Pour collecter des informations, j'ai corrigé le serveur DNS crypté pour stocker la valeur TTL pour la réponse. Il est défini comme le TTL minimum de ses entrées pour chaque demande entrante. Cela donne un bon aperçu de la répartition du trafic réel TTL et prend également en compte la popularité des demandes individuelles. La version corrigée du serveur a fonctionné pendant plusieurs heures.

L'ensemble de données résultant se compose de 1 583 579 enregistrements (nom, qtype, TTL, horodatage). Voici la distribution générale de TTL (l'axe X est TTL en secondes):



Mis à part le monticule mineur sur 86 400 (principalement pour les enregistrements SOA), il est assez évident que les TTL sont dans la plage basse. Examinons de plus près:



Eh bien, les TTL de plus d'une heure ne sont pas statistiquement significatifs. Ensuite, concentrez-vous sur la plage 0−3600:



La plupart des TTL de 0 à 15 minutes:



La grande majorité 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 dans les trois quarts 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 les TTL des résolveurs supérieurs, et cela diminue chaque seconde.

Ainsi, le client peut réellement utiliser chaque enregistrement, en moyenne, pour la moitié du TTL d'origine, après quoi il enverra une nouvelle demande.

Peut-être que ces TTL très faibles ne concernent que des demandes inhabituelles, pas des sites Web et des API populaires? Voyons voir:



L'axe X est TTL, l'axe Y est la popularité des requêtes.

Malheureusement, les requêtes les plus populaires sont également mises en cache.

Zoom avant:



Verdict: tout est vraiment mauvais. C'était mauvais avant, mais ça a empiré. La mise en cache DNS est devenue pratiquement inutile. Comme moins de personnes utilisent le résolveur DNS de leur FAI (pour une bonne raison), 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.

Notez également que le logiciel peut interpréter différemment les faibles TTL.

Pourquoi

Pourquoi un si petit TTL est-il défini pour les enregistrements DNS?

• Les équilibreurs de charge obsolètes se retrouvent avec des paramètres par défaut.
  
• Il existe des mythes selon lesquels l'équilibrage de charge DNS dépend de TTL (ce n'est pas le cas - puisque Netscape Navigator, les clients choisissent une adresse IP aléatoire dans l'ensemble RR et essaient de manière transparente une autre s'ils ne peuvent pas se connecter)
  
• Les administrateurs souhaitent appliquer les modifications immédiatement, car il est plus facile de planifier.
  
• L'administrateur du serveur DNS ou de l'équilibreur de charge considère que sa tâche consiste à déployer efficacement la configuration demandée par les utilisateurs, plutôt qu'à accélérer les sites et les services.
  
• Un faible TTL donne la tranquillité d'esprit.
  
• Les utilisateurs ont initialement défini des TTL faibles pour les tests, puis oublient de les modifier.

Je n'ai pas inclus le «basculement» dans la liste, car cela est d'autant moins pertinent. Si vous devez rediriger les utilisateurs vers un autre réseau uniquement pour afficher la page d'erreur, lorsque tout le reste est cassé, un délai de plus d'une minute est probablement acceptable.

De plus, la minute TTL signifie que si les serveurs DNS faisant autorité sont bloqués pendant plus d'une minute, personne d'autre ne peut 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.

Pour les TTL faibles, les services CDN et les équilibreurs de charge sont largement à blâmer, en particulier lorsqu'ils combinent CNAME avec de petits TTL et des enregistrements avec des TTL également petits (mais indépendants):

  $ drill raw.githubusercontent.com
 raw.githubusercontent.com.  9 DANS CNAME github.map.fastly.net.
 github.map.fastly.net.  20 DANS UN 151.101.128.133
 github.map.fastly.net.  20 DANS UN 151.101.192.133
 github.map.fastly.net.  20 DANS UN 151.101.0.133
 github.map.fastly.net.  20 DANS UN 151.101.64.133 

Chaque fois qu'un CNAME ou l'un des enregistrements A expire, vous devez envoyer une nouvelle demande. Les deux ont un TTL de 30 secondes, mais il ne correspond pas. Le TTL moyen réel sera de 15 secondes.

Mais attends! Encore pire. Certains résolveurs se comportent très mal dans cette situation avec deux faibles TTL associés:

  $ drill raw.githubusercontent.com @ 4.2.2.2
 raw.githubusercontent.com.  1 DANS 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é. Essentiellement, raw.githubusercontent.com 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 DANS UN 104.123.50.106
 a1089.dscd.akamai.net.  10 DANS UN 104.123.50.88 

Au moins trois enregistrements CNAME. Aw. On a un TTL décent, mais c'est complètement inutile. Dans d'autres CNAME, le TTL initial est de 60 secondes, mais pour les domaines akamai.net 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 EN CNAME gb-courier-4.push-apple.com.akadns.net.
 gb-courier-4.push-apple.com.akadns.net.  1 DANS UN 17.57.146.84
 gb-courier-4.push-apple.com.akadns.net.  1 DANS UN 17.57.146.85 

Le même problème que Firefox, et TTL restera bloqué pendant 1 seconde la plupart du temps lors de l'utilisation du résolveur Level3.

Dropbox?

  $ drill client.dropbox.com @ 8.8.8.8
 client.dropbox.com.  7 DANS CNAME client.dropbox-dns.com.
 client.dropbox-dns.com.  59 DANS UN 162.125.67.3

 $ drill client.dropbox.com @ 4.2.2.2
 client.dropbox.com.  1 DANS CNAME client.dropbox-dns.com.
 client.dropbox-dns.com.  1 DANS UN 162.125.64.3 

safebrowsing.googleapis.com un TTL de 60 secondes, tout comme avec les domaines Facebook. Et, encore une fois, du point de vue du client, ces valeurs sont divisées par deux.

Que diriez-vous de définir un TTL minimum?

En utilisant le nom, le type de demande, le TTL et l'horodatage enregistré à l'origine, j'ai écrit un script pour simuler 1,5 million de demandes passant par un résolveur de mise en cache afin d'estimer le nombre de demandes supplémentaires envoyées en raison d'une entrée de cache expirée.

47,4% des demandes ont été faites après l'expiration du dossier existant. C'est déraisonnablement élevé.

Quel sera l'effet sur la mise en cache si le TTL minimum est défini?



L'axe X est la valeur TTL minimale. Les enregistrements avec des TTL source supérieurs à cette valeur ne sont pas affectés.

Axe Y - pourcentage de demandes d'un client qui a déjà un enregistrement mis en cache, mais a expiré et il fait une nouvelle demande.

Le pourcentage de demandes «supplémentaires» est réduit de 47% à 36% en définissant simplement le TTL minimum en 5 minutes. Lors de la définition du TTL minimum en 15 minutes, le nombre de ces demandes est réduit à 29%. Un TTL minimum de 1 heure les réduit à 17%. La grande différence!

Que diriez-vous de ne rien changer côté serveur, mais plutôt de définir le TTL minimum dans les caches DNS clients (routeurs, résolveurs locaux)?



Le nombre de demandes requises est réduit de 47% à 34% lors de la définition du TTL minimum en 5 minutes, à 25% avec un minimum de 15 minutes et jusqu'à 13% avec un minimum de 1 heure. La valeur optimale est peut-être de 40 minutes.

L'impact de ce changement minimal est énorme.

Quelles en sont les implications?

Bien sûr, le service peut être transféré vers un nouveau fournisseur de cloud, un nouveau serveur, un nouveau réseau, obligeant les clients à utiliser les derniers enregistrements DNS. Et un TTL suffisamment petit permet une transition en douceur et en toute transparence. Mais avec la transition vers une nouvelle infrastructure, personne ne s'attend à ce que les clients passent à de nouveaux enregistrements DNS en 1 minute, 5 minutes ou 15 minutes. La définition d'une durée de vie minimale 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 augmentera la confidentialité et la fiabilité, en évitant les demandes inutiles.

Bien sûr, les RFC disent que vous devez appliquer strictement TTL. 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 votre TTL. Avez-vous vraiment besoin de valeurs aussi ridiculement basses?

Bien sûr, il existe de bonnes raisons de définir de petits TTL pour les enregistrements DNS. Mais pas pour 75% du trafic DNS, qui reste pratiquement inchangé.

Et si pour une raison quelconque vous avez vraiment besoin d'utiliser un TTL bas pour 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, tel que dnscrypt-proxy , qui vous permet de définir le TTL minimum, utilisez cette fonction. C'est normal. Il ne se passera rien de mal. Réglez le TTL minimum entre environ 40 minutes (2400 secondes) et 1 heure. Une gamme assez raisonnable.