Resumen

  • Arends fue uno de los cinco coautores de los documentos fundamentales de DNSSEC de 2005; su contribución duradera es el diseño de un protocolo colectivo, no una invención individual ni un control personal sobre la raíz.
  • NSEC3, Extended DNS Errors y DNS Error Reporting revelan una trayectoria profesional centrada en hacer que los fallos criptográficos sean diagnosticables sin tratar señales opcionales como evidencia completa.
  • La rotación de la KSK de 2026, el proyecto DELEG y el dry-run de DNSSEC sitúan su trabajo actual en la frontera entre el mantenimiento necesario y el riesgo de dejar fuera de servicio a resolutores independientes.

La etiqueta de clave 38696 convirtió un cambio global en una tarea local

En julio de 2026, Roy Arends publicó un número que la mayoría de los administradores de red no necesita conocer en circunstancias normales: 38696. Es la etiqueta de la KSK-2024, la nueva clave de firma de claves preparada para la raíz del sistema de nombres de dominio. ICANN planeaba empezar a firmar la raíz únicamente con esta clave el 11 de octubre de 2026. Se suponía que el cambio sería invisible para la mayoría de los usuarios.

Pero para un resolutor que valida DNSSEC y no había aprendido el nuevo ancla de confianza, el efecto podía ser severo: los nombres firmados podían dejar de resolverse aunque los sitios web, los servidores de correo y las redes que hay detrás funcionaran con normalidad.

Las instrucciones prácticas parecían sencillas. Los operadores de resolutores debían comprobar que la etiqueta 38696 estuviera presente en la configuración de las anclas de confianza y asegurarse de que los mecanismos de actualización automática pudieran escribir en los archivos correspondientes. Sin embargo, esa comprobación sencilla ocultaba la estructura completa del problema. No existe un registro global de todos los resolutores recursivos, ni un único administrador capaz de obligarlos a todos a actualizar, ni un canal de medición único que informe de cada configuración defectuosa.

Y una clave que se prepara en una ceremonia central solo se vuelve fiable en la práctica después de que miles de sistemas autónomos la acepten.

Arends señaló que más del 95 % de los resolutores que envían la señal de reporte correspondiente ya habían reconocido la KSK-2024. El denominador importa tanto como el porcentaje. Son resolutores que enviaron una señal de preparación utilizable, no un censo de todas las instalaciones de validación en Internet. Los equipos que dejaron de reportar, que operan con configuraciones distintas, que llevan mucho tiempo desconectados o que no pueden modificar un archivo de ancla de solo lectura pueden quedar fuera de la medición.

El porcentaje respaldaba cierto grado de confianza, pero no convertía un sistema distribuido en un sistema bajo control central.

Esta distinción recorre el historial público de Arends. Ha trabajado en las reglas que permiten documentar los datos de DNS, en mecanismos que hacen más comprensibles las respuestas negativas y los fallos, y en investigaciones que reducen el riesgo de cambiar un sistema que no tiene una ventana de mantenimiento unificada. En la fecha de cierre de la investigación, el IETF Datatracker registraba su nombre en siete RFC publicados, entre ellos los tres documentos que establecieron la arquitectura moderna de DNSSEC, NSEC3, Extended DNS Errors y DNS Error Reporting.

Su nombre también aparecía en trabajos activos sobre ampliación de la delegación y dry-run de DNSSEC.

El historial importa, pero es propenso a las leyendas de heroísmo que rodean gran parte de la infraestructura de Internet. Arends no inventó DNSSEC por sí solo. No opera personalmente la zona raíz, ni dirige el conjunto de servidores raíz, ni decide en qué debe confiar cada resolutor. Su poder proviene de especificaciones compartidas, investigación institucional, mediciones, revisión colectiva y explicación operativa. Por eso la pregunta que organiza este perfil es menos vistosa y más útil: ¿cómo ayuda un ingeniero de estándares a cambiar una infraestructura crítica cuando quienes ejecutan el cambio siguen siendo independientes?

La autoridad de la raíz se repartió deliberadamente entre varias partes

La raíz del DNS suele describirse como si fuera un único dispositivo o una única institución. Pero operativamente es una cadena de responsabilidades separadas. ICANN coordina los identificadores únicos y el trabajo técnico y de políticas asociado. Public Technical Identifiers ejecuta las funciones de la IANA. Verisign asume las tareas de Root Zone Maintainer conforme a arreglos específicos. Doce organizaciones operan las trece identidades nombradas de los servidores raíz mediante una arquitectura distribuida.

Y los operadores de resolutores recursivos eligen el software y deciden si realizan validación DNSSEC y mantienen anclas de confianza locales.

Arends trabaja dentro de una sola parte de esa cadena. Su biografía en ICANN indica que se incorporó a la organización en julio de 2015 y lo describe como Principal Research Scientist, responsable del diseño de investigación, la recopilación y el análisis de datos y la entrega de proyectos. El perfil también muestra la designación Distinguished Technologist. Estas formulaciones acreditan un rol técnico e institucional, pero no le otorgan autoridad ejecutiva sobre las organizaciones y los operadores que rodean la raíz.

La distinción va más allá de la precisión del título. La autoridad distribuida es una de las razones por las que el DNS puede resistir el fallo de una parte o su desacuerdo con las demás. También es la razón por la que el cambio es lento. Un plan para la zona raíz puede prepararse con enorme cuidado y luego chocar con software de resolutor antiguo, lógica de actualización defectuosa, relojes imprecisos, permisos de archivo restringidos o políticas locales que un equipo central no puede inspeccionar.

Por eso la coordinación debe pasar por reglas publicadas, largos periodos de preparación, identificadores verificables y pruebas de que una parte suficiente de la base instalada está lista.

