Resumen

  • RFC 3655 sustituyó una indicación amplia de política del servidor por otra más concreta: los RRsets pertinentes de la respuesta estaban autenticados conforme a las reglas revisadas.
  • AD es el informe de un resolvedor; no firma el paquete DNS ni demuestra que el resolvedor, la ruta de red o la política de confianza del usuario sean correctos.

Análisis

La escena es cotidiana: una aplicación consulta un nombre mediante un resolvedor local. El stub envía la pregunta a un resolvedor recursivo, que puede recorrer la cadena de claves, obtener firmas y reutilizar resultados en caché. Al volver la respuesta, un bit de la cabecera puede comunicar a la aplicación que ese trabajo ocurrió aguas arriba. La pregunta difícil no es cuántos bits contiene el campo, sino quién puede hacer esa afirmación y qué evidencia resume.

RFC 2535 había dado al bit Authenticated Data (AD) un significado amplio: el servidor decía que los datos de Answer y Authority estaban autenticados según su política. Publicado en noviembre de 2003, RFC 3655 sostuvo que esa señal no resultaba práctica. Un servidor conforme ya debía evitar devolver datos que incumplieran su política de seguridad; por eso, el bit describía sobre todo la postura general del servidor y no ayudaba a distinguir el estado de esa respuesta concreta.

La revisión afinó el relevo. Un servidor recursivo no debía activar AD si los RRsets pertinentes de Answer y Authority no cumplían las condiciones de autenticación. Debía hacerlo cuando los registros de respuesta —y los pertinentes que respaldaban una respuesta negativa— estaban autenticados. Eso no convirtió cada paquete DNS en un objeto firmado. DNSSEC autentica conjuntos de registros; AD resume el juicio local del resolvedor sobre los registros de esa respuesta.

La misma distinción separa DO y CD de AD. DO solicita que se incluyan registros DNSSEC; RFC 3655 exigía que se hubieran solicitado y que se devolvieran los registros SIG pertinentes para poder activar AD. CD deshabilita la comprobación para esa consulta. No borraba AD automáticamente: el servidor aún podía marcar datos ya verificados o conformes con su política local. Cada bit representa una etapa distinta: pedir evidencia, controlar las comprobaciones e informar un resultado.

Así, RFC 3655 convirtió al resolvedor recursivo en un intermediario de confianza. Las aplicaciones podían evitar incorporar cada una un validador completo y aprovechar la caché. Pero un stub no podía tratar AD como una prueba que se autentica a sí misma. Debía confiar explícitamente en el resolvedor y proteger la comunicación mediante un canal seguro o autenticación de mensajes como TSIG o SIG(0). Sin ello, un bit añadido por un respondedor en el trayecto seguía siendo una afirmación sobre la validación, no una prueba transmitida de forma segura.

La regla para servidores autoritativos revelaba otra frontera. Un servidor primario de una zona segura podía configurarse para activar AD, pero debía ser una opción explícita y venir desactivada por defecto. El documento reconocía que un autoritativo no tenía la obligación de validar los datos de su propia zona; verificar firmas al cargarla o en cada consulta podía tener un coste operativo. Por tanto, AD en una respuesta autoritativa directa no prometía, por defecto, la validación propia de un resolvedor recursivo.

También se presta a error interpretar AD=0. RFC 3655 prohibía AD cuando una respuesta era insegura, pero el bit apagado no permitía saber por sí solo si los datos eran inseguros, si el resolvedor no los comprobó, si faltaban registros DNSSEC solicitados o si el servidor optó por no afirmar ese estado. El bit activo tenía un significado dentro de una relación de confianza; el inactivo no era un diagnóstico completo.

En 2005, RFC 4033, RFC 4034 y RFC 4035 revisaron el marco DNSSEC y dejaron obsoleto RFC 3655. El relevo de estado mediante AD permaneció, pero dentro de una descripción más completa de validadores, stubs, autoritativos y rutas de autenticación. RFC 3655 se entiende mejor como una reparación de una interfaz limitada: transmitir la evaluación de un resolvedor sin fingir que el bit de cabecera era una prueba criptográfica.

La cadena de evidencia tiene varias capas. Una RRSIG puede respaldar la autenticación de un RRset mediante una cadena de claves y un ancla de confianza. El resolvedor validador toma una decisión local. AD puede informar de esa decisión. Un canal seguro con un resolvedor elegido y confiable puede vincular la respuesta con el servicio en el que el consumidor decidió apoyarse. Ninguno de esos hechos prueba por sí mismo que el titular de un nombre sea honesto, que la información siga vigente para una aplicación o que la aplicación haya actuado de forma segura.

Fuentes