Resumen

  • RFC 3090 sustituyó los estados por algoritmo y la categoría «experimentalmente segura» por tres atributos: globalmente segura, localmente segura y no segura.
  • El resolvedor seguía tomando una decisión binaria con su propia configuración: anclas, algoritmos, ruta elegida y pruebas de la frontera entre padre e hijo.

Una sola palabra ocultaba cuatro decisiones

El despliegue de DNSSEC era discontinuo. Una zona podía firmar sus registros aunque el padre no ofreciera una cadena confiable desde la raíz. Un grupo de prueba podía instalar directamente una clave. Otro resolvedor podía carecer del algoritmo o del punto de partida. Llamar «segura» a la zona sin nombrar esas condiciones confundía la acción del administrador con la conclusión del verificador.

RFC 3090 separó a cuatro participantes. El administrador decidía la condición de la zona. Un servidor de actualización dinámica debía conservarla al modificar datos. El padre declaraba el paso hacia el hijo. El resolvedor reunía los elementos y decidía si una respuesta quedaba validada. La firma del hijo, la señal del padre y la confianza local eran piezas relacionadas, no intercambiables.

Por eso el documento eliminó la posibilidad de que una zona tuviera un estado distinto para cada algoritmo. También retiró la etiqueta «experimentalmente segura». Para los resolvedores que recibían la clave, el experimento constituía una isla localmente segura; para el público general, la misma zona era no segura. No hacía falta inventar un cuarto estado.

La isla dependía de quién conociera su raíz

Varias zonas firmadas y contiguas podían estar debajo de un padre no seguro. El extremo superior de ese conjunto era la raíz de una isla. Los operadores que instalaban su clave como ancla podían validar hacia abajo, aunque la cadena global estuviera cortada por encima.

Así, dos resolvedores honestos podían describir de modo distinto la misma respuesta. El primero poseía el ancla y una ruta aceptable: veía una zona localmente segura. El segundo no tenía un origen confiable: la veía no segura. El contenido autoritativo era idéntico. La diferencia estaba en la memoria y la política del verificador.

Con varias anclas no bastaba escoger cualquiera. RFC 3090 definió la raíz de seguridad más próxima mediante la mayor coincidencia ordenada de etiquetas desde la derecha. Si el programa partía de una raíz más lejana, podía tropezar con una clave NULL y concluir que el descendiente no era seguro, aun cuando una isla cercana estuviera configurada. Las islas superpuestas convertían la selección de origen en una parte observable de la seguridad.

Una firma en una captura, por tanto, no prueba el veredicto de todos. Hacen falta el conjunto de anclas, el criterio que escogió una, los algoritmos disponibles, la ruta obtenida, la hora y la política. La validación era un evento producido por esos datos, no una propiedad absoluta de un fichero de zona.

El padre podía decir «seguro» mediante el silencio

La generación de RFC 2535 contenía una convención poco intuitiva. En un padre seguro, la ausencia de la KEY del hijo podía representar un hijo seguro, mientras que una clave NULL firmada señalaba uno no seguro. El caso positivo podía quedar en ausencia; el negativo dejaba un objeto firmado.

RFC 3090 reconoció el malestar operativo y aclaró la lectura, pero no rediseñó el mecanismo. Ese detalle impide convertir la mera ausencia de un registro en evidencia general. Primero debía demostrarse que se observaba un padre seguro, que la ausencia estaba autenticada y que se aplicaban las reglas históricas correctas.

RFC 3658 introdujo después DS. Las RFC 4033, 4034 y 4035 establecieron la arquitectura moderna con DNSKEY, RRSIG, NSEC y DS en lugar de KEY, SIG y NXT. Son fuentes para entender la transición, no permiso para sustituir los objetos que realmente existían en 2001 por sus equivalentes actuales.

Global describía una clase, no una promesa perfecta

Una zona globalmente segura debía satisfacer una lista exigente: algoritmos obligatorios, cadena de firmas del padre dentro del árbol, claves de firma adecuadas en el ápice, NXT y firmas para los conjuntos requeridos. Una zona localmente segura podía usar otros algoritmos o un camino configurado fuera del árbol, pero conservaba las propiedades de una zona firmada. El resto se clasificaba como no seguro.

Los términos «global» y «local» no certificaban el cumplimiento de un producto. Un resolvedor restrictivo podía aceptar solo la primera clase; otro, con más capacidades o configuración, aceptar ciertas zonas locales. En el instante de resolver, ambos reducían esas categorías a dos salidas: segura o no segura.

Ni siquiera la clase global eliminaba el fallo. Un resolvedor defectuoso podía aceptar datos malos; un padre subvertido podía romper la operación; una implementación podía ignorar el estándar. RFC 3090 no prometió una etiqueta invulnerable. Mostró cómo enlazar responsabilidades sin permitir que una de ellas hablara por todas.

Fuentes

  1. https://www.rfc-editor.org/info/rfc3090
  2. https://www.rfc-editor.org/rfc/rfc3090.html
  3. https://www.rfc-editor.org/rfc/rfc3090.txt
  4. https://datatracker.ietf.org/doc/rfc3090/
  5. https://www.rfc-editor.org/errata/rfc3090
  6. https://www.rfc-editor.org/rfc/rfc2535.html
  7. https://www.rfc-editor.org/rfc/rfc3007.html
  8. https://www.rfc-editor.org/rfc/rfc3008.html
  9. https://www.rfc-editor.org/rfc/rfc3658.html
  10. https://www.rfc-editor.org/rfc/rfc4033.html
  11. https://www.rfc-editor.org/rfc/rfc4034.html
  12. https://www.rfc-editor.org/rfc/rfc4035.html
  13. https://www.rfc-editor.org/rfc/rfc5011.html