El trabajo de estandarización se reparte de forma similar. Los RFC llevan los nombres de sus autores, pero son producto de debates de grupos de trabajo, experiencia de implementación, objeciones, revisiones y la revisión más amplia en el IETF. Y el Datatracker no registraba para Arends un cargo oficial activo en la fecha de cierre. Eso no borra su autoría; aclara la fuente de su autoridad. Podía proponer, explicar y persuadir, mientras que el consenso y la publicación correspondían a una comunidad más amplia.

Sería un error presentar cualquier perfil suyo como el del hombre que controla la seguridad del DNS. Su trabajo fue importante precisamente porque el control está disperso. El desafío de ingeniería consiste en hacer converger decisiones independientes sin pretender que se hayan convertido en una sola decisión.

Esta separación también limita el daño que podría causar un solo error, pero dificulta más atribuir responsabilidades durante los incidentes. Una firma defectuosa en una zona secundaria corresponde a un operador; un ancla de confianza obsoleta corresponde a otro; y un problema de publicación en la raíz exige una cadena institucional distinta. El usuario, en cambio, ve los tres casos como un nombre que no resuelve. Un buen diseño debe mantener esas fronteras internamente y, al mismo tiempo, producir evidencia suficiente para que quienes están fuera puedan localizar la falla.

Cinco autores establecieron las reglas operativas modernas de DNSSEC

El sistema de nombres de dominio ordinario asocia nombres con registros que usan las aplicaciones y las redes. Su diseño original no daba al resolutor un medio criptográfico para demostrar que la respuesta no había sido sustituida. Un atacante capaz de alimentar al resolutor con información falsa podía intentar redirigir el nombre, bloquear la respuesta correcta o envenenar la caché. Las extensiones de seguridad de DNS abordan esta debilidad permitiendo que las zonas firmen conjuntos de registros y que los resolutores verifiquen las firmas mediante una cadena de confianza.

La arquitectura que se usa hoy quedó definida en tres RFC publicados en marzo de 2005. El RFC 4033 explica el modelo y los requisitos. El RFC 4034 define los formatos de registro, entre ellos DNSKEY, RRSIG, NSEC y DS. El RFC 4035 describe los cambios exigidos a los servidores autoritativos y a los resolutores que validan firmas. Roy Arends coescribió los tres documentos con Rob Austein, Matt Larson, Dan Massey y Scott Rose. Los cinco nombres importan porque el protocolo fue un trabajo colectivo basado en esfuerzos anteriores de DNSSEC, no la invención repentina de una persona.

El proceso de firma de zona produce firmas digitales sobre conjuntos de registros de recursos, o RRsets. Las claves públicas necesarias para verificar esas firmas se publican en registros DNSKEY, mientras que los registros RRSIG llevan las firmas. Una zona padre puede publicar un registro DS que identifica una clave utilizada por la zona hija. Partiendo de una clave de confianza, el validador puede seguir la relación de padre a hijo y clasificar la respuesta como segura, insegura o inválida según las reglas del protocolo.

Este proceso de búsqueda atraviesa zonas administrativamente independientes. El validador puede partir de un ancla de confianza de la raíz configurada localmente, verificar los datos firmados de la raíz, usar el registro DS del padre para autenticar la clave del hijo y continuar hasta el nombre solicitado. Una zona no firma en nombre de todas las demás. Cada administrador controla sus claves y sus registros, mientras que el protocolo compartido permite comprobar la integridad de las entregas. Un fallo en una sola delegación puede romper la cadena aunque las zonas por encima y por debajo estén intactas.

La palabra decisiva esautenticación. DNSSEC puede aportar prueba de que los datos de DNS firmados son los datos autorizados a través de la cadena de confianza, y que no se modificaron sin que se detectara. Pero no cifra la consulta ni la respuesta. Tampoco prueba que el servicio indicado sea éticamente correcto, esté actualizado o esté disponible. Un registro de sitio puede apuntar correctamente a un destino malicioso, y una respuesta segura puede llevar a una conexión de aplicación que falla por razones ajenas al DNS.

Este alcance limitado es una ventaja cuando se entiende correctamente. El protocolo resuelve un problema específico de integridad de datos sin convertir el DNS en una lista centralizada de servicios aprobados. Permite que zonas administrativamente independientes participen en una cadena de validación común. Y los mismos límites imponen disciplina operativa: cada eslabón debe crearse, publicarse, renovarse y sincronizarse correctamente, y el validador necesita un ancla válida y algoritmos compatibles.

Los documentos de 2005 también tenían que convivir con el DNS no firmado. El despliegue no podía esperar a que todas las zonas se firmaran a la vez. Por eso el validador distingue entre una delegación explícitamente no firmada y una cadena firmada que falló. Una respuesta insegura puede aceptarse porque la cadena termina en un punto que las reglas permiten; una respuesta inválida se rechaza porque se esperaba una prueba criptográfica y no tuvo éxito. Con esta semántica, el despliegue gradual fue posible sin convertir cada ausencia de DNSSEC en una interrupción, y sin dejar de tratar una cadena firmada defectuosa como un fallo.

Estas semánticas trasladaron DNSSEC de una idea criptográfica a un sistema operativo interoperable. También fijaron el modo de fallo que ha marcado buena parte del trabajo posterior de Arends. Un mecanismo creado para impedir respuestas falsas debe a veces rechazar la respuesta entera. Y cuando el resolutor falla en modo cerrado, el operador necesita saber si el problema está en una firma, una delegación, un algoritmo, un reloj, un ancla de confianza o la ruta hacia un servidor autoritativo.

Los documentos se convirtieron en infraestructura porque distintos equipos de software pudieron implementar los mismos registros en la red y los mismos estados de validación. Eso no hizo que las implementaciones fueran idénticas. Los algoritmos compatibles, el comportamiento de la caché, los registros operativos, el tratamiento del tiempo y los errores mostrados al usuario siguen influyendo en el resultado. Las reglas compartidas reducen el espacio de variación a comportamientos comprobables, pero no eliminan el trabajo necesario para hacerlas fiables en cada resolutor o servicio autoritativo.

