Resumen

  • La documentación pública permite asignar una solidez media a la existencia de la red y de los servicios lógicos de ZDNS: hay solicitudes evaluadas por ICANN, delegaciones de IANA, rutas de doble pila y una combinación declarada de puntos anycast y unicast.
  • La evidencia sobre capacidad física atribuible a ZDNS y margen utilizable tras una avería es débil: las cifras de 732 racks en Beijing y más de 1.000 gabinetes en Huairou describen instalaciones anfitrionas, no inventario reservado, propiedad ni capacidad disponible para ZDNS.
  • Un comprador prudente todavía necesita resultados fechados de pérdida del sitio de mayor carga, retirada de rutas, restauración de bases de datos, emergencia DNSSEC y validación de depósitos, junto con inventario instalado y de reserva y RTO/RPO realmente alcanzados.

La pregunta decisiva está detrás del mapa

ZDNS deja una huella pública bastante amplia para confirmar que no estamos ante una oferta puramente conceptual. La lista de solicitudes de prestadores de servicios de registro evaluadas por ICANN muestra que la empresa fue considerada apta para los tipos de servicio Main, DNS, DNSSEC y Proxy, con compatibilidad para nombres de dominio internacionalizados. Esa evaluación es una señal importante: vincula el nombre de la compañía con funciones concretas del ecosistema de registros. También evita que el análisis dependa únicamente del lenguaje comercial de su propio sitio.

Pero la pregunta relevante para un operador de registro, una empresa que compra DNS autoritativo o una organización preocupada por la soberanía de sus datos no es simplemente si el servicio existe. Es cuánto de ese servicio puede vincularse a activos físicos identificables, qué parte de la carga reside en cada lugar, qué recursos quedan libres cuando falla una ubicación y si la recuperación ha sido demostrada con resultados recientes. El programa de prestadores de servicios de registro de ICANN evalúa una solicitud; no convierte cada despliegue posterior en una instalación continuamente certificada ni publica por sí mismo el margen operativo de cada cliente.

Esta distinción cambia el sentido de casi todos los números disponibles. Ocho filas de centros de datos no equivalen automáticamente a ocho dominios de fallo independientes. Una ruta anunciada no equivale a un servidor, y mucho menos a una cantidad determinada de consultas por segundo. Un certificado que cubre cientos de racks dice algo sobre el edificio anfitrión, pero no revela cuántos racks utiliza ZDNS. Una cifra de disponibilidad comercial tampoco muestra qué ocurrió durante la última avería relevante.

Por eso conviene separar dos conclusiones desde el comienzo. La evidencia de red y de servicio lógico merece una calificación media: hay varias clases de documento que se refuerzan entre sí. La evidencia sobre capacidad física atribuible y margen de conmutación utilizable es débil: faltan asignaciones, inventarios, cargas y pruebas de pérdida. Mezclar ambas calificaciones produciría una afirmación de capacidad que los documentos no sostienen.

Una identidad reconocible, con una anomalía ortográfica que no crea otra empresa

La identificación de la entidad exige una precaución poco vistosa, pero esencial. El registro RDAP de APNIC para AS38345 conserva en la etiqueta del titular la grafía “Resrarch”, también usada en el nombre del directorio asociado a este análisis. La solicitud actual presentada ante ICANN utiliza el nombre legal corregido y la denominación comercial ZDNS. Esa diferencia de ortografía no permite inferir por sí sola que existan dos compañías, una escisión o una sucesión jurídica. El tratamiento responsable es preservar la etiqueta documental donde corresponde y reconocer la identidad operativa sin inventar una historia corporativa.

La cronología también aconseja moderación. La página corporativa About Us de ZDNS sitúa el establecimiento declarado de la empresa en 2013. En cambio, el registro de AS38345 es anterior, y la consulta histórica disponible mediante APNIC Whois para AS38345 conserva contactos de KNET. La coexistencia de esas fechas y referencias plantea una pregunta válida sobre la evolución administrativa del recurso de numeración, pero los materiales examinados no documentan una adquisición, una entidad predecesora ni una cadena de propiedad. Rellenar ese vacío con una narración plausible sería convertir una laguna en un hecho.

La página de contacto de ZDNS aporta otra referencia directa a la identidad actual. En conjunto, las fuentes permiten seguir un nombre comercial, un nombre legal corregido y una etiqueta histórica de registro de Internet. No permiten reconstruir todos los pasos entre ellos. Para una diligencia operativa, esto significa que la identidad del servicio puede considerarse reconocible, mientras que la titularidad histórica de cada activo o contrato necesita documentación adicional si resulta material para la compra.

La anomalía ortográfica importa además por una razón práctica: una búsqueda automatizada o una revisión superficial podría tratar la etiqueta de APNIC como una entidad distinta y contar dos veces la misma huella. El error contrario sería asumir que todo recurso asociado históricamente con el ASN pertenece hoy a ZDNS bajo idénticas condiciones. Ninguno de esos extremos está justificado. La identidad sirve para orientar la investigación; no sustituye contratos, inventarios ni pruebas de control operativo.

