Resumen

  • El informe de Gaurav Kansal atribuye al resolver público 1.10.10.10 del NIC una media DNS de 27,0 ms y una media de ping de 17,3 ms durante una comparación de 91 días con RIPE Atlas. Son cifras comunicadas por el autor, no una auditoría independiente.
  • La utilidad del estudio está ligada a sus límites: los dominios populares probablemente ya estaban en caché, no se filtraron fallos ni pérdida de paquetes, los recuentos no coinciden y los archivos públicos revisados no bastan para recalcular los promedios.

Una clasificación demasiado fácil de resumir

En septiembre de 2026, Gaurav Kansal publicó “Monitoring 1.10.10.10 with RIPE Atlas Probes”, una comparación de la dirección pública del National Informatics Centre (NIC), 1.10.10.10, con Cloudflare, Google y Quad9. La ventana reportada va del 13 de noviembre de 2025 al 11 de febrero de 2026. Los promedios y volúmenes de la tabla son los que declara el autor; no los recalculé a partir de mediciones elementales.

Resolver Ping medio Observaciones de ping Respuesta DNS media Observaciones 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

Para las consultas DNS de este ensayo, la media publicada del NIC es la más baja. Para ping, Google y Cloudflare aparecen 2,5 milisegundos por debajo del NIC. No hay contradicción: una medición observa el tiempo de respuesta DNS y la otra el viaje de ida y vuelta de un paquete ICMP. Tampoco hay base para proclamar un ganador general. «Mejor» podría significar rapidez cuando hay respuesta, disponibilidad, exactitud, privacidad, seguridad o recuperación ante fallos. El estudio no mide todas esas propiedades.

El valor del trabajo está en hacer medible una parte del servicio público y en acompañar la cifra con detalles del método. Una comparación pública frente a alternativas reconocibles es más comprobable que una afirmación promocional sin denominador. Pero un cuadro claro no amplía la pregunta que se hizo. Los tiempos dependen de dónde estaban las sondas, qué nombres se consultaron, cómo estaban las cachés y qué ocurrió con los resultados que no respondieron.

La lista diaria condiciona el resultado

Según el post, cada día se eligieron los diez dominios más consultados en el tráfico de NIC y se probaron los mismos diez frente a los cuatro resolvers. La lista cambiaba diariamente. Mantener iguales los nombres para cada proveedor en una jornada ofrece una comparación controlada dentro de ese conjunto: evita comparar listas diferentes por accidente.

Pero se trata de nombres populares dentro del tráfico de NIC. El autor señala que era probable que muchas respuestas estuvieran en caché. Si un resolver ya tiene la respuesta guardada, puede contestar sin repetir las consultas necesarias para resolver desde cero. Eso no vuelve inútil el ensayo: atender nombres frecuentes forma parte del uso cotidiano. Sí acota su interpretación. El resultado se acerca a una comparación de respuestas a nombres populares que probablemente se repiten, no a una prueba de búsquedas frías, dominios raros o cualquier nombre posible.

La lista también revela desde qué perspectiva se define «lo común»: la del tráfico del NIC. Ese enfoque puede ser razonable para observar una carga operativa concreta, pero no demuestra que los diez nombres representen a todas las redes o personas de India. Las sondas de RIPE Atlas son los puntos desde los que se mide; el tráfico del NIC determina el repertorio de nombres. Son marcos distintos, ninguno equivalente a un censo nacional.

El ping tiene otro alcance. Mide la respuesta ICMP y el recorrido desde una sonda hasta una dirección. Puede decir algo sobre conectividad y latencia del trayecto, pero no sobre si una respuesta DNS es correcta, si una página se carga con rapidez o si una aplicación permanece disponible. Mezclar ping y DNS en una sola puntuación ocultaría información en vez de sintetizarla con rigor.

Más de un millón de observaciones no resuelven el denominador

El volumen llama la atención: se reportan más de un millón de mediciones de ping por resolver y más de medio millón de DNS. Un volumen alto puede hacer más estable un resumen de lo efectivamente observado, pero no aclara por sí mismo qué cuenta como observación elegible ni cómo se trataron las ausencias. Los recuentos DNS van de 528.540 para Cloudflare a 596.800 para Google; los de ping también difieren.

Kansal dice que los scripts no filtraron la pérdida de paquetes ni las consultas fallidas. Esa aclaración importa: el informe no describe un promedio construido simplemente borrando los resultados desfavorables. Aun así, «no filtrar» no explica cómo entra una consulta sin tiempo de respuesta en el promedio, cuándo se considera agotado el plazo, si hay reintentos o si los recuentos representan pruebas programadas, registros devueltos o respuestas exitosas. La definición del denominador cambia la lectura de la media.

Un archivo del repositorio muestra una parte del problema, sin resolverla. El fichero de recuentos DNS del 13 de noviembre de 2025 presenta números por dirección, no una tabla de latencias individuales. Los valores de esa jornada son distintos entre proveedores. Un solo día no demuestra una avería, un sesgo ni que los promedios estén mal; sí muestra por qué hacen falta definiciones más completas para entender cómo se obtuvo cada total.