Un fallo en la confianza criptográfica puede aparecer como pérdida de acceso

Rara vez un fallo de DNSSEC llega al usuario etiquetado como un problema de cifrado. El sitio parece no estar disponible, el correo no llega o la aplicación dice que no encuentra el host. Los servidores autoritativos pueden estar en línea y la dirección de destino puede ser accesible. Pero el resolutor se negó a usar una respuesta de DNS porque la prueba que la acompañaba no coincidía con la cadena de confianza esperada.

Errores operativos ordinarios pueden producir este resultado. El padre puede publicar un registro DS que no coincide con la clave activa del hijo, una firma puede caducar, la zona puede usar un algoritmo que el resolutor no admite, un reloj incorrecto puede hacer que una firma válida parezca fuera de su periodo de validez, o el archivo de ancla de confianza puede quedar obsoleto. Cada fallo empieza siendo local, pero puede extenderse porque las aplicaciones dependen de la resolución antes de intentar conectarse.

La propiedad de seguridad que bloquea los datos falsos aumenta el costo del error operativo. El DNS no firmado suele devolver una respuesta incluso cuando la práctica de seguridad es débil. En cambio, una cadena DNSSEC defectuosa está diseñada para detenerse. Eso protege al usuario de aceptar datos que no pueden autenticarse, pero puede dejar un servicio legítimo inaccesible tras un error de clave o de delegación.

La arquitectura de 2005 preveía que el estado de validación influyera en el comportamiento del resolutor, pero el diagnóstico visible para el usuario siguió siendo limitado. A menudo las aplicaciones veían un fallo genérico de DNS en lugar de una explicación de la prueba que había fallado. Un ingeniero de una zona firmada podía ver servidores autoritativos intactos, mientras que usuarios remotos que dependían de la validación no recibían nada. Y la evidencia se quedaba dentro de un resolutor que a veces pertenece a otra organización y está en otro continente.

Aquí la corrección del protocolo se separa de su usabilidad operativa. Un estándar puede especificar exactamente cómo llega el validador a su decisión y, aun así, dejar el incidente opaco para las personas. El software puede registrar detalles locales ricos que no llegan automáticamente al operador de la zona, al servicio de soporte o a la aplicación. Y a medida que DNSSEC pasó de las pruebas controladas a la infraestructura cotidiana, los fallos necesitaron un lenguaje transferible.

Los RFC posteriores en los que participó Arends pueden leerse como un esfuerzo por aumentar la precisión de ese lenguaje. La pregunta ya no era solo si la respuesta superaba la validación. El sistema debe explicar el motivo del rechazo con la suficiente claridad para que lo corrija el operador adecuado, sin debilitar la protección que provocó el rechazo.

NSEC3 demostró la inexistencia sin publicar los nombres de la zona en orden

Las respuestas positivas de DNSSEC llevan registros firmados. La respuesta negativa soporta una carga distinta. Cuando el resolutor pregunta por un nombre inexistente, un atacante puede bloquear la respuesta real y afirmar que el nombre no existe. El validador necesita una prueba criptográfica de inexistencia, no solo datos firmados sobre lo que existe.

El sistema de 2005 incluía el registro NSEC. Los registros NSEC encadenan los nombres existentes en un orden canónico y forman una cadena firmada que prueba la ausencia de cualquier nombre entre dos puntos. El mecanismo es elegante, pero también permite recorrer la cadena y descubrir la secuencia de nombres de la zona. Los datos de DNS son públicos cuando se consultan, pero muchos operadores no querían que todo el conjunto fuera fácil de enumerar.

NSEC3, unificado en el RFC 5155 en marzo de 2008, cambió la forma de representación. Convierte los nombres de propietario en valores hash, y la cadena firmada cubre esos valores. El resolutor puede recalcular el hash correspondiente y comprobar que el nombre solicitado cae en un hueco probado. La zona ya no publica sus nombres directamente en orden lexicográfico a través de la cadena de negación. Arends coescribió el documento con Ben Laurie, Geoff Sisson y David Blacka.

El hash no convierte la zona en una base de datos secreta. Un atacante puede adivinar nombres probables, calcular sus hashes y compararlos con los valores publicados. El costo depende de los nombres, los parámetros y los recursos. Una zona llena de etiquetas predecibles puede seguir siendo relativamente fácil de analizar. Por eso NSEC3 reduce la enumeración directa, pero no garantiza confidencialidad.

La especificación también incluye el opt-out. Las zonas grandes basadas en delegación pueden excluir algunas delegaciones no firmadas de la cadena NSEC3, lo que reduce el trabajo de firma y el tamaño de la respuesta. Esta opción cambia las propiedades de la prueba y la seguridad en torno a esas delegaciones. Ayuda a que DNSSEC conviva con un gran número de zonas hijas no firmadas, pero aumenta lo que deben entender los validadores y los operadores.

Los parámetros también afectan al rendimiento. Más iteraciones de hash pueden elevar el costo de procesamiento en los servidores autoritativos, los dispositivos de firma, los validadores e incluso los atacantes, y pueden agrandar las respuestas negativas. Los valores deben elegirse según el modelo de amenaza y la capacidad del servicio, no asumiendo que más iteraciones son siempre más seguras. El mecanismo equilibra negación autenticada, exposición, tamaño y costo operativo.

Arends también coescribió el RFC 4956, un documento experimental de 2007 sobre DNSSEC Opt-In. Fue un intento anterior de hacer manejables las zonas padre firmadas mientras muchas delegaciones seguían sin firmar. El opt-out de NSEC3 se convirtió en la respuesta más longeva en la trayectoria de estandarización, pero la secuencia importa: las presiones del despliegue no aparecieron después de completar la arquitectura, sino que contribuyeron desde el principio a dar forma a los mecanismos que llevaron DNSSEC a entornos grandes y mixtos.

