Résumé
- Pour 116 050 253 essais sans réponse, APNIC Labs a reçu 9 685 775 212 requêtes sur son serveur faisant autorité. Les totaux donnent 83,46 requêtes par nom de test, contre 3,43 pour le témoin positif, 3,93 pour NODATA, 4,40 pour NXDOMAIN, 11,47 pour REFUSED et 51,73 pour SERVFAIL.
- Ces écarts relient nettement l’état de la réponse à la charge observée dans ce dispositif. Ils ne disent pas si la répétition vient du terminal, du stub, d’un relais, d’un moteur récursif, d’une ferme de résolveurs ou de plusieurs étages à la fois.
- Deux moyennes diffèrent entre le corps du billet et son tableau récapitulatif. Les comptes publiés permettent de refaire le calcul, pas de deviner l’intention de l’auteur. Une exploitation sérieuse doit donc conserver formule, dénominateur, topologie et attribution inconnue.
Le serveur voit les requêtes, pas la chaîne des décisions
Le chiffre le plus spectaculaire du billet du 4 septembre est exact au paquet près : 9 685 775 212 requêtes observées dans la condition où le serveur ne répondait pas. Le tableau donne 116 050 253 essais. Leur rapport est 83,4619.
Cette précision ne remonte pourtant pas jusqu’à l’acteur.
Le point de départ était un script intégré à une publicité en ligne. Il demandait à un terminal de résoudre un nom aléatoire, propre à l’essai. Entre ce terminal et le serveur d’APNIC peuvent intervenir la bibliothèque locale, plusieurs adresses de résolveurs configurées, un relais, un répartiteur frontal, un ensemble de moteurs récursifs, puis un choix d’adresse ou de transport. Chacun peut émettre, regrouper, répéter ou réorienter du travail.
Le journal faisant autorité recueille le résultat qui atteint sa frontière. Il ne reçoit pas, avec chaque paquet, un historique certifié des décisions prises en amont. Écrire qu’« un résolveur a envoyé 83 requêtes » ajouterait donc une identité absente des données. Parler de 83 « retransmissions » serait également trompeur : une application moderne peut demander séparément A, AAAA et HTTPS pour le même nom.
L’unité publique est un nom de test unique. Ce n’est ni un clic humain, ni une résolution applicative, ni une transaction de stub, ni une opération récursive identifiée. Cette limite ne rend pas la mesure faible. Elle la rend correctement située : APNIC dispose d’un registre de charge à la frontière faisant autorité, pas encore d’un registre de garde retraçant l’origine de chaque reprise.
Une matrice de réponses, pas une constante universelle
Les noms aléatoires empêchaient une réponse déjà mise en cache pour le même nom. La zone n’était pas signée. Un seul serveur faisant autorité, joignable en IPv4 et IPv6, acceptait UDP et TCP, sans DoT ni DoH. Les réponses étaient courtes et non tronquées. Les requêtes arrivées dans les vingt-quatre heures suivant le déclenchement ont été comptées.
À partir des totaux publiés, on obtient :
| État du serveur | Essais | Requêtes | Requêtes par essai recalculées | Par rapport au témoin |
|---|---|---|---|---|
Réponse positive A/AAAA |
254 894 985 | 875 316 423 | 3,43 | 1,00× |
NOERROR/NODATA |
115 571 398 | 454 213 932 | 3,93 | 1,14× |
NXDOMAIN |
115 750 503 | 509 410 787 | 4,40 | 1,28× |
REFUSED |
115 415 259 | 1 324 355 211 | 11,47 | 3,34× |
SERVFAIL |
138 643 924 | 7 171 673 166 | 51,73 | 15,06× |
| Aucune réponse | 116 050 253 | 9 685 775 212 | 83,46 | 24,30× |
Le classement a du sens. Une réponse positive et les deux négations déterminées restent proches de quatre requêtes par essai. REFUSED monte nettement. SERVFAIL et le silence changent d’ordre de grandeur. NXDOMAIN affirme que le nom n’existe pas ; NODATA que le nom existe sans le type demandé. REFUSED exprime un refus d’exécuter l’opération. SERVFAIL laisse ouverte l’idée qu’un autre serveur, une autre adresse, un autre transport ou un instant ultérieur puisse réussir. Le silence abandonne l’interprétation aux temporisateurs.
Mais une sémantique compatible avec une reprise n’en désigne pas l’auteur. Le tableau ne ventile ni les logiciels, ni les configurations, ni les chemins. Il ne dit pas combien de demandes équivalentes ont été fusionnées. Il ne montre pas la distribution qui se cache derrière la moyenne. Ces valeurs décrivent le montage d’APNIC ; elles ne sont pas des multiplicateurs permanents attachés aux codes DNS.
Le socle attendu comporte déjà plusieurs questions
Dans l’essai NXDOMAIN, 48 % des terminaux ont demandé à la fois A et AAAA, 51 % seulement A, et 1 % seulement AAAA. Des requêtes HTTPS ont été vues pour 39 % des terminaux. Avec cette combinaison, APNIC estime à 218 millions le nombre de requêtes si chaque type utilisé n’était demandé qu’une fois.
Le serveur en a reçu 509 410 787. La différence, 291 919 927, est classée comme répétition. Sur 115 750 503 essais, 67 316 541 se sont achevés avec au plus une requête par type utilisé. Les 48 433 962 autres concentrent les répétitions, soit 6,03 en moyenne dans ce sous-ensemble.
Sans cette base, on confondrait trois questions légitimes avec trois tentatives du même paquet. Sans le compteur de répétitions, on réduirait au contraire une résolution à son résultat final et l’on ferait disparaître près de 292 millions de requêtes supplémentaires.
La portée géographique doit voyager avec le dénominateur. Les terminaux provenaient des zones servies par Google Ads ; le billet cite la Russie comme exception majeure. Cela donne une très large observation, pas un échantillon probabiliste de tous les internautes. Le serveur unique à double pile est un instrument contrôlé, non la copie d’une flotte multi-NS ordinaire. L’absence de DNSSEC, de chiffrement et de troncature retire des variables de cette expérience ; elle ne démontre pas qu’elles seraient sans effet ailleurs.
Deux divergences numériques sont elles-mêmes instructives
Le paragraphe SERVFAIL attribue 51,29 à la moyenne par essai et 51,59 à la moyenne des répétitions. Or 7 171 673 166 divisé par 138 643 924 donne 51,7273, arrondi à 51,73 dans le tableau. Après retrait des 3 702 576 essais sans répétition, 6 920 490 780 répétitions divisées par 134 941 348 donnent 51,2852, soit 51,29.
Pour l’absence de réponse, le corps du texte imprime 11,6050,253 essais et une moyenne de 82,6. Le tableau donne 116 050 253 essais et 83,46. Le total de 9 685 775 212 divisé par le dénominateur du tableau produit 83,4619. La moyenne de 83,38 répétitions est elle aussi reproductible à partir des comptes détaillés.
Il ne faut ni masquer ces écarts, ni en déduire que toute l’expérience s’effondre. Les totaux, la formule et l’arrondi permettent de distinguer une erreur de transcription d’une erreur de mesure. Seul l’auteur peut préciser la valeur qu’il voulait placer dans le paragraphe ; le calcul peut seulement établir celle qui découle des nombres publiés.
Une moyenne devrait donc être publiée avec son reçu : numérateur, dénominateur, exclusions, formule et version du tableau. C’est une discipline modeste, mais elle empêche une phrase fluide d’obtenir plus d’autorité que les données qui la soutiennent.
Les hypothèses de 2019 ne remplissent pas le champ manquant
En 2019, APNIC avait analysé plus finement les reprises après NXDOMAIN. L’étude distinguait des pics temporels, des requêtes répétées depuis une même adresse apparente et des groupes d’adresses partageant un préfixe. Elle examinait Happy Eyeballs, la perte de paquets, des temporisateurs agressifs, la concentration des relais et les fermes de résolveurs. Le regroupement par /24 ou /48 était présenté comme approximatif.
Ces mécanismes restent plausibles. Ils ne transforment pas la mesure agrégée de 2026 en attribution certaine. Une adresse visible peut cacher plusieurs moteurs ; plusieurs adresses peuvent appartenir au même service. Deux résolveurs configurés sur un terminal peuvent finir dans le même système récursif. Une nouvelle requête peut entrer dans une file alors que la précédente n’est pas terminée. Une perte peut toucher la question ou la réponse.
Le nouveau billet conserve honnêtement cette incertitude : il demande si le phénomène vient de l’implémentation récursive ou d’architectures séparant distributeurs frontaux et moteurs dorsaux. Une reprise éditoriale ne doit pas supprimer le point d’interrogation.
La documentation Microsoft fournit un exemple concret, pas une clé universelle. Elle montre comment le client Windows élargit ses requêtes selon le nombre de serveurs configurés quand il n’obtient aucune réponse, tandis qu’une erreur de nom arrête la recherche. APNIC n’a pas établi que les terminaux de l’échantillon exécutaient ce client ou ce calendrier. Un manuel explique une branche possible ; il ne renseigne pas rétroactivement une variable non observée.
Les RFC bornent les reprises sans identifier le paquet
RFC 9520 limite à deux reprises, après l’envoi initial, une même question destinée à une adresse de serveur par un même transport. Il impose aussi de mémoriser les échecs de résolution pendant au moins une seconde et au plus cinq minutes afin qu’une demande correspondante n’engendre pas immédiatement un nouveau travail en amont.
Ces règles répondent au risque de tempête. Elles ne donnent pas au serveur faisant autorité la possibilité de relier chaque paquet reçu à une seule décision normative. Un résolveur peut explorer une autre adresse ou un transport compatible. Plusieurs clients peuvent être regroupés dans une transaction récursive ; une action du client peut aussi se déployer dans plusieurs systèmes.
RFC 2308 définit la mise en cache de NXDOMAIN et NODATA et son traitement plus ancien des échecs serveur. RFC 8914 autorise un Extended DNS Error à préciser le diagnostic, tout en interdisant à cette information de modifier le traitement du RCODE. Ces mécanismes rendent l’état plus lisible. Ils n’autorisent jamais à répondre faussement NXDOMAIN ou NODATA pour économiser du trafic.
La bonne frontière est donc locale. Celui qui modifie les temporisateurs, le choix de serveur, la fusion des demandes ou le cache d’échec doit observer l’effet à l’endroit où cette décision est prise. Le compteur d’APNIC peut servir de signal externe ; il ne peut pas remplacer ce contrôle interne.
Un reçu minimal pour la prochaine mesure
Le prochain rapport devrait conserver la fenêtre de l’expérience, le canal de déclenchement, les zones non couvertes et l’unité exacte. Il devrait montrer les types attendus avant de qualifier le surplus de répétition, puis enregistrer la construction de la réponse, le nombre de serveurs, les familles d’adresses, l’anycast éventuel, les transports, DNSSEC, la taille et la troncature.
Les comptes bruts, formules, arrondis et distributions doivent accompagner la moyenne. Surtout, les champs non observés doivent rester non renseignés. Si les étages stub, relais et récursif ne sont pas instrumentés séparément, leur part demeure inconnue.
Dans un essai contrôlé et respectueux de la vie privée, un opérateur peut compter les demandes entrantes, les groupes fusionnés, les transactions récursives, les reprises sur le même triplet adresse/transport et les essais d’une autre voie. Sans cette garde, le rapport doit s’arrêter à la frontière faisant autorité.
APNIC a déjà montré que la différence de coût mérite l’attention. La suite utile n’est pas de baptiser la tempête plus sévèrement. C’est de produire une mesure capable d’indiquer quelle couche a exercé quel droit de recommencer.
Sources
- APNIC Blog — What part of ‘No!’ is so hard for the DNS understand?
- APNIC Blog — No! (étude de 2019)
- Microsoft Learn — DNS client resolution timeouts
- RFC 1035 — Domain names: implementation and specification
- RFC 2308 — Negative Caching of DNS Queries
- RFC 8914 — Extended DNS Errors
- RFC 9520 — Negative Caching of DNS Resolution Failures
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé au Cercle stratégique
Cercle stratégique
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre le Cercle stratégiqueRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance





