Resumen

  • La captura del 11 de septiembre del inventario Hosted DNS contiene 48 filas de AuthDNS: 43 operativas y cinco retiradas. Es una contabilidad verificable de despliegues, no de poblaciones que consiguieron menor latencia o una ruta más resistente.
  • El estudio regional de RIPE Atlas aporta la cautela decisiva: el nodo situado en Baréin fue utilizado sobre todo por sondas saudíes, mientras que las sondas de Batelco dentro de Baréin casi nunca llegaron a él.

Un inventario que hace bien una sola cosa

La etiqueta «Operational» sí tiene contenido. Distingue una instancia que RIPE NCC considera en servicio de otra que ha sido retirada. Junto a ella aparecen un identificador, la ciudad, la organización anfitriona, un nombre de host y, en numerosos casos, una fecha de finalización. Para una infraestructura distribuida, ese rastro es preferible a un mapa sin estados ni responsables.

La versión preservada para este análisis reúne 48 registros AuthDNS. Cuarenta y tres están operativos y cinco figuran como decommissioned. Entre los activos, el #523 de Milán, alojado por LAKENETWORKS, se completó el 18 de junio de 2026. El #520 de Berlín, con BCIX Management GmbH, muestra el 28 de julio. El plan trimestral se había actualizado el 11 de junio.

Las fechas permiten ordenar hechos, no atribuir causas. La documentación examinada no indica cuándo comenzaron esas solicitudes, si respondían al objetivo del tercer trimestre ni qué carencia concreta pretendían resolver. Tampoco publica una prueba de aceptación que muestre la red de acceso alcanzada antes y después.

Por tanto, 43 es un número sólido mientras se formule la pregunta correcta: ¿cuántas filas Hosted AuthDNS están declaradas operativas en esta captura? Deja de ser sólido si se convierte en respuesta a cuántas zonas mejoraron, cuántos resolutores eligieron un nodo más cercano o cuántos dominios de fallo se eliminaron.

RIPE NCC no definió el objetivo como una colección de ciudades

El plan DNS y K-root para el tercer trimestre de 2026 dice que AuthDNS debe ampliar su cobertura allí donde está poco representado. La preferencia es estar dentro de grandes redes de acceso de un país, en redes que intercambien tráfico con ellas o en un puerto de IXP que permita relacionarse con varias partes. El trabajo figura en curso.

Es una definición topológica. Las redes de acceso importan por los resolutores y usuarios que agregan. Sus pares importan porque pueden ofrecer una ruta corta. Un servidor de rutas de un intercambio puede hacer visible una misma instancia a numerosos sistemas autónomos. Nada de ello se deduce del domicilio del centro de datos.

Faltan, en la superficie pública, un denominador de países o redes insuficientemente cubiertos, una cohorte objetivo, un límite de latencia y una ventana temporal para aceptar el resultado. Esa ausencia no demuestra que los ingenieros carezcan de criterios internos. Delimita lo que un tercero puede reproducir: hoy se puede verificar el alta del nodo, pero no enlazarla con el cierre de la brecha anunciada.

La arquitectura obliga a separar términos

AuthDNS anuncia 193.0.9.0/24 y 2001:67c:e0::/48 desde AS197000. Atiende zonas de DNS inverso bajo in-addr.arpa e ip6.arpa, el dominio ripe.net, zonas de infraestructura de otros Registros Regionales de Internet, organizaciones apoyadas y servicio secundario para algunos ccTLD.

RIPE NCC presenta cuatro instalaciones centrales: Ámsterdam, Londres, Estocolmo y Tokio. En cada una, un encaminador reparte consultas entre varios servidores que ejecutan BIND, Knot DNS y NSD. Los nodos alojados complementan esa base con instancias de un solo servidor dentro de redes ISP o conectadas a intercambios.

Un nodo alojado puede acercar el anuncio anycast sin reproducir la diversidad interna de un centro principal. Un centro principal puede tener redundancia y no ser el destino preferido de una red concreta. Hablar de «nodo», «servidor», «sitio», «cobertura» y «resiliencia» como si fueran una misma unidad borra la diferencia entre presencia física y servicio observado.

Baréin ofrece la prueba que el mapa no puede dar

El propio RIPE NCC ya ensayó una contabilidad mejor. En 2024, una investigación publicada en RIPE Labs utilizó sondas de RIPE Atlas en Europa Sudoriental, Asia Central y Oriente Medio. Cada treinta minutos consultaban 193.0.9.7 por 150.6.0.193.in-addr.arpa. El análisis identificaba qué servidor había respondido y agregaba por sonda y día, incluida la mediana del tiempo de ida y vuelta.