Esta contribución revela un patrón en el trabajo de Arends. En cuanto DNSSEC pudo probar la inexistencia, la propia prueba empezó a revelar información. NSEC3 no eliminó la tensión; cambió el equilibrio y documentó los costos. Los estándares de infraestructura rara vez eliminan todas las disyuntivas. Su valor está en hacer que la disyuntiva sea lo bastante clara para que implementaciones independientes produzcan resultados compatibles.

SERVFAIL no daba a los operadores suficiente información

Un resolutor que no puede responder puede devolver el código SERVFAIL. El código indica que el nombre no simplemente está ausente, pero abarca muchas causas. Un fallo de validación DNSSEC, la imposibilidad de llegar a un servidor autoritativo, un algoritmo no compatible, un tiempo de espera de red, datos obsoletos o una política local pueden dar el mismo resultado.

El RFC 8914, publicado en octubre de 2020, introdujo Extended DNS Errors. Arends lo coescribió con Warren Kumari, Evan Hunt, Mark Andrews y Wesley Hardaker. El mecanismo añade una opción en EDNS que transporta un código de información numérico y un texto explicativo cuando es necesario. El código de respuesta ordinario se mantiene, mientras que el código extendido describe la situación con más detalle.

El beneficio operativo es directo. El resolutor puede distinguir entre una firma DNSSEC caducada y un caso en el que ningún servidor autoritativo respondió. Puede señalar filtrado, uso de una respuesta obsoleta o efecto de una política. Y los operadores y las aplicaciones ya no tienen que deducir todas las causas a partir de un único fallo genérico.

La extensión aporta una prueba, no un conocimiento completo. El resolutor genera el código a partir de los límites de lo que vio y entendió. La causa original puede estar más arriba en la ruta, un intermediario puede eliminar la opción, una implementación puede admitir solo parte de los códigos o puede añadir un texto incompleto. La frase «firma caducada» es un indicio fuerte, no una prueba de que no exista otro problema.

El texto opcional abre otro límite. Un detalle legible puede acelerar el soporte, pero también puede revelar una política interna, decisiones de filtrado, topología o información de implementación. El operador debe pensar qué revela y a quién. Los códigos numéricos aportan estructura; el texto libre añade juicio local y un contexto que puede ser sensible.

Extended DNS Errors mejora la operación sin cambiar la decisión de validación. Una respuesta inválida sigue siendo inválida. No se pide al resolutor que reduzca la seguridad para que el usuario pueda entrar; se le da un medio para explicar el rechazo. La separación mantiene la propiedad de seguridad y hace que la reparación sea más práctica.

El documento también aclara qué tipo de autoridad ejerce Arends. Un RFC puede definir un vocabulario común, pero no obliga a cada resolutor, aplicación, intermediario y herramienta de soporte a conservarlo y mostrarlo. El beneficio crece con la implementación, la transmisión cuidadosa de la información y la práctica operativa. La publicación es el comienzo del trabajo, no la prueba de que esté terminado.

Además, el camino hasta la persona es desigual. El resolutor puede emitir un código preciso y el sistema operativo, el navegador o la aplicación lo sustituyen por un mensaje de conexión genérico. El equipo de soporte puede ver el síntoma sin los registros del resolutor. El estándar mejora la información en una capa; los productos y los procedimientos deciden si llega a la persona capaz de usarla. Por eso no basta con contar las implementaciones que pueden leer la opción para medir la dependencia útil.

Los informes de errores hacen visibles los fallos remotos y crean riesgos nuevos

Los errores extendidos mejoran lo que ve quien está cerca del resolutor. Pero no informan automáticamente al operador de la zona autoritativa cuyos datos fallaron. Y ese operador puede no tener relación directa con el resolutor afectado ni saber que usuarios remotos ven errores. El RFC 9567, DNS Error Reporting, publicado en abril de 2024, aborda esta brecha. Arends lo coescribió con Shumon Huque.

El mecanismo permite que un dominio designe un destinatario para los informes. Cuando un resolutor participante encuentra errores seleccionados, puede enviar un informe estructurado según las reglas de implementación, los límites de tasa y la política local. El objetivo es llevar a la parte responsable de la zona la prueba que de otro modo se habría quedado en registros remotos.

Esta retroalimentación puede acortar el tiempo de incidente. Una zona hija con un DS que no coincide puede parecer intacta en su propia monitorización si no prueba la validación desde suficientes puntos externos. Los informes muestran si los fallos se distribuyen entre redes, versiones de software o áreas geográficas. También revelan problemas de compatibilidad intermitentes que un único sistema de pruebas no detecta.

La información misma puede ser sensible. Un informe puede revelar que un resolutor intentó acceder a un nombre, el tipo de error, el momento y aspectos del comportamiento local. Un destino mal diseñado puede atraer una carga excesiva. Y un atacante puede fabricar errores o abusar del mecanismo para amplificación, sondeo o ruido operativo. Por eso el RFC 9567 hace opcional el reporte y aborda la privacidad y los límites de tasa en lugar de crear un flujo global de eventos.

Los datos resultantes seguirán teniendo el problema del denominador. Algunos resolutores informan y otros no. Algunos dominios publican un destinatario y otros no. Y los operadores pueden muestrear o bloquear eventos. Una ráfaga de informes prueba que existe un problema; un panel tranquilo no prueba que todos los resolutores estén bien. El mecanismo amplía la visibilidad sin convertirse en un censo global.

Este límite está en el centro del trabajo de Arends. Las señales mejores importan porque la responsabilidad del DNS está distribuida, y son incompletas por la misma razón. Cada organización decide si enviará los datos, los recibirá, los conservará o actuará a partir de ellos. El protocolo define el mecanismo de entrega, y la gobernanza, la privacidad y la confianza operativa determinan su utilidad.

