Introduction: causes et atténuation de la latence DNS
À mesure que les pages Web deviennent plus complexes, en référençant les ressources de nombreux domaines, les résolutions DNS peuvent devenir un goulot d'étranglement important dans l'expérience de navigation. Chaque fois qu'un client doit interroger un résolveur DNS sur le réseau, la latence introduite peut être importante, en fonction de la proximité et du nombre de serveurs de noms que le résolveur doit interroger (plus de 2 est rare, mais cela peut arriver). Par exemple, la capture d'écran suivante montre les codes temporels indiqués par l'outil de mesure des performances Web Vitesse des pages. Chaque barre représente une ressource référencée sur la page. Les segments noirs indiquent les résolutions DNS. Sur cette page, 13 recherches sont effectuées au cours des 11 premières secondes de chargement de la page. Bien que plusieurs recherches soient effectuées en parallèle, la capture d'écran montre que cinq temps de recherche en série sont nécessaires, ce qui représente plusieurs secondes du temps de chargement total de la page, qui est de 11 secondes.
La latence DNS repose sur deux éléments:
- Latence entre le client (utilisateur) et le serveur de résolution DNS. Le plus souvent, cela est dû en grande partie aux contraintes habituelles du délai aller-retour (DAR) des systèmes en réseau: distance géographique entre les machines client et serveur, encombrement du réseau, perte de paquets et longs délais de retransmission (une seconde en moyenne), serveurs surchargés, attaques par déni de service, etc.
- Latence entre les serveurs de résolution et les autres serveurs de noms.
Cette source de latence est principalement due aux facteurs suivants :
- les défauts de cache (miss). Si une réponse ne peut pas être diffusée à partir du cache d'un résolveur, mais nécessite d'interroger de manière récurrente d'autres serveurs de noms, la latence réseau supplémentaire est considérable, en particulier si les serveurs primaires sont géographiquement distants.
- Sous-provisionnement. Si les résolveurs DNS sont surchargés, ils doivent mettre en file d'attente les requêtes et les réponses de résolution DNS, et peuvent commencer à supprimer et à retransmettre des paquets.
- Trafic malveillant. Même si un service DNS est surprovisionné, le trafic DoS peut placer une charge excessive sur les serveurs. De même, les attaques de style Kaminsky peuvent impliquer une inondation des résolveurs de requêtes qui sont garanties pour contourner le cache et qui nécessitent des requêtes sortantes pour une résolution.
Nous pensons que le facteur de défaut de cache (miss) est la cause la plus importante de la latence DNS. Nous en discuterons plus en détail ci-dessous.
Erreurs de cache (miss)
Même si un résolveur dispose de ressources locales abondantes, les retards fondamentaux liés à la communication avec les serveurs de noms distants sont difficiles à éviter. En d'autres termes, en supposant que le résolveur est suffisamment bien provisionné pour que les succès de cache soient supprimés du côté serveur, les défauts de cache (miss) restent très coûteux en termes de latence. Pour gérer un défaut, un résolveur doit communiquer avec au moins un, mais souvent deux serveurs de noms externes ou plus. Avec le robot d'exploration Googlebot, nous avons observé un temps de résolution moyen de 130 ms pour les serveurs de noms qui répondent. Toutefois, 4 à 6% des requêtes expirent simplement, en raison de la perte de paquets UDP et de l'inaccessibilité des serveurs. Si nous prenons en compte les défaillances telles que la perte de paquets, les serveurs de noms morts, les erreurs de configuration DNS, etc., la durée moyenne de résolution réelle de bout en bout est comprise entre 300 et 400 ms. Toutefois, il existe une variance importante et une longue traîne.
Bien que le taux de défaut de cache puisse varier d'un serveur DNS à l'autre, ils sont fondamentalement difficiles à éviter pour les raisons suivantes:
- la taille et la croissance d'Internet. Pour faire simple, à mesure qu'Internet se développe, à la fois par l'ajout de nouveaux utilisateurs et par la création de nouveaux sites, la majorité du contenu ne présente qu'un intérêt marginal. Bien que quelques sites (et par conséquent des noms DNS) soient très populaires, la plupart n'intéressent que quelques utilisateurs et sont rarement consultés. La majorité des requêtes entraînent donc des défauts de cache (miss).
- Valeurs TTL (Time To Live) faibles La tendance à des valeurs TTL DNS plus faibles signifie que les résolutions nécessitent des recherches plus fréquentes.
- Isolement du cache Les serveurs DNS sont généralement déployés derrière des équilibreurs de charge qui attribuent des requêtes à différentes machines de manière aléatoire. Chaque serveur individuel dispose ainsi d'un cache distinct au lieu de pouvoir réutiliser les résolutions mises en cache d'un pool partagé.
Stratégies d'atténuation
Dans le DNS public de Google, nous avons mis en œuvre plusieurs approches pour réduire les délais de résolution DNS. Certaines de ces approches sont assez standards, d'autres sont expérimentales:
- Provisionner les serveurs de manière adéquate pour gérer la charge du trafic client, y compris le trafic malveillant.
- Prévention des attaques DoS et de leur amplification Bien qu'il s'agisse principalement d'un problème de sécurité et qu'il affecte moins les résolveurs fermés que les résolveurs ouverts, la prévention des attaques DoS présente également un avantage en termes de performances, car elle élimine la charge de trafic supplémentaire pesant sur les serveurs DNS. Pour en savoir plus sur les approches que nous utilisons pour réduire les risques d'attaque, consultez la page sur les avantages en termes de sécurité.
- L'équilibrage de charge pour la mise en cache partagée, afin d'améliorer le taux d'accès au cache agrégé sur l'ensemble du cluster de diffusion
- Fournir une couverture mondiale pour assurer la proximité avec tous les utilisateurs.
Provisionner correctement les clusters de diffusion
Les résolveurs DNS de mise en cache doivent effectuer des opérations plus coûteuses que les serveurs de noms primaires, car de nombreuses réponses ne peuvent pas être diffusées à partir de la mémoire. Au lieu de cela, ils nécessitent une communication avec d'autres serveurs de noms et nécessitent donc beaucoup d'entrées/sorties réseau. De plus, les résolveurs ouverts sont très vulnérables aux tentatives d'empoisonnement du cache, qui augmentent le taux de défaut de cache (telles qu'elles envoient spécifiquement des requêtes pour des noms factices qui ne peuvent pas être résolus à partir du cache) et aux attaques DoS, qui augmentent la charge de trafic. Si les résolveurs ne sont pas provisionnés de manière adéquate et ne peuvent pas suivre la charge, cela peut avoir un impact très négatif sur les performances. Les paquets sont supprimés et doivent être retransmis, les requêtes de serveur de noms doivent être mises en file d'attente, etc. Tous ces facteurs ajoutent des retards.
Par conséquent, il est important que les résolveurs DNS soient provisionnés pour des entrées/sorties volumineuses. Cela inclut la gestion d'éventuelles attaques DDoS, pour lesquelles la seule solution efficace consiste à surprovisionner de nombreuses machines. Dans le même temps, il est important de ne pas réduire le taux de succès de cache lorsque vous ajoutez des machines. Cela nécessite la mise en œuvre d'une règle d'équilibrage de charge efficace, que nous aborderons ci-dessous.
Équilibrage de charge pour la mise en cache partagée
Le scaling de l'infrastructure du résolveur en ajoutant des machines peut effectivement se déclencher et réduire le taux de succès de cache si l'équilibrage de charge n'est pas effectué correctement. Dans un déploiement classique, plusieurs machines se trouvent derrière un équilibreur de charge qui répartit équitablement le trafic entre chaque machine, à l'aide d'un algorithme simple tel que le round robin (à tour de rôle). En conséquence, chaque machine conserve son propre cache indépendant, de sorte que le contenu mis en cache est isolé entre les machines. Si chaque requête entrante est distribuée sur une machine aléatoire, en fonction de la nature du trafic, le taux effectif de défaut de cache peut être augmenté proportionnellement. Par exemple, pour les noms avec de longs TTL qui sont interrogés de manière répétée, le taux de défaut de cache peut être augmenté en fonction du nombre de machines dans le cluster. (Pour les noms ayant des TTL très courts, qui sont interrogés très peu fréquemment ou qui génèrent des réponses ne pouvant pas être mises en cache (zéro TTL et erreurs), le taux de défaut de cache (miss) n'est pas réellement affecté par l'ajout de machines.)
Pour augmenter le taux de succès des noms pouvant être mis en cache, il est important d'équilibrer la charge des serveurs afin que le cache ne soit pas fragmenté. Dans le DNS public de Google, nous disposons de deux niveaux de mise en cache. Dans un pool de machines, très proche de l'utilisateur, un petit cache par machine contient les noms les plus courants. Si une requête ne peut pas être satisfaite à partir de ce cache, elle est envoyée à un autre pool de machines qui partitionnent le cache par nom. Pour ce cache de deuxième niveau, toutes les requêtes portant le même nom sont envoyées à la même machine, où le nom est mis en cache ou non.
Distribuer des clusters actifs pour une couverture géographique étendue
Pour les résolveurs fermés, ce n'est pas vraiment un problème. Pour les résolveurs ouverts, plus vos serveurs sont proches de vos utilisateurs, moins ils verront de latence côté client. En outre, une couverture géographique suffisante peut améliorer indirectement la latence de bout en bout, car les serveurs de noms renvoient généralement des résultats optimisés en fonction de l'emplacement du résolveur DNS. Autrement dit, si un fournisseur de contenu héberge des sites mis en miroir dans le monde entier, ses serveurs de noms renvoient l'adresse IP la plus proche du résolveur DNS.
Le DNS public de Google est hébergé dans des centres de données du monde entier et utilise le routage Anycast pour envoyer les utilisateurs vers le centre de données géographiquement le plus proche.
En outre, le DNS public de Google est compatible avec le sous-réseau client EDNS (ECS), une extension de protocole DNS permettant aux résolveurs de transmettre l'emplacement du client aux serveurs de noms, lesquels peuvent renvoyer des réponses sensibles à l'emplacement optimisées pour l'adresse IP réelle du client plutôt que pour l'adresse IP du résolveur. Pour en savoir plus, veuillez consulter ces questions fréquentes. Le DNS public de Google détecte automatiquement les serveurs de noms compatibles avec le sous-réseau de client EDNS.