La cartera mezcla funciones que no comparten el mismo plano de riesgo

Las páginas de ZDNS describen una cartera extensa. La plataforma para dominios de nivel superior presenta funciones propias de un entorno de registro, mientras que la oferta de DNS en la nube se dirige al servicio alojado y la línea de equipamiento central añade dispositivos que pueden desplegarse de forma separada. En los materiales aparecen custodia de datos, DNSSEC, WHOIS/RDAP, DNS autoritativo, GSLB, HTTPDNS, BGP/anycast y aparatos instalables. Enumerarlos juntos ayuda a entender la amplitud comercial, pero no demuestra que todos utilicen los mismos servidores, ubicaciones, rutas, bases de datos o procedimientos de recuperación.

La separación es especialmente importante entre el plano público de consultas y el plano de control. Un nodo DNS autoritativo puede responder cerca de un usuario a través de anycast, aunque la gestión de zonas, las claves, los registros, las copias o los mecanismos administrativos residan en otros lugares. De forma similar, un producto instalado en las dependencias del cliente puede compartir marca y determinadas funciones con el servicio alojado, pero su continuidad depende de activos y responsabilidades diferentes. La existencia de una opción desplegable no aumenta automáticamente la capacidad de la nube de ZDNS.

El Acuerdo Base de Registro de ICANN ofrece el marco general dentro del cual se entienden varias obligaciones de un operador de registro, pero no asigna equipos concretos de ZDNS a una ubicación ni aporta el consumo de cada servicio. Para evaluar dependencia, el comprador debe descomponer la cartera: registro principal, publicación DNS, firma DNSSEC, WHOIS/RDAP, custodia, distribución de tráfico y administración. Cada capa tiene estados, datos y condiciones de recuperación diferentes.

Esta lectura evita una confusión frecuente. Una lista larga de funciones puede elevar la confianza en que existe una oferta madura, pero también amplía la superficie que debe comprobarse. La continuidad del DNS autoritativo no prueba la disponibilidad del registro principal; la supervivencia de consultas almacenadas no prueba que se puedan aceptar cambios; la operación del WHOIS/RDAP no prueba el acceso a material de firma; y la recuperación de una base de datos no demuestra que las rutas se hayan estabilizado. La calificación media de la evidencia lógica reconoce la documentación de esas funciones.

No debe convertirse en una calificación física ni en una garantía conjunta para todas ellas.

Ocho filas describen dependencias, no ocho fortalezas independientes

El documento más concreto sobre localización es el anexo de centros de datos de ZDNS. Contiene ocho filas: CSNET en Beijing; Jiuxianqiao en Beijing; Chengdu; HKIX en Hong Kong; y ubicaciones de Cogent en Los Ángeles, Chicago, Fráncfort y Nueva York. El mismo material asocia Beijing, Hong Kong, Los Ángeles, Chicago, Fráncfort y Nueva York con anycast, y vincula Jiuxianqiao y Chengdu con servicios unicast.

La lista es valiosa porque desplaza el debate desde una palabra genérica como “global” hacia dependencias nombradas. El sitio público de operaciones de HKIX permite identificar el punto de intercambio citado, y el mapa de red de Cogent contextualiza al operador mencionado en las cuatro ciudades. Sin embargo, ninguna fila revela por sí sola qué equipos instala ZDNS, cuántos puertos contrata, qué volumen de consultas atiende, qué conexión utiliza, qué datos conserva o quién controla la retirada de rutas.

Tampoco puede suponerse que una ciudad sea un dominio de fallo o que dos nombres dentro de Beijing sean plenamente independientes. La independencia real depende de elementos que no aparecen en la lista: alimentación, salas, conducciones, operadores, equipos, control, personal, sincronización de estado y concentración de carga. Dos sitios geográficamente separados pueden compartir una dependencia crítica; dos servicios en un mismo recinto pueden tener comportamientos diferentes. Sin una matriz de sitio y función, la cifra ocho es un recuento de filas documentales, no una medida de resiliencia.

La diferencia entre anycast y unicast añade otra capa. Anycast permite que varios lugares anuncien una dirección y que el encaminamiento entregue tráfico según la vista de la red. Unicast señala una relación más directa entre dirección y destino. Ninguna de las dos etiquetas informa del margen restante. Seis ciudades asociadas con anycast podrían sostener una distribución robusta, o podrían depender desproporcionadamente de uno o dos puntos; el anexo no lo cuantifica. Las dos referencias unicast podrían alojar funciones auxiliares o esenciales; tampoco se especifica.

Por tanto, las ocho ubicaciones son evidencia de una arquitectura distribuida declarada y de relaciones con anfitriones o redes reconocibles. Son insuficientes para afirmar ocho nodos físicos propiedad de ZDNS, ocho instalaciones equivalentes o capacidad para absorber la pérdida de cualquiera de ellas. Esa precisión no debilita la evidencia existente; define exactamente lo que puede y no puede demostrar.

Los 732 racks pertenecen al perímetro certificado de un anfitrión

La cifra que más fácilmente se presta a una lectura excesiva es la del complejo Beijing M5 Phase III. El anexo citado cubre, dentro del alcance de un certificado, 732 racks distribuidos en tres salas. También menciona dos enfriadoras de 3 517 kW, dos depósitos de agua enfriada de 84 m³ y cinco unidades diésel de 2 500 kVA. Son características físicas sustanciales del entorno anfitrión. No son una declaración de que ZDNS posea, arriende o pueda usar esos 732 racks.

El alcance importa tanto como el número. La certificación excluye red y cableado, de modo que no puede emplearse para validar trayectos de comunicaciones, diversidad de conducciones o conectividad de ZDNS. Tampoco informa de la fracción asignada a la empresa, de la ocupación del edificio, de las reservas eléctricas contractuales ni del equipo instalado para el servicio analizado. Incluso si ZDNS utiliza espacio en ese recinto, pasar del total del anfitrión a su capacidad individual requeriría una asignación documentada.

La tentación de apropiarse del total surge porque un número físico parece más sólido que una descripción comercial. Pero la unidad de medida correcta depende de la pregunta. Los racks del edificio pueden describir escala agregada. Para determinar capacidad utilizable de ZDNS se necesitarían, entre otros elementos, racks contratados, potencia comprometida, servidores instalados, puertos, límites de tránsito, sistemas de almacenamiento, equipos de firma, repuestos y carga actual. Ninguno de esos valores puede deducirse dividiendo o multiplicando los totales del certificado.

Tampoco conviene convertir los componentes de energía y refrigeración en una capacidad teórica para DNS. No sabemos la carga del resto de ocupantes, la redundancia disponible, la configuración operativa ni la parte reservada. Sumar las potencias nominales o inferir consultas por segundo a partir de ellas produciría una precisión ficticia. Las cifras sirven para confirmar una dependencia de alojamiento dotada de infraestructura descrita; no para cuantificar la prestación de ZDNS.

La conclusión correcta es estrecha pero útil: el documento da evidencia sobre el lugar que puede sostener parte de la operación, no sobre el inventario atribuible al operador. Los 732 racks deben tratarse como un total de la instalación anfitriona y nunca como capacidad de ZDNS. Esta sola distinción evita que el dato más vistoso del expediente se convierta en su afirmación menos defendible.

Huairou confirma otra instalación de gran escala, pero no una reserva para ZDNS

La descripción de Huairou aporta otro conjunto de cifras agregadas: aproximadamente 20.000 metros cuadrados y más de 1.000 gabinetes. La presentación institucional de CNIC ayuda a situar la organización mencionada en la documentación. De nuevo, la escala del recinto no revela la porción que corresponde a ZDNS ni prueba que esos gabinetes estén disponibles para asumir tráfico procedente de otro sitio.

La distinción entre superficie construida y capacidad operativa es decisiva. Los metros cuadrados pueden incluir áreas que no alojan equipos de ZDNS; los gabinetes pueden estar ocupados por otros usuarios, reservados para otras funciones o sujetos a límites de potencia y conectividad. “Más de 1.000” tampoco es un inventario detallado. Sin un vínculo contractual y técnico, la cifra describe al anfitrión, no al servicio de DNS o de registro.

Además, la existencia de dos grandes instalaciones mencionadas en Beijing no resuelve la concentración regional. La documentación no permite establecer qué estados o funciones se replican entre ellas, si comparten dependencias, cómo se distribuye la carga ni cuánto tardaría una transición. La proximidad puede facilitar ciertas operaciones y, al mismo tiempo, mantener riesgos comunes. No hay base pública para escoger una interpretación optimista o pesimista; solo puede registrarse la incertidumbre.

Un comprador podría preguntar qué parte del registro principal se ejecuta en Huairou, qué parte en Jiuxianqiao, dónde se guardan copias, dónde se ubican claves y qué componentes son estrictamente activos o de reserva. También debería solicitar la capacidad contratada, instalada y libre de cada entorno. Estas tres cifras no son intercambiables: un compromiso comercial puede superar lo instalado, y lo instalado puede estar ocupado por carga ordinaria.

Así, Huairou refuerza la evidencia de dependencia física, pero no cambia la calificación de capacidad atribuible. Junto con M5 Phase III, muestra que la documentación se apoya en instalaciones de tamaño significativo. Sin asignaciones y resultados de conmutación, no demuestra cuánto de esa escala está al servicio de ZDNS ni cuánto sobreviviría cuando más se necesitara.

AS38345 hace visible una superficie de red real y de doble pila

La red ofrece una clase de evidencia diferente. El resumen de AS38345 en RIPEstat, la consulta de prefijos anunciados y el estado de encaminamiento mostraron durante la investigación 24 prefijos IPv4 /24 y 12 prefijos IPv6 /48, con visibilidad amplia entre colectores. Cloudflare Radar para AS38345 proporciona otra vista pública de esa presencia.

Estos datos sustentan una conclusión positiva y limitada: existe una superficie de encaminamiento activa y de doble pila asociada con el ASN. La combinación de IPv4 e IPv6 y la observación desde múltiples puntos es más informativa que una afirmación comercial aislada. También encaja con una oferta que utiliza BGP y anycast. Por esa razón, la evidencia de red merece más que una calificación débil.

Sin embargo, una ruta no es una unidad de cómputo. El anuncio de un /24 o un /48 no indica cuántos servidores responden, qué consultas procesan, cuánto tráfico soportan, si comparten una sala o si mantienen estado saludable. Un prefijo puede ser visible mientras el servicio detrás de él está degradado, y varias rutas pueden terminar en infraestructura común. La amplitud observada en colectores tampoco equivale a diversidad física.

La información de vecinos de AS38345 y la vista de coherencia de encaminamiento permiten examinar relaciones y consistencia a nivel de red. Son útiles para mapear exposición, pero no documentan contratos, conductos separados ni control de equipos en cada ciudad. La red lógica y el edificio deben seguir siendo capas distintas.

Incluso el recuento de prefijos exige una marca temporal. Refleja lo observado durante la investigación, no una propiedad inmutable del ASN. Las rutas pueden cambiar y su estado debe reevaluarse cuando una decisión dependa de él. En este análisis, esas observaciones confirman operación visible; no se utilizan para calcular consultas por segundo, disponibilidad, inventario o reserva física.

Dos muestras RPKI no permiten puntuar toda la red

La validación de origen añade una señal de higiene de encaminamiento, pero el conjunto público examinado es deliberadamente pequeño. Una consulta de RIPEstat para 150.242.156.0/24 originado por AS38345 devolvió un estado válido. Otra consulta para 1.8.1.0/24 y AS38345 devolvió desconocido.

El resultado válido indica que esa muestra concreta coincidía con la autorización visible en el momento de la consulta. El resultado desconocido significa que la misma clase de confirmación no estaba disponible para la segunda muestra. No constituye prueba de secuestro de ruta, comportamiento malicioso o fallo del servicio. Tampoco debe presentarse como una tasa del 50 %, porque dos prefijos escogidos no forman una medición representativa del conjunto.

La lectura prudente es que la postura observada no fue uniforme en esas dos consultas. Para convertirla en una evaluación de toda la red haría falta cubrir los prefijos pertinentes, conservar fecha y estado, considerar cambios y relacionar cada ruta con el servicio que transporta. Incluso una cobertura perfecta de autorizaciones de origen no respondería preguntas de capacidad física o recuperación de datos.

RPKI protege una relación concreta entre prefijo y origen autorizado; no demuestra que un nodo anycast esté sano, que una zona sea correcta o que los sistemas tengan margen. Es posible tener una ruta validada hacia un servicio degradado. También es posible tener un estado desconocido sin que exista una anomalía de tráfico. La señal debe integrarse en una revisión de red sin inflarla.

Esta sección ilustra el principio general del expediente: cada evidencia debe mantenerse en su capa. Las muestras RPKI hablan de validación del origen para dos prefijos. No miden la infraestructura de ZDNS, la independencia de sus lugares ni su continuidad. Presentarlas con esa frontera conserva su utilidad y evita una falsa precisión.

Las delegaciones de IANA conectan ZDNS con nombres que funcionan en Internet

Las páginas de delegación de IANA para .baidu, .icbc y .unicom identifican a ZDNS como contacto técnico y muestran un patrón compartido de puntos autoritativos. Esta es una evidencia externa y directamente vinculada con el plano público del DNS. Confirma que el nombre de ZDNS aparece en delegaciones reales, no solo en una descripción de producto.

El patrón común puede ser coherente con una plataforma compartida y con el uso de una red autoritativa distribuida. No permite saber cuántas máquinas atienden cada dominio, si existe aislamiento dedicado por cliente o cuánto margen se reserva. Una delegación contiene la información necesaria para encontrar servidores autoritativos; no es un inventario de activos ni un diagrama de dependencias internas.

La atribución de direcciones observadas introduce todavía más matices. Las consultas de información de red para 203.99.24.1, 116.169.54.111, 223.72.199.37 y 2401:8d00:2::1 vincularon direcciones autoritativas seleccionadas con orígenes de ruta observados en AS38345, AS4837, AS56048 y AS24149.

Esa diversidad de orígenes puede ser consistente con una combinación de redes, ubicaciones o relaciones operativas. No demuestra que ZDNS sea propietaria del servidor o del ASN en cada caso, que exista un contrato específico, que las direcciones residan en instalaciones separadas o que los trayectos físicos sean diversos. El origen BGP indica desde dónde se anuncia una ruta, no quién posee todos los componentes detrás de ella.

Para el usuario final, lo importante es que las delegaciones y rutas sostienen la visibilidad del servicio lógico. Para la diligencia de infraestructura, lo importante es lo que aún falta: asignación de puntos autoritativos a sitios, equipos y funciones; proporción de carga; dependencia de terceros; y capacidad restante tras retirar el origen o lugar de mayor peso. Las delegaciones elevan la confianza en la realidad operativa del DNS, pero no alteran por sí solas la calificación débil de capacidad física atribuible.

Anycast ayuda a desviar tráfico, pero no cura todos los fallos

El funcionamiento general de anycast está documentado en RFC 4786. Cuando un nodo fallido deja de anunciar de manera limpia y los sitios supervivientes conservan capacidad, el encaminamiento puede conducir las consultas hacia otros puntos. Esa propiedad encaja con las seis ciudades asociadas con anycast en el anexo de ZDNS y puede reducir la dependencia visible de un destino único.

La palabra decisiva es “cuando”. Si un nodo sigue anunciando mientras está enfermo, puede continuar atrayendo tráfico que no responde correctamente. Si los sitios restantes están cerca de sus límites, la retirada de un punto puede transformar una avería local en saturación distribuida. Anycast tampoco repara datos corruptos, una configuración errónea propagada globalmente ni la pérdida del estado necesario para firmar o publicar información correcta.

La diversidad de servidores secundarios, tratada en RFC 2182, recuerda que la separación útil no se reduce al número de nombres. Las dependencias de red y de ubicación importan. En el caso de ZDNS, el mapa de ciudades y los distintos orígenes de ruta ofrecen indicios de distribución, pero no una prueba de que los componentes críticos eviten dependencias comunes.

La verificación que falta es operacional. Un ensayo de retirada debería registrar qué ruta se elimina, cuánto tarda la convergencia, qué fracción de consultas cambia de destino, qué latencia y errores aparecen y cuánto margen conservan los supervivientes. Una prueba de pérdida del mayor sitio debería seleccionar el punto por carga real, no por tamaño del edificio, y observar todas las funciones relevantes, no solo una respuesta DNS almacenada.

Esta diferencia también explica por qué la disponibilidad histórica anunciada no basta. Una red puede haber estado disponible la mayor parte del tiempo sin haber probado la combinación de fallo que preocupa al comprador. Anycast es un mecanismo potente de distribución y desvío; su efectividad depende de señales correctas, capacidad sobrante y control coordinado. La documentación pública demuestra que forma parte del diseño declarado, pero no publica el resultado fechado de un escenario de pérdida máxima.

Las cifras comerciales carecen del denominador que permitiría comprobarlas

ZDNS comunica cifras de rendimiento y escala en su material de plataforma: 3.000 operaciones de firma por segundo, 15.000 pares de claves, entre 16.000 y 27.000 consultas WHOIS/RDAP por segundo, dos mil millones de resoluciones DNS al día y una disponibilidad superior al 99,999 %. Son números concretos y relevantes para una conversación de capacidad. Sin embargo, no vienen acompañados, en el material público revisado, de un método fechado, una definición completa de carga, inventario, utilización, distribución por sitio ni resultado tras perder la ubicación principal.

Una tasa máxima no tiene un único significado. Podría proceder de una prueba de laboratorio, de un componente aislado, de una configuración de referencia o de un entorno desplegado. Sin el número de instancias, el tamaño de las respuestas, la combinación de lecturas y escrituras, la duración, el percentil de latencia y la condición de fallo, no puede compararse de forma fiable con una carga de comprador. Lo mismo ocurre con el rango de consultas WHOIS/RDAP: el extremo aplicable depende de las condiciones que no se publican.

Dos mil millones de resoluciones diarias expresan volumen, no necesariamente capacidad máxima ni margen. Un promedio diario puede ocultar picos y distribución desigual. Tampoco revela cuántas respuestas se atienden desde cada ubicación o qué porcentaje depende del punto más cargado. Para estimar continuidad se necesitan al menos carga ordinaria, pico observado, capacidad sostenible y reserva disponible después de una pérdida.

La disponibilidad superior al 99,999 % requiere además un perímetro de medición. ¿Qué función se mide, desde qué puntos, con qué tratamiento de degradaciones y durante qué periodo? Los hechos disponibles no contestan esas preguntas. La cifra puede permanecer como afirmación comercial de ZDNS, pero no debe transformarse en un resultado independiente para todo el conjunto de servicios.

La cuestión no es rechazar los números, sino clasificarlos correctamente. Indican objetivos o capacidades publicitadas y ayudan a formular preguntas. No permiten asignar hardware, calcular concentración ni demostrar supervivencia. Sin denominadores y condiciones, no pueden elevar la evidencia física por encima de débil.

Dos centros Tier III o equivalentes son un compromiso de diseño, no una medición del margen

La solicitud Main RSP M57 de ZDNS afirma que existen al menos dos centros de datos independientes Tier III o equivalentes, además de copias, monitorización, controles de recuperación y respuesta de guardia durante las 24 horas. Es una descripción estructurada de intención y controles. También es más específica que una promesa genérica de alta disponibilidad.