Cuando DNS Error Reporting se convirtió en RFC, la trayectoria de contribución era más clara. Los documentos de 2005 definieron la validación. NSEC3 mejoró la prueba de ausencia. Los errores extendidos explicaron la decisión de rechazo. Y el reporte intentó llevar la prueba a quien puede reparar la zona. El trabajo pasó de la corrección criptográfica a un circuito de retroalimentación operativa.

ICANN acercó a Arends a la evidencia operativa

Arends se incorporó a ICANN en julio de 2015. El traslado situó a un veterano colaborador de estándares dentro de una organización que coordina identificadores únicos y apoya investigaciones sobre la raíz del DNS. Su misión declarada incluye el diseño y la ejecución de investigación, la recopilación y el análisis de datos. El registro no ofrece detalles de cada encargo interno, presupuesto o jerarquía administrativa.

El contexto institucional amplió el tamaño de las preguntas disponibles. Un documento del IETF puede definir qué debería hacer un resolutor o un servidor autoritativo. Una investigación vinculada a ICANN puede estudiar las operaciones de la raíz, la distribución de las anclas de confianza y el comportamiento de una base instalada diversa. Los dos caminos se complementan: los estándares necesitan evidencia operativa, y las mediciones necesitan conceptos de protocolo que interpreten lo que se ve.

El trabajo público de Arends en ICANN incluye el análisis de la raíz hiperlocal, la participación en el estudio de rotación de algoritmos de la zona raíz y la comunicación con operadores sobre la KSK de 2026. También usó la plataforma técnica de ICANN para explicar el trabajo en curso del IETF sobre delegación. Eso no convierte a ICANN en propietaria del proceso del IETF, ni a Arends en operador de cada sistema que estudia. Pero muestra un puente institucional entre investigación, estándares y operación.

Las partes en torno a ese puente mantienen roles distintos. Los participantes del IETF debaten el texto. Los equipos de ICANN estudian el sistema de identificadores y publican los resultados. PTI y Verisign ejecutan funciones específicas de la raíz. Los operadores de servidores raíz sirven la zona a través de sus sistemas. Los desarrolladores de resolutores convierten los estándares en software, y luego los administradores de red deciden el despliegue. Arends puede moverse entre estas conversaciones, pero la autoridad para actuar sigue en manos del operador de cada capa.

El puente tiene influencia porque ICANN llega a la planificación de la raíz, a las comunidades y a los datos. También necesita moderación. Las mediciones cercanas a la raíz pueden parecer más completas de lo que son. Cualquier cifra derivada de «resolutores que informan» debe conservar esa descripción. Un estudio sobre un posible algoritmo no puede presentarse como una decisión ejecutada. Y el borrador explicado en un blog de ICANN sigue siendo trabajo del IETF que puede cambiar.

La autoridad de Arends en este contexto es fundamentalmente técnica y reputacional. El registro no prueba un presupuesto unilateral, un liderazgo sobre los operadores de la raíz ni un derecho de veto sobre los estándares. Su trabajo puede influir en lo que monitorizan los operadores y en cómo las organizaciones formulan la transición, pero el cambio de claves, software o política local sigue estando distribuido.

El aplazamiento de 2018 cambió el enfoque de la siguiente rotación

La primera rotación de la clave de firma de la raíz se completó en octubre de 2018. Dio una lección práctica que el protocolo por sí solo no puede ofrecer. Se puede crear y publicar correctamente un ancla de confianza y, aun así, mantener suficientes dudas sobre la preparación de los resolutores como para justificar un aplazamiento, más medición y más comunicación.

El RFC 5011 define un método automático mediante el cual un resolutor que valida aprende un ancla de confianza nueva de DNSSEC. La clave nueva se publica mientras la antigua sigue siendo de confianza. El resolutor la observa durante un periodo determinado antes de aceptarla, lo que reduce el riesgo de confiar de inmediato en una clave efímera o maliciosa. El proceso supone que el resolutor funciona durante el periodo de observación, recibe los datos y puede guardar la actualización.

El periodo de observación es un control de seguridad. Impide confiar en la clave la primera vez que se ve y da al operador tiempo para detectar un cambio inesperado. También es una dependencia de disponibilidad. Un resolutor que pierde una parte suficiente del periodo de solapamiento no puede deducir la legitimidad de la clave sustituta. Una precaución que protege el ancla puede dejar una instalación desatendida incapaz de validar después de que se retire la clave antigua.

Los supuestos parecen normales hasta que uno falla. El resolutor puede llevar mucho tiempo desconectado, la función de actualización puede estar deshabilitada, el proceso puede ejecutarse con una cuenta que no puede escribir, una herramienta integrada puede seguir procedimientos de mantenimiento inusuales, o una configuración manual puede no adoptar la clave sin intervención. Publicar los datos correctos con más insistencia no arregla ninguna de estas circunstancias locales.

La experiencia de 2018 fomentó un programa de preparación más claro para la siguiente rotación. La nueva clave se publicaría pronto, se estudiarían las señales de los resolutores y los operadores dispondrían de una etiqueta concreta que comprobar. La concienciación se centró en las circunstancias locales que rompen la actualización, en lugar de asumir que cumplir el estándar garantiza el éxito.

La lección no es que aplazar haga siempre seguro el cambio. Esperar tiene un costo, entre otras cosas seguir dependiendo de la clave antigua y la pérdida de atención. La fecha debe llegar después de la evidencia, no sustituirla. Y en un sistema con instalaciones desconocidas, la decisión de seguir adelante combina medición, pruebas, experiencia de soporte y juicio sobre una población invisible.

Las orientaciones de Arends en julio de 2026 reflejan esa historia. Convirtieron una rotación institucional en una tarea para el operador: encuentra la etiqueta nueva, comprueba el archivo, verifica la ruta de actualización. Ya no prometían que todos los resolutores estuvieran listos, pero daban a cada administrador una forma de convertir el plan global en evidencia local.

Una señal del 95 % deja atrás resolutores desconocidos

