Résumé

  • Le compte rendu de Gaurav Kansal attribue au résolveur 1.10.10.10 du NIC une moyenne DNS de 27,0 ms et une moyenne ping de 17,3 ms durant une comparaison RIPE Atlas de 91 jours. Ce sont les chiffres publiés par l’auteur, pas ceux d’un audit indépendant.
  • L’intérêt de l’étude tient aussi à ses limites explicites : les noms testés, très populaires, sont probablement souvent en cache ; les échecs et pertes n’ont pas été filtrés ; les nombres d’observations divergent ; et les fichiers publics consultés ne permettent pas de recalculer les moyennes.

Un chiffre rapide n’est pas un verdict

Dans son billet de septembre 2026, « Monitoring 1.10.10.10 with RIPE Atlas Probes », Gaurav Kansal compare l’adresse DNS publique du National Informatics Centre (NIC), 1.10.10.10, à Cloudflare, Google et Quad9. La fenêtre annoncée va du 13 novembre 2025 au 11 février 2026. Les valeurs ci-dessous sont celles que le billet rapporte ; elles n’ont pas été recalculées ici à partir des mesures brutes.

Résolveur Ping moyen Observations ping Réponse DNS moyenne Observations DNS
NIC 1.10.10.10 17,3 ms 1 038 738 27,0 ms 580 916
Cloudflare 1.1.1.1 14,8 ms 1 047 581 43,2 ms 528 540
Google 8.8.8.8 14,8 ms 1 039 961 32,1 ms 596 800
Quad9 9.9.9.9 55,8 ms 1 050 441 112,1 ms 577 032

La moyenne DNS publiée place le NIC devant les trois comparateurs, pour cette charge et cette période. La moyenne ping est en revanche de 2,5 ms supérieure à celles de Cloudflare et Google. Les deux résultats ne se contredisent pas : un ping mesure un aller-retour réseau, tandis qu’une requête DNS sollicite un autre chemin et un autre traitement. Ils ne permettent pas non plus de désigner un « meilleur » résolveur en général. Il faudrait d’abord définir ce que signifie meilleur : rapidité d’une réponse réussie, disponibilité, exactitude, protection de la vie privée, comportement face aux menaces ou facilité de reprise après incident.

Cette distinction est précisément ce qui rend le travail intéressant. Un responsable technique associé à un service public ne se contente pas d’annoncer une adresse : il publie une comparaison avec des alternatives connues, une période, des volumes et certaines réserves de méthode. Cela rend l’affirmation plus examinable qu’un slogan. Mais la lisibilité d’un tableau n’élargit pas ce qu’il a mesuré. La latence reste un résultat situé, qui dépend des sondes, des noms demandés et des règles de collecte.

Une charge de noms très particulière

Le billet explique que chaque jour, le test DNS reprenait les dix noms les plus consultés dans le trafic du NIC, puis les envoyait aux quatre résolveurs. La même liste quotidienne était utilisée pour les quatre services ; elle changeait d’un jour à l’autre. C’est une propriété utile du protocole : les comparateurs recevaient la même sélection au cours d’une journée, plutôt que des listes arbitraires différentes.

Cette sélection a aussi une conséquence que Kansal signale lui-même : ces noms sont probablement souvent présents dans les caches. Un résolveur qui possède déjà la réponse peut répondre sans refaire tout le parcours hiérarchique du DNS. Cela n’invalide pas le test. Les noms fréquents comptent dans l’usage ordinaire, et la capacité à les servir rapidement a une valeur opérationnelle. Mais la comparaison décrit davantage des réponses à des noms populaires qu’une résolution à froid de noms rarement demandés. Elle ne démontre donc pas que toute recherche, tout domaine ou toute première requête serait aussi rapide.

