Comment corriger une résolution DNS lente

Ce que mesure une résolution lente

Le chargement d'une page commence par une résolution de nom, puis une connexion TCP, puis une poignée de main TLS, puis le temps de réflexion propre du serveur. Seule la première de ces étapes est le DNS, et c'est la seule que vous pouvez souvent améliorer sans toucher au site du tout.

Deux chiffres sont ici souvent confondus. Une résolution mise en cache ne coûte presque rien, car la réponse est déjà sur votre machine ou à un saut de distance. Une résolution à froid peut impliquer une requête vers la racine, une autre vers le domaine de premier niveau, et une autre encore vers les serveurs de noms propres au domaine, chacune étant un aller-retour à travers quelle que soit la distance qui vous sépare de ces serveurs. Moins de 20 ms à chaud et moins de 100 ms à froid n'ont rien d'inhabituel. Quoi que ce soit approchant la seconde signifie qu'un des sauts est loin, surchargé, ou qu'il expire et est retenté.

Les pages modernes aggravent cela en ayant de nombreux noms d'hôtes. Les polices, les outils d'analyse, les images et les widgets de paiement ont chacun besoin de leur propre résolution, et un navigateur qui résout dix noms d'hôtes à 300 ms chacun a passé trois secondes sur le DNS avant de restituer quoi que ce soit d'utile.

Confirmer que le DNS est la partie lente

Mesurez avant de changer quoi que ce soit. La commande unique la plus propre décompose une requête en ses phases :

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

Si time_namelookup représente une petite fraction du total, le DNS n'est pas votre problème et vous devriez plutôt lire ce qui concerne le temps de réponse du serveur. S'il représente un tiers ou plus, continuez. Pour la résolution seule, dig affiche le temps écoulé pour vous :

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

Sous Windows, PowerShell donne la même lecture :

Measure-Command { Resolve-DnsName www.example.com }
Measure-Command { Resolve-DnsName www.example.com -Server 1.1.1.1 }

Comparez votre réglage par défaut aux résolveurs publics. Un grand écart vous indique que la correction est de votre côté. Des temps similaires partout pointent vers les serveurs de noms propres au domaine.

Un résultat exclut entièrement ce guide. Si un résolveur répond instantanément avec NXDOMAIN, le nom n'est pas publié et vous êtes face à un problème différent, décrit dans DNS_PROBE_FINISHED_NXDOMAIN.

Pourquoi cela arrive

• Un résolveur distant. Les services publics utilisent l'anycast, de sorte que la même adresse répond depuis un emplacement proche. Un résolveur de FAI ou un serveur de bureau unique ne le fait pas, et chaque requête paie l'aller-retour complet.
• Le premier serveur de la liste est mort. Le client attend l'expiration de son délai, puis interroge le second. Sur les systèmes glibc, le réglage par défaut est de 5 secondes avant la première nouvelle tentative, ce qui correspond exactement à la pause que les gens décrivent par « ça se bloque, puis ça charge ».
• Des TTL très bas. Un TTL de 30 ou 60 secondes signifie que presque chaque visiteur paie pour une résolution fraîche, car la copie mise en cache a déjà expiré.
• De longues chaînes de CNAME. Chaque maillon est une résolution supplémentaire. Des chaînes de trois ou quatre maillons sont courantes derrière les CDN et les outils marketing.
• Des serveurs de noms faisant autorité lents. Un fournisseur DNS avec peu d'emplacements répond rapidement pour une partie du monde et lentement pour le reste.
• La validation DNSSEC. Valider une chaîne ajoute des requêtes. C'est normalement peu coûteux, mais une chaîne partiellement cassée provoque des nouvelles tentatives qui ressemblent à de la lenteur.
• Les domaines de recherche. Un résolveur configuré avec des suffixes essaie example.com.corp.local avant example.com, dépensant d'abord une requête échouée pour chaque suffixe.
• Des résolutions AAAA sans IPv6. Le système demande les deux types d'enregistrement et attend la réponse qu'il ne peut pas utiliser.
• Un VPN ou un proxy filtrant qui envoie chaque requête à travers un tunnel vers un résolveur situé sur un autre continent.
• Un routeur agissant comme relais avec un tout petit cache et un processeur sous-dimensionné.

Comment le corriger

Sur votre appareil