El segundo programa de rotación comenzó en 2024. La KSK-2024 entró en la zona raíz el 11 de enero de 2025, lo que dio a los resolutores un periodo largo para observar la clave antes de la activación prevista para octubre de 2026. Y en julio de 2026, informes de ICANN indicaban que más del 95 % de los resolutores visibles a través de la señal correspondiente habían reconocido la clave.

La secuencia ilustra un cambio por etapas. La publicación no es la activación. Y reconocer la clave no significa que ya se haya superado el cese del uso de la antigua. Un resolutor puede tener el ancla nueva y fallar por un defecto de software, una política local, un reloj o cualquier otra parte de la ruta de validación. El periodo de solapamiento reduce el riesgo, pero no elimina todos los modos de fallo.

La preparación es un conjunto de condiciones, no un valor único. La clave debe ser visible y aceptada, debe persistir tras un reinicio, el software debe usarla cuando cambien las firmas, la monitorización debe distinguir un fallo de validación de una interrupción normal de acceso, y la organización debe saber quién puede modificar la configuración bajo la presión de un incidente. La señal previa confirma una parte de la cadena, no toda la respuesta.

El porcentaje restante merece atención, y también la población fuera de la medición. Los mecanismos de reporte seleccionan los sistemas que admiten la señal y la envían. Un resolutor público grande puede aparecer junto a muchas instalaciones detrás de traducción de direcciones. Y una señal puede representar a muchos más usuarios que otra. Un resolutor retirado puede distorsionar la observación histórica, mientras que un resolutor activo que no informa queda ausente.

Por eso la formulación responsable nombra el numerador, el denominador y el tiempo. «Más del 95 % de los resolutores que informan habían reconocido la KSK-2024 a finales de julio de 2026» es útil. «Internet está lista al 95 %» no está respaldada. La primera delimita el alcance de la prueba; la segunda oculta una incertidumbre decisiva.

Esta disciplina se aplica a otra infraestructura global. Un colector de rutas ve lo que envían sus pares, no todas las rutas. Un detector de interrupciones reúne las señales disponibles, no la experiencia de cada usuario. Las mediciones de DNS pueden mostrar una tendencia sin identificar cada sistema que fallará. La calidad del análisis depende de mantener los límites de la medición unidos a la cifra.

En la fecha de cierre, el evento decisivo era futuro. El plan del 11 de octubre solo puede evaluarse después de la activación, mediante informes de incidentes, casos de soporte, mediciones y la presencia o ausencia de fallos persistentes. Las orientaciones de Arends eran una entrada para obtener el resultado, no una prueba de que este se hubiera producido.

Una copia local de la raíz sustituye la distancia por una responsabilidad local

El resolutor recursivo envía normalmente algunas consultas al conjunto distribuido de servidores raíz y luego sigue las delegaciones a través de la jerarquía. El diseño hiperlocal coloca una copia de los datos de la zona raíz cerca del resolutor. Arends participó en la coautoría de un análisis de la Office of the CTO de ICANN de agosto de 2021.

El atractivo es evidente. El servicio local puede seguir respondiendo durante algunas interrupciones de conectividad ascendente. Las consultas no salen de la red del operador, lo que puede reducir la latencia y la exposición de los patrones de consulta en la raíz. Y las redes grandes obtienen un rendimiento más predecible y una menor dependencia de una ruta externa para el primer paso.

El diseño traslada la responsabilidad, no la elimina. La copia debe obtenerse, autenticarse, actualizarse y servirse correctamente. Una copia obsoleta o corrupta puede dar a todos los resolutores que la usan una visión desactualizada de la raíz. Y un error de configuración convierte una medida de resiliencia en un punto de fallo compartido. El operador debe definir qué ocurre si falla la actualización y cómo detecta la divergencia respecto a la raíz publicada.

La propiedad operativa se vuelve más importante durante un cambio de la raíz. Una copia que se actualiza correctamente distribuye los datos nuevos sin depender de cada ruta de consulta externa. Un proceso de actualización defectuoso puede conservar un estado antiguo después de que la raíz global haya avanzado. Por eso el diseño necesita comprobaciones independientes de frescura, validación y conmutación, no una confianza derivada solo de la cercanía.

También hay un efecto en la medición. Las consultas que se responden localmente no aparecen en las instancias públicas de los servidores raíz. Eso puede mejorar la privacidad de los usuarios, pero retira señales que investigadores y operadores usan para entender la demanda, la mala configuración y las anomalías. El sistema puede volverse más privado localmente y menos observable desde fuera.

El valor del informe es que no ofrece una receta general. La elección depende del tamaño de la red, la madurez operativa, el modelo de amenaza y la capacidad de asumir responsabilidad local. Una arquitectura que ayuda a un operador experto durante una interrupción ascendente puede imponer a un equipo más pequeño otro servicio crítico que debe parchear, monitorizar y recuperar.

Este trabajo conecta con un tema recurrente en Arends. La fiabilidad no depende solo de la disponibilidad central; depende de lo que ocurre cuando las funciones se trasladan al operador. Un sistema distribuido solo gana resiliencia con la independencia si se mantiene esa nueva independencia.

Un cambio de algoritmo llega a capas más profundas que la sustitución de una clave

La rotación de 2026 sustituye una clave dentro de un orden criptográfico conocido. Un futuro cambio de algoritmo de la raíz afecta a más capas. Deben admitirlo los resolutores, los sistemas de firma, los módulos de seguridad de hardware, las bibliotecas y las herramientas operativas. Un algoritmo puede ser criptográficamente superior y operativamente peligroso si una proporción significativa de la base instalada no puede procesarlo.

El Root Zone Algorithm Rollover Study, publicado en mayo de 2024, abordó la cuestión como un ejercicio de diseño. Arends participó en el trabajo colectivo. El estudio examinó el soporte de implementaciones, las capacidades de hardware, el tamaño de los mensajes, los arreglos de firma, los periodos de firma doble, la distribución de anclas y los entornos de prueba. No anunció ni ejecutó una rotación de algoritmo.