Le choix du corpus reflète en outre la perspective du NIC : les noms proviennent de son trafic. Cela peut être parfaitement pertinent pour observer une charge courante dans son environnement. Cela n’en fait pas une enquête sur les usages de toute l’Inde, ni même sur toutes les personnes susceptibles d’utiliser un résolveur public. Les sondes Atlas constituent des points d’observation ; le trafic du NIC fournit le jeu de noms. Ces deux populations ne sont pas un recensement commun.

Le ping demande encore moins d’interprétation : il mesure le temps de réponse d’un paquet ICMP entre une sonde et une adresse. Il renseigne sur la joignabilité et le trajet à cet endroit. Il ne vérifie pas qu’une réponse DNS est correcte, que le site final est rapide, ni qu’une application reste disponible. Additionner ping et DNS dans un classement synthétique ferait disparaître ces différences au lieu de les expliquer.

Beaucoup de mesures, des dénominateurs différents

Les volumes annoncés sont considérables : plus d’un million d’observations ping par service et plus d’un demi-million d’observations DNS. Un grand nombre aide à caractériser les résultats collectés ; il ne révèle pas à lui seul la population de référence, les résultats absents ou le calcul de la moyenne. Les comptes DNS vont de 528 540 pour Cloudflare à 596 800 pour Google. Les comptes ping varient également.

Kansal dit ne pas avoir filtré les pertes de paquets ni les requêtes échouées. Cette déclaration est utile : elle évite de faire croire que les résultats défavorables auraient été retirés. Elle ne précise toutefois pas, à elle seule, comment un échec sans durée de réponse est entré dans une moyenne, comment les délais d’attente ont été enregistrés, ni si les totaux signifient tests programmés, enregistrements reçus ou réponses réussies. Ces définitions déterminent ce que le dénominateur veut dire.

Un fichier public du dépôt associé illustre l’écart sans le résoudre : le relevé DNS du 13 novembre 2025 fournit des nombres de mesures par adresse, pas des latences individuelles. Les volumes de cette journée diffèrent entre résolveurs. Une seule journée ne prouve ni panne, ni biais, ni erreur dans les moyennes. Elle indique simplement pourquoi un lecteur aurait besoin des règles de comptage et des résultats sous-jacents avant de refaire le calcul.

Le dépôt GitHub 1.10.10.10-tests et son README présentent des comptes quotidiens, des répertoires de données et des graphiques. Dans l’arborescence publique vérifiée pour cette enquête, les fichiers clairement identifiés comme scripts de collecte, identifiants de mesures ou journaux complets de latence n’étaient pas visibles. C’est une observation circonscrite à cette arborescence, pas l’affirmation que ces éléments n’existent nulle part. En l’état, les éléments repérés ne suffisent pas, à eux seuls, à reproduire la moyenne de 91 jours.

La moyenne masque par ailleurs la distribution. Elle ne dit pas si 27 ms est proche du résultat typique, si quelques périodes très lentes ont pesé dans le total, ou si certaines zones connaissent un comportement différent. Les percentiles, séries quotidiennes et répartitions par sonde répondraient à d’autres questions. Sans eux, les chiffres publiés sont un résumé utile, mais pas une description complète de la qualité vécue.

Des sondes distribuées ne sont pas un auditeur indépendant

RIPE Atlas élargit les points depuis lesquels une mesure peut être lancée ; la documentation du fonctionnement d’Atlas et des mesures définies par les utilisateurs décrit cette infrastructure. Cela apporte une dispersion géographique et des perspectives réseau variées. Mais la plateforme ne choisit pas ici la liste de domaines, l’interprétation des moyennes ou la publication de Kansal. Des sondes hébergées par des tiers ne transforment pas une étude rédigée par l’opérateur en audit indépendant, et RIPE NCC n’est pas présenté comme ayant validé les résultats.

L’échantillon annoncé — généralement 130 à 145 sondes situées en Inde — reste un ensemble de points disponibles, pas un tirage pondéré de tous les opérateurs, réseaux d’accès et utilisateurs du pays. La mesure peut être précise pour ces points tout en laissant ouvertes les questions de généralisation. Multiplier les paquets n’équivaut pas à diversifier les réseaux observés. Pour prétendre à une moyenne nationale, il faudrait une base d’échantillonnage, des règles de sélection et des pondérations explicites.