1. Videz les caches pour que vos mesures soient honnêtes : ipconfig /flushdns sous Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder sous macOS, sudo resolvectl flush-caches sous Linux.
2. Regardez quels serveurs sont configurés et dans quel ordre : Get-DnsClientServerAddress, scutil --dns, ou resolvectl status. Retirez toute entrée qui ne répond plus, car une première entrée morte vous coûte le délai d'attente sur chaque résolution à froid.
3. Sous Linux, raccourcissez l'attente pendant que vous enquêtez en ajoutant options timeout:2 attempts:2 à /etc/resolv.conf, et supprimez les suffixes search inutilisés.
4. Déconnectez le VPN et mesurez à nouveau. Si le chiffre est divisé par deux, le tunnel est la cause et c'est son réglage de résolveur qu'il faut changer.

Sur votre réseau

1. Définissez le résolveur dans le DHCP au niveau du routeur plutôt qu'appareil par appareil, de sorte que chaque client obtienne la même paire rapide.
2. Donnez au relais propre du routeur un résolveur public en amont au lieu du réglage par défaut du FAI, ou contournez entièrement le relais en distribuant directement les adresses publiques aux clients.
3. Sur un réseau d'entreprise avec son propre serveur DNS, vérifiez qu'il relaie plutôt que d'effectuer une récursion complète depuis un seul site, et que son cache est assez grand pour tenir toute la journée de travail.

Sur votre propre domaine

1. Augmentez les TTL sur les enregistrements qui changent rarement. Cinq minutes est un plancher raisonnable pour un enregistrement que vous pourriez devoir déplacer rapidement ; une heure ou un jour convient à tout ce qui est stable.
2. Aplatissez les chaînes de CNAME où c'est possible. Pointez l'enregistrement directement vers la cible finale plutôt qu'une chaîne d'alias : dig www.example.com CNAME +short montre la profondeur de la vôtre.
3. Utilisez un fournisseur DNS avec des serveurs de noms anycast, et gardez au moins deux serveurs de noms sur des réseaux séparés.
4. Vérifiez que le DNSSEC se valide. Comparez une requête normale avec une qui saute la validation : dig example.com @1.1.1.1 face à dig +cd example.com @1.1.1.1. Un grand écart, ou un SERVFAIL sur la première seulement, signifie que la chaîne est cassée.

Vérifiez-le depuis l'extérieur

Vos propres mesures décrivent un réseau à un instant donné, ce qui est l'échantillon le moins utile que vous puissiez prendre. Un résolveur qui est à 8 ms de vous peut être à 400 ms d'un client dans une autre région, et c'est ce client qui se plaint.

Commencez par mesurer les serveurs faisant autorité directement, ce qui retire chaque cache entre vous et la source :

dig NS example.com +short
dig @ns1.example-dns.net example.com | grep "Query time"
dig example.com +trace

La sortie de +trace parcourt la délégation étape par étape, de sorte qu'un saut qui bloque soit visible plutôt que moyenné et donc invisible. Lancez ensuite la vérification de requête DNS, qui résout le nom depuis des points de contrôle dans différents pays et rapporte chacun séparément. C'est la mesure que vous ne pouvez pas prendre depuis un ordinateur portable : elle montre si vos serveurs de noms sont lents partout, ce qui pointe vers le fournisseur, ou lents depuis un seul continent, ce qui pointe vers son empreinte réseau. Si certains emplacements renvoient une réponse différente plutôt qu'une réponse plus lente, la question porte alors sur la propagation, traitée dans comment vérifier la propagation DNS.

Une latence qui dérive plutôt qu'elle ne casse

La latence DNS se dégrade rarement de façon évidente. Elle dérive, un serveur de noms perd un emplacement, un TTL est abaissé pendant une migration et n'est jamais relevé, et six semaines plus tard le site semble mou pour des raisons que personne ne peut identifier. Une seule mesure ne peut pas montrer une tendance, c'est pourquoi le temps de résolution vaut la peine d'être enregistré selon un horaire depuis les régions où se trouvent vos visiteurs. HostTracker surveille des sites web depuis 2004 et observe aujourd'hui plus de 500 000 sites web depuis des points de contrôle répartis dans 158 villes, conservant l'historique qui rend une dérive lente visible. Les autres guides ici se trouvent dans le cluster résoudre, et le cas d'échec où rien ne revient du tout est DNS server not responding.