Los módulos de seguridad de hardware hacen tangible la transición. Las operaciones de firma de la raíz dependen de hardware y procedimientos controlados, por lo que el algoritmo candidato debe funcionar en los dispositivos y el entorno operativo, no solo en una biblioteca de software. La sustitución de hardware, certificados, diseño de ceremonias y pruebas puede marcar el calendario. La agilidad criptográfica es a la vez una cuestión matemática y una cuestión de suministro, herramientas y operación.

La diferencia entre clave y algoritmo es decisiva. La sustitución de clave pregunta si el sistema reconoce una instancia nueva de un tipo conocido. El cambio de algoritmo pregunta si entiende un método distinto, dispone de sus recursos y se comporta correctamente mientras conviven firmas. Puede alterar los tamaños de paquete, los riesgos de fragmentación, el costo de procesamiento y la lógica de selección o rechazo del material criptográfico.

La transición puede necesitar firmas paralelas para que los resolutores antiguos y nuevos funcionen durante el periodo de solapamiento. Eso mejora la compatibilidad, pero agranda las respuestas y aumenta el trabajo de firma y validación. La raíz está en la ruta de cada resolutor, por lo que un cambio pequeño en cada respuesta puede tener un efecto amplio. Las pruebas deben abarcar software común, dispositivos, bibliotecas y configuraciones difíciles de enumerar.

Las presiones posteriores de la computación cuántica aumentan la importancia de la agilidad, pero el material no prueba la elección de un algoritmo para la raíz ni la ejecución de una transición poscuántica. La conclusión respaldada es más estrecha: la raíz necesita una forma de evaluar cambios criptográficos futuros antes de que la necesidad prive al sistema de la opción de moverse despacio.

Una vez más, la evidencia debe preceder a la confianza institucional. Un equipo puede redactar estándares y los implementadores pueden anunciar soporte, pero solo las pruebas por etapas y la monitorización muestran el comportamiento del colectivo en redes reales. El algoritmo más fuerte es el que el sistema puede adoptar sin sacrificar la disponibilidad del DNS.

DELEG añadirá un nuevo contrato en la frontera entre padre e hijo

Una delegación de DNS indica al resolutor dónde comienza la autoridad de la zona hija. En el modelo habitual, el padre publica la información de los servidores de nombres y el registro DS del hijo firmado para vincularlo a la cadena DNSSEC. La información es deliberadamente limitada. Esta simplicidad ha sostenido décadas de interoperabilidad, pero deja un margen estrecho para anunciar capacidades nuevas antes de que el resolutor contacte con los servidores autoritativos del hijo.

El trabajo de DELEG en el IETF explora un mecanismo de delegación más extensible. Arends participó en el trabajo activo en la fecha de cierre y publicó una explicación en ICANN en abril de 2026. Uno de los posibles usos es proporcionar información que ayude al resolutor recursivo a establecer una conexión cifrada con un servidor autoritativo. El cifrado de la ruta de la aplicación al resolutor no protege automáticamente el paso siguiente, y los datos de delegación podrían ayudar a iniciar esa relación separada.

Esta distinción se pierde a menudo en el debate público sobre el DNS cifrado. El usuario puede enviar una consulta protegida a un servicio recursivo, mientras que el servicio puede conectarse a los servidores autoritativos por una ruta no cifrada. DNSSEC puede autenticar los datos firmados sin ocultar los nombres solicitados. La relevancia de DELEG radica en que podría permitir al resolutor conocer las capacidades de transporte antes de conectarse, combinando autenticación y confidencialidad de forma más clara sin tratarlas como la misma propiedad.

La propuesta toca una frontera fundacional. La zona padre puede transportar información más estructurada sobre cómo contactar con el hijo. Eso podría evitar la creación de un registro específico para cada capacidad futura. Pero puede hacer la delegación más grande y compleja, y aumentar las consecuencias de una divergencia entre los datos del padre y del hijo.

La compatibilidad determinará cuánto provecho se obtiene. Los resolutores antiguos deben seguir llegando a las zonas antiguas. Los nuevos necesitan un comportamiento de repliegue claro cuando la extensión falta, está dañada o no se admite. También hay que gestionar la degradación de seguridad: un atacante o un intermediario defectuoso no debería poder eliminar una capacidad de seguridad y hacer que el resolutor acepte en silencio una conexión más débil.

La relación entre el registro, el registrador, el operador de DNS y el titular del dominio gana importancia. Los parámetros de delegación adicionales deben crearse, verificarse, transferirse y eliminarse en sistemas de aprovisionamiento reales. Una coordinación de red limpia no garantiza que el registrador muestre los campos correctamente ni que el registro publique los cambios sin demora. Y cuando un valor incorrecto impide llegar al hijo, la responsabilidad de la reparación debe estar clara.

En la fecha de la investigación, DELEG seguía siendo un Internet-Draft. Su estructura, sus propiedades de seguridad y su alcance podían cambiar con la revisión del grupo. No existía un RFC final ni un despliegue global. Presentarlo como una práctica actual borra la diferencia entre una dirección de ingeniería y un estándar aplicado.

El valor de la participación de Arends también proviene de conectar la propuesta con lecciones anteriores. DNSSEC demostró que una relación de seguridad entre padre e hijo puede sostener una validación global, y que un error en la frontera puede ocultar nombres. DELEG busca añadir capacidad expresiva en esa misma frontera. Su éxito dependerá de que existan diagnóstico, reglas de transición y propiedad operativa capaces de contener los nuevos modos de fallo.

Las pruebas previas podrían hacer menos brusco un cambio de DNSSEC