Le service, son rôle et les limites de l’autorité

APNIC présente Kansal comme Joint Director (IT) au NIC et indique qu’il pilote Sarvagya, ou Bharat Public DNS, dans sa notice d’auteur. Son billet APNIC est une contribution signée ; la notice de publication précise que les vues de l’auteur lui sont propres. Cette affiliation situe son travail, mais n’en fait pas une parole représentative de tous les utilisateurs indiens.

Des documents officiels de configuration du gouvernement nomment les adresses 1.10.10.10 et 2409::1 : le guide de cybersécurité du CGA et un article de NIC Informatics de juillet 2025 les citent dans un contexte de configuration ou de durcissement. Cela prouve une recommandation documentaire, pas combien d’appareils l’appliquent, ni son adoption à l’échelle nationale, ni la qualité de l’expérience obtenue.

Le profil personnel de Kansal formule aussi des affirmations de portée, de localisation des données et de filtrage. Elles doivent rester attribuées à son site personnel : la comparaison de latence ne les vérifie pas. Un temps de réponse n’établit ni la politique de conservation des journaux, ni la précision d’un filtre, ni la protection contre les attaques. Ces propriétés nécessitent des preuves et des évaluations distinctes.

La norme technique de base est plus modeste : le DNS traduit des noms en informations d’adressage, comme l’expose le RFC 1034. La performance d’un résolveur n’est qu’un élément de sa valeur publique. Les conséquences des pannes, le mécanisme de bascule, la gouvernance des changements, la confidentialité et l’existence d’alternatives comptent tout autant lorsqu’une organisation configure de nombreux postes.

Le prochain palmarès peut devenir vérifiable

Une prochaine publication pourrait rendre le résultat beaucoup plus facile à auditer sans modifier le principe de la comparaison. Elle pourrait associer chaque série à des identifiants de mesures Atlas, préciser les sondes retenues et leurs changements au fil du temps, publier le type exact de requête et la configuration, et définir les délais d’attente, tentatives et échecs. Des résultats bruts expurgés des informations sensibles, accompagnés du code d’agrégation, permettraient de vérifier la moyenne.

Les moyennes pourraient rester dans le résumé, à côté de médianes, percentiles élevés, séries par jour et taux de réponses manquantes. Il faudrait aussi distinguer les tests de noms populaires en cache des tests à froid. D’autres évaluations porteraient séparément sur la disponibilité, l’exactitude des réponses, DNSSEC, la confidentialité, le filtrage et la reprise après incident. Aucune de ces caractéristiques ne découle automatiquement d’une latence plus basse.

Le décalage temporel importe enfin : la fenêtre se termine le 11 février 2026, tandis que le billet date du 17 septembre. C’est un résultat historique, non une mesure de septembre. Une cadence régulière, avec des définitions stables ou des changements documentés, permettrait de suivre les évolutions au lieu de transformer un instantané en promesse durable.

La lecture la plus solide n’est donc ni « le NIC bat les grands résolveurs » ni « l’étude ne vaut rien ». Le dossier public soutient une affirmation plus précise : sur les sondes, les noms, la période et les règles rapportés, la moyenne DNS du NIC est plus basse que celles des trois alternatives, tandis que sa moyenne ping est légèrement plus élevée que celles de Google et Cloudflare. L’auteur publie assez de contexte pour susciter une discussion sérieuse ; la documentation ouverte ne permet pas encore de recalculer complètement les moyennes.

Cette frontière est le vrai sujet du profil. Kansal rend visible une partie d’un service public par une comparaison opérationnelle. Les lecteurs peuvent reconnaître cette contribution sans faire du tableau un audit national ni de son auteur le porte-parole de chaque utilisateur. Un scorecard devient plus utile lorsque ses limites sont visibles et que sa prochaine édition permet à d’autres de contrôler les calculs.

Sources