Requêtes DNS en double : le coût caché que votre resolveur vous fait payer
Le coût caché de la duplication des requêtes DNS : pourquoi votre serveur récursif fait du gaspillage
Tu connais sûrement la notion de « tragédie des communs » en économie. Ce principe décrit comment des ressources partagées finissent par être surexploitées parce que ceux qui les consomment ne paient pas directement la note. Figure-toi que le même mécanisme existe dans l'écosystème DNS — et ça change pas mal la façon dont on voit son resolver.
Le repas gratuit dans la tête
Dans le monde DNS, les requêtes sont essentiellement gratuites pour les resolvers récursifs. C'est un peu comme ces serviettes en papier à volonté dans un fast-food — pourquoi se limiter quand tout est à portée de main ?
Le problème, selon l'angle NameOcean, c'est que quelqu'un d'autre encaisse les conséquences. Le nameserver faisant autorité doit traiter chaque requête, générer une réponse, consommer de la bande passante — pendant que le resolver ne paie rien pour son zèle excessif.
Pourquoi ce comportement de sur-requêtage ? Logique élémentaire : si un paquet UDP se perd en route, pourquoi attendre un timeout quand on peut renvoyer une requête instantanément ? Si les deux requêtes passent, on ignore la deuxième. Si la première échoue, la seconde pourrait réussir — et on a gagné quelques millisecondes précieuses.
Astucieux, certes. Mais pas vraiment fair-play.
Ce que disent les chiffres
Là, ça devient révélateur. L'analyse des données de mesure APNIC Labs de juin 2026 montre des écarts régionaux assez marqués :
| Région | Taux de duplication | |--------|---------------------| | Sous-continent indien | 61% | | Chine/Hong Kong | 47% | | Moyenne mondiale | 38% | | Amérique du Nord | 28% | | Europe | 27% |
Ces chiffres font réfléchir. En moyenne, presque quatre requêtes sur dix sont des doublons. Au Pakistan, en Inde et compagnie, on passe à plus de six sur dix. Et parfois, c'est pire — certaines requêtes sont répétées 5, 10, voire 20 fois avant que le resolver n'abandonne.
Pourquoi ça devrait t'intéresser ?
Chez NameOcean, on héberge le DNS de milliers de domaines. Donc ce n'est pas qu'un problème théorique pour nous. Quand tu gères des nameservers faisant autorité à grande échelle, la duplication des requêtes devient un vrai défi opérationnel.
Pense-y : chaque requête en double, c'est des ressources de calcul gaspillées, du trafic réseau inutile, et de la latence accrue pour tout le monde. Si tu es une startup qui construit des applications qui comptent sur une résolution DNS rapide et fiable, cette inefficacité impacte directement l'expérience de tes utilisateurs.
Pour les développeurs qui bossent sur des systèmes haute performance, comprendre le comportement DNS est essentiel. Si ton application effectue des lookups répétés pour le même domaine, tu ne consommes pas seulement tes propres ressources — tu contribues aussi à la charge des serveurs faisant autorité que tu interroges.
La voie à suivre
La communauté DNS a conscience de ces problèmes depuis des années. Des efforts sont en cours pour améliorer la situation. DNS-over-HTTPS (DoH) et DNS-over-TLS (DoT) amènent le chiffrement dans le DNS, ce qui aide sur certains fronts. Les extensions EDNS Client Subnet (ECS) permettent aux resolvers de mettre en cache les réponses plus efficacement.
Mais le problème fondamental — « les requêtes sont gratuites » — reste largement non résolu. Tant qu'il n'y aura pas de mécanisme pour facturer aux resolvers récursifs le coût de leur comportement, on continuera à voir ces taux de duplication inflationnistes.
Pour l'instant, le mieux c'est d'être conscient du problème. Si tu construis des systèmes qui dépendent fortement des lookups DNS, réfléchis à des stratégies de mise en cache intelligentes. Utilise des outils comme dig pour investiguer ce qui se passe vraiment avec tes requêtes. Et si tu es client NameOcean, rassure-toi : notre infrastructure est conçue pour gérer ces patterns du monde réel de manière efficace.
La tragédie des communs continue — mais au moins, maintenant, tu la comprends mieux.