La referencia de Uptime Institute sobre niveles sirve para entender que una clasificación del recinto aborda características de infraestructura. Pero una categoría de la instalación no asigna a ZDNS una cantidad determinada de servidores, tránsito, almacenamiento o personal. Tampoco demuestra que la aplicación completa tolere una avería, que los datos estén sincronizados correctamente o que la capacidad superviviente pueda absorber el pico.

“Independiente” debe probarse en el perímetro del servicio. Dos edificios pueden cumplir determinadas características y seguir compartiendo operadores, conductos, herramientas de administración, una fuente de configuración o una base de datos lógica. La solicitud no publica el inventario instalado y de reserva, los compromisos de puertos, la capacidad frente a ataques de denegación, la proporción de carga del mayor sitio ni el margen que queda al retirarlo.

La presencia de controles de monitorización y guardia mejora la preparación organizativa, pero no sustituye tiempos logrados. Una alerta puede detectar un problema sin resolverlo; un equipo de guardia puede responder sin alcanzar el objetivo de recuperación. Para valorar el riesgo contractual se necesitan resultados de incidentes o ejercicios representativos, con inicio, detección, decisión, conmutación, estabilización y retorno.

Por ello, la solicitud respalda una arquitectura declarada de redundancia y recuperación. No prueba capacidad N+algo para cada componente ni una cifra única de disponibilidad. El comprador puede reconocer el compromiso de diseño y, al mismo tiempo, pedir evidencia de implementación y prueba. Esa combinación es más rigurosa que aceptar o rechazar en bloque toda la afirmación.

DNSSEC requiere conservar estado, autoridad y capacidad de actuar bajo presión

El anexo de gestión de KSK de ZDNS describe rotaciones anuales y de emergencia, monitorización mediante HSM e IDS, comunicaciones fuera de banda, ejercicios de mesa y un diseño de análisis posterior. Esta combinación revela que la continuidad de DNSSEC se concibe como un proceso operativo, no solo como la presencia de una clave.

Los controles son pertinentes porque una emergencia DNSSEC no se parece a una mera pérdida de capacidad de consulta. El equipo debe identificar qué estado es correcto, conservar la cadena de autorización, coordinar comunicaciones y evitar que una acción apresurada amplíe el daño. Un HSM puede proteger material sensible y la monitorización puede alertar sobre anomalías, pero la documentación del diseño no muestra cuándo se ejecutó por última vez el escenario completo ni cuál fue el resultado.

Los ejercicios de mesa tienen valor para aclarar funciones y decisiones. No prueban por sí mismos que los sistemas, accesos, canales y tiempos funcionen en una ejecución técnica. De la misma manera, un procedimiento de análisis posterior indica intención de aprendizaje, pero no aporta un informe reciente que permita comprobar hallazgos y correcciones.

Existe además una frontera contractual. La descripción general no identifica la asignación jurídica y operativa de cada cliente respecto de todos los componentes. No se puede asumir que un único modelo de claves, HSM, ubicación o responsabilidad se aplique sin variación a cada registro atendido. Esa precisión debe pedirse cuando el riesgo de firma sea material.

Una prueba útil de emergencia debería demostrar acceso autorizado, comunicación fuera de banda, decisión, rotación o recuperación, publicación coherente y verificación desde el exterior. Debe registrar tiempos y cualquier desviación. La documentación pública muestra que ZDNS ha diseñado procesos alrededor de esas tareas; no presenta el último resultado ejecutado. Por tanto, fortalece la evidencia de madurez lógica, pero deja abierta la eficacia comprobada bajo una crisis realista.

Un depósito diario no equivale a una restauración demostrada

La solicitud Main indica que los depósitos completos de custodia del registro se realizan diariamente y que los depósitos fallidos se reintentan. Esta cadencia es relevante porque limita, en principio, el intervalo entre entregas completas y contempla el tratamiento de fallos. Sin embargo, frecuencia de depósito y recuperabilidad son propiedades distintas.

Para que un depósito sirva en una recuperación hay que saber si está completo, si puede descifrarse, si su integridad se valida, si el formato puede cargarse y cuánto tiempo lleva convertirlo en un servicio coherente. Un reintento resuelve ciertos fallos de entrega, pero no demuestra que el contenido sea utilizable. La mención de periodicidad tampoco proporciona por sí sola el punto de recuperación realmente alcanzado.

El RPO debe derivarse de resultados y del flujo de datos, no solo de la agenda. Si una entrega diaria contiene omisiones o si la restauración depende de otros estados, el resultado puede diferir de la cadencia nominal. El RTO requiere todavía más: infraestructura disponible, acceso, procedimientos, carga, comprobaciones y retorno del servicio. Ninguno de esos tiempos puede calcularse a partir de la palabra “diario”.

La evidencia adecuada sería una restauración fechada desde el depósito, realizada en un entorno representativo, con validación de integridad y funcionalidad. Para el registro principal debería comprobarse no solo que los datos aparecen, sino que las relaciones necesarias son coherentes y que los servicios dependientes pueden reanudarse de manera controlada. El resultado tendría que indicar punto y tiempo logrados, incidencias y acciones correctivas.

