Passer au contenu 
J'optimise les Performance du résolveur DNS avec une mise en cache cohérente, des valeurs TTL adaptées et une surveillance mesurable, afin que les résolutions restent en millisecondes. Dans cet article, je montre comment les hiérarchies de cache, les résolveurs anycast et les mécanismes de sécurité peuvent vitesse de recherche et éviter les pannes.
Points centraux
- Réglage TTL: valeurs courtes pour les changements, valeurs longues pour la stabilité
- Hiérarchie du cache: Navigateur, OS, ISP et résolveurs récursifs
- Redondance: multi-fournisseurs et anycast pour une faible latence
- Sécurité: DNSSEC et protection contre l'empoisonnement du cache
- Suivi: rendre visible le taux de hit, la latence et les anomalies
Comment la mise en cache DNS accélère la vitesse des requêtes
Un système intelligent caching Resolver fait gagner un temps réel en gardant les réponses en mémoire au lieu d'interroger les serveurs racine, TLD et d'autorité à chaque requête. Chaque réponse en cache raccourcit le chemin et réduit sensiblement le nombre de sauts externes. J'aligne les TTL de manière à ce que les entrées fréquemment interrogées et rarement modifiées restent valables beaucoup plus longtemps. Pour les zones dynamiques, je limite la validité afin de préserver l'actualité et d'éviter les données obsolètes. Il en résulte un équilibre entre Vitesse et la correction, qui élève durablement la query speed.
Hiérarchie du cache : navigateur, OS, ISP, récursif
J'utilise toute la Chaîne de cacheLe navigateur conserve des entrées très éphémères, le système d'exploitation stocke plus longtemps, les résolveurs du fournisseur d'accès mettent massivement en mémoire tampon et les résolveurs anycast récursifs fournissent globalement des résultats rapides. Ces couches se complètent, raccourcissent le chemin vers l'objectif et réduisent les pics de charge. Les caches d'appareils locaux accélèrent considérablement les requêtes répétées sur la même page. Parallèlement, un cache FAI efficace réduit la bande passante et soulage les serveurs faisant autorité. Si vous souhaitez optimiser cela du côté client, vous trouverez des conseils pratiques dans l'article suivant Mise en cache du client, Le site web de l'OFSP présente les vis de réglage sur les terminaux.
Architecture : propre recourant, porteur et split-horizon
Pour l'architecture, je choisis délibérément entre Forwarding à des résolveurs en amont (par ex. ISP ou Public) et à leur propre pleine récurrence. Un forwarder profite des grands caches chauds du fournisseur et peut simplifier les chemins d'accès au réseau. Je perds toutefois un peu de contrôle sur les politiques, les versions de protocole et les métriques. Avec ma propre récursion, je tiens toutes les ficelles en main : priming des racines, paramètres EDNS, validation, limitation des débits et télémétrie précise. Cela demande plus de travail, mais cela se traduit par des résultats reproductibles. Performance et la stabilité.
Pour les espaces de noms internes et externes, je mise sur Split-Horizon avec des vues séparées. Ainsi, les clients internes atteignent directement les IP internes, tandis que les utilisateurs externes voient les points de terminaison publics. Il est important d'avoir des ACL propres et des TTL cohérents pour éviter les „fuites“ de réponses. Pour les configurations de forwarding, j'évite les cascades ou les boucles et je définis des fallbacks clairs. Je planifie également plusieurs flux ascendants en parallèle afin que la résolution se poursuive sans interruption en cas de panne d'un fournisseur.
Stratégies TTL pour les changements et la stabilité
Je planifie les changements avec TTL-fenêtres : 24-48 heures avant un changement d'IP, je réduis à environ 300 secondes et augmente à 3600 secondes ou plus après le changement. Ainsi, le changement se propage rapidement, alors que le fonctionnement normal avec des TTL plus longs génère moins de requêtes. Des TTL très courts, inférieurs à 300 secondes, n'apportent pas grand-chose, car certains fournisseurs d'accès les ignorent. Pour les contenus dynamiques, je choisis des valeurs modérées (1800-3600 secondes) afin que la flexibilité et l'efficacité restent équilibrées. Je résume les détails concernant les limites et les valeurs mesurées dans une comparaison claire sous Performance TTL ensemble.
Concevoir des zones d'autorité de manière performante
Je pense aussi à la performance autoritaire-côté. Les chemins de résolution courts et plats permettent de gagner des millisecondes mesurables. C'est pourquoi j'évite les longues Chaînes CNAME et, au lieu d'utiliser des CNAME directs, j'ai recours à des fonctions de fournisseur telles que ALIAS/ANAME (si elles sont prises en charge) sur le Zonenapex. Je maintiens le nombre de serveurs de noms faisant autorité entre deux et quatre, diversifiés géographiquement et en termes de réseau. Glue-Records auprès du registre et des délégations correctes empêchent les réponses „boiteuses“. Les paramètres NS et SOA sont délibérément choisis : Un SOA minimum plausible (TTL négatif) contrôle la durée de mise en cache de NXDOMAIN/NODATA, sans fixer éternellement les erreurs.
J'utilise DNSSEC avec Pré-publication/Double-sign, pour que la validation se fasse en continu. Avant les commutations importantes, je vérifie les entrées DS au niveau du parent. Je tiens à disposition à la fois A et AAAA pour que les clients à double pile puissent résoudre sans détours. Lorsque des jokers sont nécessaires, je documente leur impact sur les taux de cache et la gestion des erreurs, car ils peuvent entraîner un nombre excessif de caches négatifs s'ils sont utilisés sans précaution.
Contrôle de la mémoire cache et du flushing dans les résolveurs courants
Je contrôle les Validité actif : dans BIND, je définis max-cache-ttl et neg-max-cache-ttl pour limiter les réponses anciennes ou négatives. Unbound propose des commutateurs similaires, ainsi que le prefetching, qui recharge les entrées très demandées avant leur expiration. Pi-hole permet de cibler la taille du cache et peut conserver longtemps les réponses bloquées afin de répondre sans délai aux domaines publicitaires récurrents. Après une mise à jour importante du DNS, je vide le cache de manière ciblée afin que tous les clients reçoivent des enregistrements frais. Je maintiens ainsi l'équilibre entre performance et précision à un niveau élevé et constant.
Redondance, anycast et configuration multi-fournisseurs
Pour des communications rapides et fiables Résolution j'utilise plusieurs résolveurs récursifs et au moins deux fournisseurs DNS faisant autorité. Un réseau anycast rapproche géographiquement la réponse des utilisateurs et réduit le temps d'aller-retour. Les clients choisissent automatiquement le serveur disponible le plus rapide, ce qui atténue les fenêtres de maintenance et les perturbations isolées. Dans les mesures, une configuration double divise souvent la latence par deux, car la route la plus rapide gagne plus souvent. Ceux qui souhaitent comprendre en détail l'effet sur les temps de chargement trouveront des métriques pratiques sous Temps de charge du résolveur.
Transport et protocoles : UDP, TCP, DoT/DoH/DoQ et EDNS
Les détails du transport font la différence en quelques millisecondes : Le DNS commence généralement par UDP. Je limite volontairement la charge utile EDNS (par exemple à ~1232 octets) pour Fragmentation et d'exclure les problèmes de PMTU. Si une réponse devient plus grande ou si un fragment est perdu, je passe proprement à TCP. Pour les chemins d'accès cryptés, je mets DoT (TLS) ou DoH (HTTPS) avec des sessions réutilisées de longue durée. Cela permet d'économiser des handshake, de réduire la latence et de stabiliser les valeurs p95 en charge. DoQ (QUIC) peut économiser des millisecondes supplémentaires grâce au 0-RTT et au multiplexage, à condition que les deux parties le prennent en charge.
Pour plus de sécurité, je réduis les données supplémentaires inutiles (minimal-responses) et activez Cookies DNS contre le spoofing. Minimisation QNAME préserve la vie privée et réduit les fuites, mais peut augmenter légèrement le nombre de sauts. Je mesure cet effet par zone et l'équilibre par rapport à la latence globale. Il est également important de disposer d'un modèle de timeout et de retry judicieux : des fenêtres de temps initiales courtes, un backoff exponentiel, des requêtes parallèles vers A et AAAA ainsi qu'un repli rapide vers d'autres serveurs de noms si l'un d'entre eux réagit lentement.
Sécurité : DNSSEC, empoisonnement du cache et Stale Answer
Je sécurise les Réponses avec DNSSEC, afin que les clients vérifient de manière cryptographique si un enregistrement est authentique. Sans cette protection, les exploitants risquent des enregistrements manipulés par empoisonnement du cache. En outre, j'utilise la minimisation QNAME et des identifiants randomisés pour réduire encore la surface d'attaque. Je n'utilise les mécanismes de Stale Answer que de manière ciblée : En cas de panne d'autorité de courte durée, un résolveur peut fournir une réponse connue et expirée afin que les services restent accessibles. Après le retour des serveurs de zone, je force une nouvelle validation pour assurer la cohérence et Intégrité ne pas mettre en danger.
ECS et optimisation du CDN
Dans le cas des CDN, le Sous-réseau client EDNS (ECS) en : il permet des réponses proches de l'emplacement, mais augmente considérablement la carence de cache. J'active l'ECS de manière sélective pour les zones qui contiennent de véritables Proximité de l'Edge et limiter la longueur des préfixes afin d'éviter que le cache ne se divise en d'innombrables petits segments. Les mesures montrent souvent qu'un ECS modéré réduit sensiblement la latence p95, tandis qu'une approche trop finement granulaire fait baisser le taux de réussite. C'est pourquoi je mesure par zone, et non de manière globale, et je documente l'influence sur la taille du cache et les temps de réponse.
Monitoring et métriques : comprendre le taux de réussite du cache
Je mesure la Taux de succès par résolveur, en séparant les types d'enregistrement tels que A, AAAA et TXT. Un taux élevé indique une mémoire cache efficace, mais un taux trop élevé pour les TTL longs peut retarder les changements. Outre la latence p50/p95, j'observe les taux NXDOMAIN et SERVFAIL afin de détecter rapidement les requêtes erronées ou bloquées. Si le taux de réponses négatives augmente, je vérifie les zones, les domaines bloqués et les éventuelles fautes de frappe. Des tableaux de bord avec des alertes en direct m'aident à voir immédiatement les aberrations et à query de maintenir une vitesse stable.
Taille de la mémoire cache, Eviction et Prewarming
Je dimensionne le Cache en fonction du QPS, de la diversité des domaines et de la répartition des TTL. Pour Unbound, je contrôle séparément rrset et msg-cache, dans BIND je limite l'utilisation totale et fixe des caps pour les TTL minimum et maximum. Un comportement d'éviction de type LRU empêche les réponses rares et volumineuses de supplanter les hot-keys. Il est judicieux d'utiliser un serve-expired-qui n'intervient qu'en cas de problème d'autorité. Après des déploiements ou des changements de site, je préchauffe le cache de manière ciblée : J'interroge par script les noms d'hôtes Top-N, les CDN-Edges et les upstreams critiques, afin que les premiers utilisateurs puissent déjà profiter d'entrées chaudes.
Mesurer les performances : Outils et benchmarks
Pour des résultats reproductibles Tests je mets en place des séries de mesures avec des questions identiques, cache froid puis cache chaud. Je varie les sites par VPN ou serveur Edge pour voir l'effet d'Anycast. Chaque série contient plusieurs répétitions afin d'éviter que les valeurs aberrantes ne dominent. Ensuite, je compare les valeurs de la médiane et du 95e percentile, car les utilisateurs ressentent surtout les pics lents. Je corrèle les données de résultats avec le taux de cache et le TTL afin d'évaluer l'efficacité de l'anycast. Causes derrière les latences.
Runbooks et tuning spécifique au système d'exploitation
Je tiens Runbooks prêt : si SERVFAIL augmente, je vérifie d'abord l'accessibilité des serveurs faisant autorité, puis la validation DNSSEC et les éventuels problèmes de MTU/fragmentation. En cas de pics NXDOMAIN, je recherche les erreurs de frappe, les zones bloquées ou les sous-domaines modifiés. En cas d'erreurs de validation (BOGUS), je vérifie DS/KSK/ZSK et active temporairement „serve-stale“, mais jamais de désactivation aveugle des DNSSEC sans plan.
Côté client, des flushs ciblés aident : sous Windows, je vide le cache avec ipconfig /flushdns. Sur macOS, je mets sudo killall -HUP mDNSResponder ou sudo dscacheutil -flushcache en fonction de la version. Dans les configurations Linux, j'utilise resolvectl flush-caches (systemd-resolved) ou sudo service nscd reload. Je supprime les caches internes au navigateur en redémarrant ou en utilisant des menus de débogage spécifiques au réseau. Ces étapes accélèrent sensiblement les déploiements lorsque certains clients conservent encore d'anciennes entrées.
Exemples de la pratique : Boutique en ligne, CDN et Pi-hole
Une boutique avec de fréquents Modifications pour les IP ou les points de terminaison, 600-1800 secondes de TTL, combinées à une mise en cache agressive du navigateur et du système d'exploitation, fonctionnent bien. Pour les pages statiques ou les CDN d'images, je fixe 86400 secondes, car les modifications sont rares et la charge diminue nettement. Pour les campagnes saisonnières, je réduis le TTL à l'avance, je distribue les nouvelles cibles et je le remets ensuite à un niveau plus élevé. J'utilise Pi-hole comme front de cache local pour accélérer les clients du réseau domestique et bloquer de manière fiable les domaines gênants. Grâce à des règles claires et à une taille de cache suffisante, le service maintient les Temps de réponse bas.
SLOs et planification des capacités
Je définis clairement SLOs, pour que l'optimisation reste mesurable : Pour les caches chauds, je vise un p95 inférieur à 20-30 ms, pour les résolutions froides, inférieur à 120-150 ms. Le taux de succès pour A/AAAA est idéalement supérieur à 85 %, le taux de réponses négatives (NXDOMAIN/NODATA) reste dans une plage de pourcentage à un chiffre. En charge, je prévois suffisamment de marge de manœuvre pour que les POP isolés ou les pannes de fournisseur d'accès soient compensés sans saut de latence. Côté matériel, je privilégie une grande quantité de RAM pour les grands caches, des performances rapides à un seul cœur pour la validation/signatures et des NIC fiables ; pour DoT/DoH, je prévois un déchargement TLS ou un réemploi de session.
Au niveau du réseau, je limite les risques d'amplification avec RRL (Response Rate Limiting) et je mets en place des ACL strictes. Je répartis les recourants géographiquement, je les intègre par anycast et je les mets à l'échelle horizontalement lorsque le QPS et la diversité des zones augmentent. Des tests de capacité périodiques simulent des pics (lancement de produit, campagne TV) afin que les résolveurs fonctionnent déjà dans la zone verte. Toutes les modifications sont contrôlées via Canaries et ne sont déployées que lorsque les métriques sont stables.
Configurations recommandées par scénario
Je considère la suivante Matrice pour définir des valeurs de départ et les affiner ensuite en fonction des données. Le tableau présente les TTL typiques, les utilisations, les avantages et les risques potentiels. Ensuite, j'adapte les valeurs en fonction du taux de réussite, de la fréquence des changements et de l'emplacement des utilisateurs. C'est justement pour les projets globaux qu'il vaut la peine de segmenter par zone ou sous-domaine. Ainsi, la Contrôle flexible, sans affaiblir la performance globale.
| TTL | Utilisation | Avantages | Risques | Remarque |
|---|---|---|---|---|
| 300 s | Déménagements prévus, tests | Propagation rapide | Charge d'interrogation plus élevée | Réduire au préalable, augmenter après le déménagement |
| 900 s | Points finaux API (modéré) | Un bon équilibre | Taux de cache moyen | Convient pour les services avec des changements de jour en jour |
| 1800 s | Boutiques en ligne, CMS | Latence solide, flexible | Léger retard dans les corrections à chaud | Combiner avec les drapeaux de fonctionnalités |
| 3600 s | Sites stables | Moins de charge DNS | Mises à jour plus lentes | Bonne valeur par défaut |
| 86400 s | Contenu statique, CDN | Efficacité maximale de la mémoire cache | Retard important dans les modifications | N'utiliser que pour des adaptations rares |
En bref, je résume : Voici comment je le mets en œuvre
Je commence par MétriquesLe taux de réussite, la latence p95 et les taux d'erreur m'indiquent les plus grands leviers. Ensuite, je règle les TTL de manière différenciée par type d'enregistrement et sous-domaine, je les diminue avant les modifications et les augmente après une distribution réussie. Parallèlement, j'établis une redondance avec des résolveurs anycast et deux fournisseurs d'accès faisant autorité, afin que les utilisateurs obtiennent toujours le chemin le plus rapide. DNSSEC et des règles de cache propres protègent contre les manipulations et empêchent les réponses obsolètes. Si la structure de base est stable, je continue à la peaufiner par petites étapes et je vérifie chaque changement de manière mesurable jusqu'à ce que la DNS Résolveur Performance durablement convaincu.
