Resumen

  • RFC 3008 exigió que una firma de datos superara controles de campos y correspondiera a una clave de zona antes de ser material para DNSSEC; acertar el cálculo criptográfico no bastaba.
  • Las claves de host y usuario podían autenticar transacciones SIG(0), pero la clave de zona firmaba el estado público, separando la identidad del solicitante de la autoridad para atestiguar el contenido de la zona.

Una firma correcta puede ser una prueba auténtica emitida por el testigo equivocado. Los bytes coinciden, el algoritmo responde y la clave es real, pero nada de eso decide por sí solo si esa clave representa a la zona DNS. RFC 3008 convirtió ese problema de autoridad en una comprobación obligatoria para el resolvedor de su época.

El documento llamó material a la firma relevante para la validación DNSSEC. Una firma de datos suele cubrir un RRset. Otras firmas podían tener una función definida por una aplicación, no estar unidas a un RRset o proteger el mensaje completo como SIG(0). Eran inmateriales para la cadena DNSSEC sin ser necesariamente inválidas. La clasificación venía antes de atribuirles poder público.

La regla revisaba la amplitud de RFC 2535, donde claves de zona, host o usuario podían firmar datos bajo determinadas condiciones. La flexibilidad tenía una promesa operativa: durante una actualización dinámica, el host firmaría lo que aportaba y la clave privada principal de la zona podría permanecer fuera de línea.

El resto del sistema frustraba esa promesa. Una zona segura con cambios dinámicos debía volver a firmar conjuntos SOA y NXT. El camino de RFC 3007 ya requería, por tanto, una capacidad de firma de zona en línea. Si esa clave estaba presente y podía firmar la información admitida, aceptar además las firmas de cada host como evidencia pública no eliminaba el riesgo que motivó el diseño. Sí obligaba a cada resolvedor a deducir una relación de autoridad más compleja.

RFC 3008 impuso una línea común: los datos de una zona segura debían llevar la firma de una clave de zona. El resolvedor ignoraría las demás claves para una firma de datos material salvo que una política local explícita dispusiera otra cosa. La decisión redujo combinaciones posibles, limitó la cadena de verificación por la profundidad de etiquetas del nombre y ancló la autoridad en la estructura visible de zonas.

El papel de zona no anulaba las demás pruebas. El campo type covered de una data SIG debía coincidir con el tipo del RRset. El algoritmo tenía que ser reconocido y contar con un formato SIG definido. El número de labels no podía superar el del nombre propietario. Original TTL debía ser al menos el TTL actual de la SIG, porque un intermediario no puede aumentarlo. El reloj de validación tenía que caer entre inception y expiration.

Después, signer name, key tag y algoritmo debían localizar una KEY candidata. Sin coincidencia, la firma quedaba fuera del procesamiento. Cuando varias claves compartían esos selectores, todas seguían siendo candidatas hasta que la operación criptográfica identificara la que produjo la firma. El éxito matemático llegaba dentro de un conjunto previamente acotado; no concedía a la clave un papel retrospectivo.

La KEY también declaraba límites. Sus flags tenían que permitir autenticación. Para datos materiales, name type debía ser zone. Protocol debía indicar DNSSEC o ALL. El algoritmo de la KEY tenía que coincidir con el de la SIG. Una clave capaz de generar la misma operación podía ser inadmisible porque el registro la destinaba a otro protocolo o a otra clase de actor.

Cada comprobación daba un recibo distinto. La criptografía vinculaba clave, firma y entrada. La elegibilidad validaba la forma. El tipo de clave determinaba la autoridad para ese objeto. La cadena llevaba desde un punto de confianza hasta la zona. El intervalo temporal acotaba la vigencia. Incluso el conjunto completo no demostraba que el servicio detrás de una dirección siguiera vivo ni que el dato fuera verdadero en todos los sentidos; protegía la aseveración DNS que la zona publicaba.

SIG(0) conservó un espacio propio. Una SIG con type covered igual a cero protegía una solicitud o transacción DNS según RFC 2931. Como la transacción la inicia una persona o un host, la clave esperada era user o host/entity. Un servidor de nombres actuaba aquí como host, no como encarnación de una zona. Por eso las claves de zona no debían generar normalmente SIG(0).

La diferencia no invalidaba a las claves de host; afinaba lo que demostraban. Una podía autenticar al principal que enviaba una actualización. El primario aplicaba luego su política local de RFC 3007, restringiendo nombres, tipos y acciones, con denegación como punto de partida. Si admitía el cambio, la clave de zona firmaba el estado destinado a los resolvedores. Propuesta, autorización y atestación pública no se fusionaban.

Este diseño también evitó publicar la política privada de acceso del primario. El resolvedor no necesitaba reconstruir qué cliente tuvo permiso para producir cada RR. Recibía una regla estándar para los datos. El operador podía cambiar su control de actualización sin cambiar el formato DNS ni pedir que todos los resolvedores aprendieran una nueva gramática institucional.

El campo signatory del antiguo KEY quedó al margen. RFC 3008 no le asignó valores ni exigió que estuviera presente. Codificar autoridad en pocos bits parecía portable, pero ataba políticas futuras a una enumeración fija y confundía admisión con validación. La alternativa creó dos superficies: configuración local para aceptar una actualización y clave de zona para la evidencia pública.

La solución pertenece a una generación histórica concreta. RFC 3090 aclaró el estado seguro de una zona en ese marco. RFC 3658 añadió el registro DS y cambió la unión entre delegaciones. RFC 4033, RFC 4034 y RFC 4035 terminaron sustituyendo la arquitectura KEY/SIG de RFC 2535 y RFC 3008.

No corresponde, por ello, presentar RFC 3008 como receta actual ni equiparar sin explicación sus bits KEY con DNSKEY y RRSIG. El informe RFC 3130 mostró que en 2001 DNSSEC se entendía como una caja de herramientas cuyas piezas evolucionaban a ritmos distintos. Documenta la incertidumbre de esa etapa, no una implantación universal ni una mejora cuantificada causada por este texto.

Lo duradero es el orden de decisión. Una prueba no transporta automáticamente su mandato. El código que la recibe debe comprobar el rol del firmante, la clase de objeto, el uso declarado, el tiempo y el camino de confianza. De lo contrario, una respuesta matemática precisa puede convertir posesión de clave en autoridad para definir una verdad pública.

Con la lente Running-Code Primacy de Lu Heng, la autoridad surge cuando el resolvedor ejecuta todo el proceso y conserva sus resultados, no cuando la firma aparece en el paquete. La regla de clave de zona ofrece el mínimo común. Una excepción local puede existir, pero no se vuelve norma global por permanecer oculta. La estabilidad depende de poder reconstruir cada eslabón, no de un único indicador verde.

RFC 3008 quitó magia a la firma y le añadió responsabilidad. Firmar prueba control de una clave; los campos declaran propósito; la posición de zona aporta rol; la cadena aporta confianza; el tiempo aporta vigencia. Solo su encuentro convierte una firma válida en evidencia autorizada para ese RRset.

Sources