Así, la custodia diaria es una medida de protección documentada y útil. No debe confundirse con una restauración probada ni con una garantía de continuidad. Esta separación entre control previsto y resultado ejecutado recorre todo el análisis de ZDNS: los documentos muestran componentes razonables de diseño, mientras que el registro público carece de una serie completa de resultados fechados.

Una respuesta cercana no demuestra que los datos permanezcan en el mismo país

El DNS público de ZDNS tiene una superficie global. Las ciudades declaradas, el uso de anycast y la visibilidad de las rutas pueden hacer que una consulta llegue a un punto cercano desde la perspectiva del encaminamiento. Esa proximidad es valiosa para latencia y distribución, pero no revela dónde se almacenan los datos del registro, los registros de actividad, las copias, las claves o los servicios de control.

Este matiz es central para la soberanía y la localización. El plano de datos público puede estar muy distribuido mientras el plano de control permanece concentrado. Una respuesta DNS puede derivarse de información replicada y publicada sin exponer el lugar donde se autorizó el cambio o donde reside la copia principal. Del mismo modo, una dirección atendida en una ciudad no prueba que los registros administrativos o el material DNSSEC estén allí.

Por eso no se debe inferir residencia legal o física a partir de la latencia, del origen BGP o del nombre de un nodo. Para responder una pregunta de localización se necesita una matriz que separe al menos datos de registro, zonas publicadas, telemetría, copias, depósitos, claves y administración. También debe distinguir almacenamiento habitual, réplica, acceso remoto y transferencia durante recuperación.

La dependencia de terceros añade otra dimensión. Las referencias a HKIX, Cogent y otras redes muestran conexiones del plano público, pero no detallan qué información recibe cada parte ni en qué jurisdicción se procesa el control. La localización no se resuelve contando ciudades; requiere seguir categorías de datos y responsabilidades.

La conclusión disponible es, por tanto, precisa: el servicio ofrece una superficie pública global. No hay base para afirmar, solo por una respuesta cercana, que el resto de la operación o de los datos sea local. Un comprador con requisitos de residencia necesita compromisos y mapas específicos, además de pruebas de que la configuración desplegada coincide con ellos.

Cada grupo de usuarios depende de una capa distinta

Los efectos de una avería no pueden expresarse con un único número de clientes o dominios. Operadores de registro, registradores, registrantes, resolutores recursivos, clientes empresariales de DNS y usuarios posteriores interactúan con capas diferentes. Una interrupción del plano de actualización puede afectar altas o cambios sin impedir inmediatamente todas las consultas. Una degradación autoritativa puede afectar resolución mientras otros componentes siguen accesibles. Una emergencia de firma puede tener un patrón temporal distinto.

Esta segmentación impide convertir recuentos comerciales en personas afectadas. Un dominio puede sostener muchos servicios o muy pocos; una empresa puede usar DNS para sistemas de relevancia diversa; los resolutores pueden conservar información durante periodos limitados. Los datos públicos aquí reunidos no permiten calcular una población, un volumen económico o un conjunto de servicios críticos expuestos.

También cambia la forma de pedir evidencia. Un operador de registro necesita conocer continuidad de la base principal, custodia y DNSSEC. Un cliente de DNS empresarial puede centrarse en publicación, control y distribución anycast. Un registrador depende de interfaces y datos distintos de los que utiliza un resolutor recursivo. La misma cifra agregada de disponibilidad puede ocultar experiencias muy diferentes.

Una revisión útil debe describir escenarios: pérdida de un lugar, retirada defectuosa de una ruta, corrupción de configuración, indisponibilidad de control, restauración del registro o emergencia de claves. Para cada uno, debe indicar qué grupo pierde qué función y durante cuánto tiempo. La documentación pública no ofrece esa matriz completa.

Esta ausencia no niega la escala de la dependencia. Al contrario, obliga a tratarla sin números inventados. Sabemos que varias clases de participantes dependen de los servicios descritos; no sabemos cuántas personas o funciones críticas quedarían afectadas en un incidente concreto. La comunicación responsable conserva esa incertidumbre.

Lo que un comprador debería pedir antes de aceptar una cifra de resiliencia

La primera pieza necesaria es una matriz de sitio y función. Cada una de las ocho filas debería relacionarse con los servicios que ejecuta, los estados que conserva, su condición activa o de reserva, las rutas que anuncia y las dependencias compartidas. La matriz debe distinguir los centros anfitriones de los activos controlados por ZDNS y separar cualquier producto instalado por el cliente del servicio alojado.

La segunda pieza es un inventario por lugar que diferencie instalado, utilizado y libre. Debe incluir los recursos que limitan el servicio real: cómputo, almacenamiento, equipos de red, puertos, compromisos de tránsito, dispositivos de firma y repuestos pertinentes. El objetivo no es acumular números, sino descubrir el cuello de botella. La capacidad de un edificio no sirve si la restricción está en un puerto, una base de datos o un HSM.