En Europa Sudoriental, muchas observaciones acabaron en Ámsterdam. Bosnia y Herzegovina y, sobre todo, Rumanía mostraron un mayor uso de nodos locales, aunque algunas sondas llegaron de manera persistente a Kansas City o Baréin. En Asia Central, donde entonces no había una instancia AuthDNS según el informe, Ámsterdam y Estocolmo recibieron la mayoría de las consultas medidas.

La paradoja aparente apareció en Manama. Había un servidor en Baréin, hospedado por STC Bahrain, pero su clientela observada era principalmente saudí. Las sondas de Batelco en Baréin, AS5416, apenas lo seleccionaban. Las de Saudi Telecom Company, AS25019, sí lo hicieron durante toda la ventana de medición. Además, para estas últimas era una buena ruta: medianas inferiores a 50 ms, frente a unos 100 ms hacia Europa y trayectos mucho más largos hacia Venezuela o Guam.

No es evidencia de mal funcionamiento. Es evidencia de que el producto de un despliegue anycast es su zona de captación BGP. La geografía crea una posibilidad; anuncios, preferencias, peering y tránsito deciden qué resolutores la utilizan.

La política de peering dibuja el mecanismo

AS197000 mantiene una política generalmente abierta. En los sitios centrales y en los nodos alojados en IXP, AuthDNS acepta desde los servidores de rutas prefijos con mínimo /24 en IPv4 y /48 en IPv6, y anuncia allí los suyos. RIPE NCC recomienda los servidores de rutas y sus comunidades de filtrado. También contempla acuerdos directos bajo condiciones explícitas; en nodos IXP alojados, cuando el intercambio no dispone de servidor de rutas.

Así, una sola instalación puede conseguir una amplia zona útil o una mucho más estrecha. El nombre de la organización anfitriona no equivale a la lista de pares. El inventario no expone para cada fila el ASN de alojamiento, la participación efectiva en servidores de rutas, la distribución de resolutores entrantes ni su variación después de la puesta en marcha.

No sería prudente exigir todos los detalles. Algunos acuerdos son privados, cambian con frecuencia o podrían revelar topología sensible. La rendición de cuentas necesaria es agregada: qué cohorte se pretendía mejorar, cómo se midió y qué desplazamiento se observó.

La caché impide inflar el beneficio

La FAQ de Hosted DNS advierte que la mayor parte de las consultas se responde desde cachés. En redes bien conectadas, alojar un servidor puede aportar una mejora modesta o incluso imperceptible, porque solo una fracción pequeña de las consultas a esas zonas llega al root o a AuthDNS. El beneficio relevante puede existir para búsquedas inversas o zonas concretas, pero no debe presentarse como una aceleración de todo el DNS ni como ahorro general de ancho de banda.

Las obligaciones también están repartidas. El anfitrión aporta el servidor especificado o una máquina virtual suficiente, un entorno profesional, energía redundante, seguridad física y conectividad, y asume los costes. RIPE NCC administra el equipo a distancia. Si detecta problemas del nodo o de alcance, este retira el prefijo para desviar las consultas hacia otros servidores.

Esa retirada cambia la captación sin trasladar el equipo. Un acuerdo de peering puede cambiarla sin instalar nada. Un alta puede estar completa antes de que su ruta alcance a la población prevista. Por eso el reloj del inventario no coincide con el del resultado.

El segundo recibo

El registro actual merece conservarse. Para cumplir el lenguaje del plan necesita un complemento: un recibo de cobertura por nodo o por campaña de despliegue. Podría unir el identificador a una brecha inicial, una cohorte agregada, un ID de medición, reglas de selección de sondas, ventana temporal, distribución de servidores que responden y latencias antes y después. Debe registrar el umbral de aceptación, las excepciones y la incertidumbre de la muestra.

Ese documento puede excluir peers privados, direcciones de resolutores y detalles de seguridad. Su función no es revelar la red, sino mantener separados cinco resultados: inventario, alcance, captación anycast, latencia y resistencia al fallo. Una fila verde prueba el primero. Una consulta exitosa prueba el segundo desde un punto y un instante. Los demás requieren observación adicional.

Los 43 registros no condenan el programa. Muestran que ya existe una base ordenada sobre la que publicar el recibo que falta.

Fuentes