Es difícil probar muchos cambios de DNSSEC en todos los resolutores antes de imponerlos. Una zona puede funcionar en su laboratorio y luego encontrarse fuera con software o políticas distintas. Y en cuanto la nueva configuración es efectiva, un problema de compatibilidad oculto puede convertirse en una interrupción inmediata para los usuarios de los resolutores afectados.

El proyecto activo dry-run DNSSEC considera una forma de mostrar la reacción de los validadores ante un cambio planificado sin que el fallo simulado controle la resolución real. La semántica precisa seguía en desarrollo en la fecha de cierre. La idea operativa es reunir resultados de «lo que habría pasado» antes del corte difícil.

Una prueba útil podría revelar un algoritmo no compatible, una cadena con un error compuesto o una política que provoca un rechazo inesperado. Los operadores podrían comparar lo que ven entre software y redes mientras la cadena actual sigue sirviendo a producción. Una parte de la transición binaria se convierte en un ensayo.

Para una zona grande o un servicio vinculado a la raíz, esto cambia la economía de la prudencia. Lo esperado puede compararse con lo observado antes de convertir a los usuarios en muestra de prueba. Los equipos de software descubren diferencias mientras la reversión sigue siendo fácil. Y la evidencia ayuda a seguir, aplazar o reducir el alcance. El valor del ensayo está en crear un punto de decisión antes de un compromiso difícil de revertir, no en predecir todas las circunstancias reales.

El ensayo tiene límites. Solo tiene sentido cuando las implementaciones admiten la señal y los operadores monitorizan el resultado. La participación temprana puede concentrarse en los sistemas mejor preparados, dejando fuera de la muestra a los resolutores antiguos. La ruta simulada puede diferir del código usado en la aplicación completa. Y surgen cuestiones de privacidad si los informes revelan características del resolutor o actividad de consulta.

Por eso el borrador no garantiza un despliegue seguro. Añade una capa de evidencia similar a los informes de anclas y a la retroalimentación de errores. Su valor depende de la claridad del denominador y de la capacidad de los operadores de actuar según lo que aprendan.

Para Arends, este trabajo completa un arco largo sin cerrarlo. Los RFC de 2005 definieron la decisión de validación. Los documentos posteriores mejoraron la prueba de negación y las señales de fallo. Y dry-run DNSSEC pregunta si la decisión puede observarse antes de permitirle interrumpir el servicio. Es un paso de describir el comportamiento correcto a gestionar el cambio en una red que nadie puede probar por completo.

Su influencia termina donde empiezan las decisiones de los operadores independientes

El historial público permite una descripción clara de la contribución de Arends. Es coautor principal del núcleo de la DNSSEC moderna, coautor de estándares posteriores sobre negación autenticada y observabilidad de errores, e investigador en ICANN que trabaja en cuestiones de la raíz, algoritmos y delegación. El registro no respalda una historia de inventor único, una autoridad operativa integral ni una biografía privada llena de conjeturas.

Su carrera también muestra cómo se acumula autoridad en una arquitectura abierta sin convertirse en propiedad. Un autor de estándares puede definir un vocabulario que perdura. Un investigador de ICANN puede formular mediciones, elegir señales de preparación y explicar el riesgo. Un colaborador experto puede conectar un borrador nuevo con fallos antiguos. Pero ninguno de estos roles obliga a un proveedor de resolutores a publicar código, ni a un registro a cambiar su sistema, ni a un operador a reparar su archivo.

Este límite es productivo. Obliga a las propuestas a pasar por la revisión de quienes soportan costos distintos. A los desarrolladores de resolutores les importa la compatibilidad y el soporte. A los registros y registradores les importa el aprovisionamiento y el tamaño. A los operadores autoritativos les importan las claves y la disponibilidad. Los defensores de la privacidad vigilan lo que revelan los informes. Y los socios de la raíz se centran en las ceremonias, la continuidad y la evidencia. Una especificación puede ser elegante e inaplicable si no responde a las preguntas de todos ellos.

La división del trabajo también cambia el tipo de prueba profesional. A un director de producto se le puede medir por los ingresos o la cuota de mercado; un colaborador de estándares deja documentos, revisiones, opciones de implementación y prácticas operativas. Su impacto puede ser amplio y difícil de atribuir numéricamente a una sola persona. La formulación segura es la que se ajusta al registro: Arends ayudó repetidamente a definir mecanismos que autentican los datos de DNS y hacen más observable el resultado de los cambios.

El modelo distribuido también mantiene limitado el tamaño del legado personal. DNSSEC, NSEC3, los errores extendidos y los informes pueden perdurar sin sus autores porque los documentos son públicos y muchas organizaciones mantienen las implementaciones. La influencia de Arends permanece en la arquitectura y en las preguntas que esta conserva, no en un control personal permanente.

El 10 de agosto de 2026, la mayor prueba de su trabajo actual seguía en el futuro. Si la KSK-2024 se convierte en la única clave el 11 de octubre con una perturbación limitada, será el resultado de años de ceremonias, soporte de software, informes, concienciación y gestión local en muchas organizaciones. Y si aparecen fallos, las preguntas útiles serán concretas: qué resolutores perdieron la etiqueta 38696, por qué falló la ruta de actualización, si las mediciones ocultaron poblaciones afectadas y cuánto duró la recuperación.

DELEG y dry-run DNSSEC afrontan una versión más larga de la misma prueba. Deberán juzgarse por un texto estable, implementaciones independientes, comportamiento de reversión, revisión de privacidad y evidencia de que registros, servicios autoritativos y resolutores pueden operar los nuevos mecanismos. El despliegue por sí solo no resuelve la cuestión.

La importancia del trabajo de Arends radica en que no ofrece una ilusión de control central. Trata el DNS como un sistema que debe cambiarse mediante reglas compartidas, evidencia visible y pasos reversibles. El pequeño número 38696 soporta esa carga. El éxito no se mide porque lo note cada operador, sino porque los operadores que deben actuar detecten el problema antes de que lo detecten los usuarios en su lugar.