La tercera pieza es una curva de carga. Carga ordinaria, pico observado y capacidad sostenible deben medirse con una definición común. También debe mostrarse la participación del mayor sitio. Solo entonces se puede calcular si los puntos supervivientes conservan margen para absorber la pérdida sin incumplir latencia, errores u objetivos operativos.

La cuarta pieza son resultados fechados. La retirada de rutas debe mostrar convergencia y salud del servicio; la prueba de pérdida del mayor sitio debe cubrir la ubicación elegida por carga; la restauración de base de datos debe validar integridad y tiempo; la emergencia DNSSEC debe demostrar autoridad, estado y comunicación; y la custodia debe probar descifrado y recuperación. Cada resultado debería registrar RTO y RPO logrados, no solo objetivos.

La quinta pieza es el mapa de terceros y localidad. Debe aclarar qué anfitrión, red u organización participa en cada función, qué datos recibe, qué control retiene ZDNS y qué dependencia común existe. Para requisitos territoriales, la ubicación del punto DNS debe separarse de datos del registro, registros de actividad, copias y claves.

Ninguna de estas solicitudes contradice la evidencia pública. La completa. Los documentos ya aportan una base para preguntar con precisión; lo que falta es la capa cuantitativa y ejecutada que convierte un diseño razonable en resiliencia demostrada.

Dos calificaciones distintas ofrecen una conclusión más fiel

La evidencia de red y servicio lógico obtiene una calificación media. ICANN registra servicios evaluados; IANA muestra delegaciones con ZDNS como contacto técnico; APNIC identifica el ASN; RIPEstat y Cloudflare Radar permiten observar una superficie de encaminamiento de doble pila; y los materiales de ZDNS describen funciones coherentes con esos rastros. Son fuentes de naturaleza diversa, y su coincidencia sostiene la existencia de una operación visible.

“Media” no significa completa. La evaluación de una solicitud no certifica continuamente cada despliegue, las delegaciones no revelan inventario y las rutas no miden salud o capacidad. La calificación reconoce realidad y coherencia documental sin atribuir más de lo observado.

La evidencia de capacidad física atribuible a ZDNS y margen utilizable de conmutación obtiene una calificación débil. Las instalaciones nombradas y sus cifras agregadas muestran dependencias físicas, pero no asignación. Faltan racks contratados, potencia reservada, servidores, puertos, carga por sitio, capacidad libre y resultados de pérdida. Los 732 racks de M5 Phase III y los más de 1.000 gabinetes de Huairou no pueden reservarse contablemente para ZDNS.

Estas dos calificaciones no deben promediarse ni comprimirse en una sola. Hacerlo permitiría que la buena visibilidad de red compensara una falta de evidencia física, aunque respondan preguntas diferentes. También podría penalizar injustamente la existencia del servicio porque no se publica un inventario. La separación mantiene cada conclusión en su ámbito.

El resultado final es más útil que una etiqueta binaria. ZDNS muestra una plataforma con presencia pública, funciones amplias y diseño de continuidad declarado. Todavía no muestra, en las fuentes revisadas, cuánto margen sobrevive a la mayor pérdida ni una serie completa de recuperaciones ejecutadas. Ese es el punto exacto donde debe concentrarse la diligencia adicional.

La resiliencia se demuestra cuando desaparece el componente más importante

El expediente permite formular una respuesta clara a la pregunta inicial. Sí hay pruebas de una red DNS y de servicios de registro globalmente visibles. También hay una lista de ocho ubicaciones, mecanismos anycast y unicast, controles de recuperación descritos y cifras comerciales ambiciosas. Pero ninguna de esas piezas permite adjudicar a ZDNS la capacidad total de un edificio anfitrión o conocer la reserva disponible tras una avería.

El criterio decisivo no es el número de puntos en el mapa, sino el comportamiento al retirar el punto que más carga o estado concentra. Si las rutas convergen, los sitios restantes absorben el tráfico, los datos siguen correctos, las claves permanecen operables y el control se recupera dentro de tiempos medidos, la resiliencia deja de ser una inferencia. Sin esos resultados, el mapa sigue siendo una descripción de dependencias.

La cifra de 732 racks resume el riesgo de interpretación. Es verdadera dentro del alcance físico del certificado citado y, a la vez, impropia como total de ZDNS. Tratarla como evidencia del anfitrión conserva su valor. Tratarla como inventario del servicio crearía una capacidad que no está documentada.

Para operadores de registro y compradores empresariales, la postura razonable es reconocer la evidencia media del plano lógico y mantener como débil la evidencia física y de margen. Después, la decisión debe condicionarse a una matriz de sitios y funciones, inventario y carga, prueba de pérdida del mayor sitio, restauración de datos, emergencia DNSSEC, validación de custodia y RTO/RPO logrados.

La transparencia útil no exige publicar cada detalle sensible. Sí exige proporcionar al comprador evidencia suficiente, fechada y delimitada para comprobar que la capacidad superviviente existe. Hasta entonces, ZDNS puede demostrar una presencia global; no puede demostrar públicamente cuánta de esa presencia seguiría siendo utilizable cuando falle su dependencia más importante.