El repositorio público 1.10.10.10-tests y su README describen datos y gráficos diarios. En el árbol público revisado para este artículo no encontré archivos identificados como los ID de medición, los registros completos de latencia o los scripts de recopilación necesarios para rehacer el cálculo. Es una observación acotada a ese árbol en la fecha de revisión; no una afirmación de que esos materiales no existan en otro lugar. Con lo visible allí no se reproducen por sí solas las medias de 91 días.

Además, un promedio esconde la forma de la distribución. No informa si la mayoría de las respuestas estuvo cerca de 27 ms, si unas pocas jornadas lentas arrastraron el resultado o si algunas rutas funcionaron de modo muy distinto. Medianas, percentiles altos, vistas por día y dispersión por sonda aportarían contexto. Una muestra grande puede estimar bien el comportamiento de las sondas incluidas y aun así no representar redes que no participaron.

RIPE Atlas aporta puntos de observación, no un sello de auditoría

La documentación de RIPE Atlas y de las mediciones definidas por usuarios explica que la plataforma permite ejecutar pruebas desde sondas alojadas en distintas redes. Esa distribución amplía los puntos de vista. No implica que RIPE NCC eligiera la lista, revisara la agregación o certificara la interpretación del artículo. Sondas de terceros hacen que la observación sea distribuida; no convierten un análisis del operador en una auditoría independiente.

El informe habla normalmente de 130 a 145 sondas ubicadas en India. No publica en el artículo una muestra probabilística de redes, proveedores de acceso y usuarios ponderada para representar al país. Una colección de puntos puede ser útil para los lugares donde están y seguir dejando abierta la generalización. Para presentar una media nacional harían falta reglas de selección, una población objetivo y un método de ponderación.

El cargo sitúa el trabajo; no representa a cada usuario

La biografía de Gaurav Kansal en APNIC lo identifica como Joint Director (IT) del NIC y señala que lidera Sarvagya/Bharat Public DNS. El post de APNIC es una contribución de autor invitado; su aviso editorial de agosto de 2026 aclara que las opiniones corresponden al autor. Estos datos explican su relación con el servicio y con la comunidad técnica, pero no lo convierten en representante de todas las personas que usan Internet en India.

El manual de ciberseguridad del CGA y una nota de NIC Informatics de julio de 2025 incluyen 1.10.10.10 y 2409::1 en recomendaciones o parámetros de configuración. Prueban que existe una recomendación documental; no cuántos dispositivos la aplican, qué regiones cubre ni si la recomendación equivale a adopción nacional.

El sitio personal de Kansal describe además escala, localidad de datos y filtrado de dominios dañinos. Esas afirmaciones deben atribuirse a su perfil personal, no tratarse como resultados validados por la tabla de latencia. Una respuesta rápida no establece la política de registro, la exactitud de filtros, la calidad de protección ni el nivel de disponibilidad. Cada afirmación necesita su propia evidencia.

El estándar fundacional, RFC 1034, define el sistema de nombres; medir la rapidez de un resolver cubre solo una dimensión de su operación. En una instalación amplia también importan la ruta alternativa cuando falla, la persona responsable del incidente, la política de privacidad y quién puede cambiar la configuración.

Una próxima comparación más reproducible

La siguiente edición podría publicar para cada ejecución su ID de RIPE Atlas, las reglas de selección y distribución de sondas, los tipos de consulta, la configuración exacta y las fechas. Tendría que definir cómo se registran timeouts, reintentos, paquetes perdidos y respuestas fallidas. Un conjunto de resultados por consulta y el código de agregación permitirían que otra persona recalculara los promedios, respetando las restricciones de privacidad.

Las medias pueden conservarse para facilitar la lectura, acompañadas por medianas, percentiles altos, serie diaria y tasa de respuestas ausentes. También convendría separar nombres populares potencialmente almacenados en caché de nombres de resolución fría y consultas de respuesta conocida. Disponibilidad, corrección, DNSSEC, privacidad, filtrado, seguridad y respuesta a incidentes necesitan ensayos separados; no se deducen de un tiempo menor.

La fecha limita igualmente la actualidad: la ventana terminó el 11 de febrero de 2026 y el artículo apareció el 17 de septiembre. Es evidencia histórica, no una medición de septiembre. Una serie regular, con definiciones comparables o cambios bien explicados, permitiría saber si el comportamiento se mantiene.

La conclusión más defendible no es «el NIC supera a los grandes resolvers» ni «la prueba carece de valor». Es más acotada: para las sondas, nombres, periodo y método descritos, la media DNS que reporta el autor para NIC es menor que las de los tres comparadores; su media de ping es algo mayor que las de Cloudflare y Google. El informe publica suficientes detalles y cautelas para iniciar una conversación técnica, pero el paquete público revisado no permite rehacer toda la aritmética.

Ese límite es central para entender la contribución de Kansal. Su trabajo hace visible una parte de un servicio público mediante medición comparativa. Se puede reconocer ese aporte sin llamar al cuadro una auditoría nacional ni asumir que el cargo del autor expresa la voluntad de todos los usuarios. Una tabla pública gana autoridad cuando sus límites están claros y los datos permiten a terceros verificarla.

Fuentes