Resumen
- RFC 3445 limitó los nuevos registros
KEYal valor de protocolo 3, DNSSEC, porque DNS sólo consultaba el tipo completo y la firma protegía todos los miembros del RRset. - No ordenó borrar el pasado: el autoritativo debía dejar de escribir valores obsoletos, pero el lector debía retenerlos al verificar para no alterar la firma ni fragmentar la caché.
El cajón universal carecía de divisores
En RFC 2535, KEY contenía banderas, octeto de protocolo, algoritmo y clave pública. El 1 correspondía a correo, 2 a IPsec, 3 a DNSSEC, 4 a TLS; 5–254 quedaban disponibles y 255 significaba cualquier protocolo. Parecía razonable aprovechar el directorio distribuido que ya existía.
La interfaz de consulta, sin embargo, veía KEY, no el octeto interior. Quien buscaba una clave recibía todo el conjunto del nombre. La firma DNSSEC tampoco separaba propósitos: cubría el RRset entero. Una única unidad de consulta y prueba encerraba varias políticas de confianza.
RFC 3445 llegó en diciembre de 2002 tras un despliegue experimental limitado. El texto, el registro editorial, el Datatracker, su historia, referencias, citas posteriores y erratas documentan la norma, no la cantidad de zonas ni el comportamiento real de los resolvedores.
Seis diferencias que el formato ocultaba
Las claves divergían en propósito, administrador, regla de autenticación, inclusión por servidores autoritativos, tratamiento por resolvedores y efecto de fallo o compromiso. DNSSEC era infraestructura esencial para la integridad de datos DNS; una clave de aplicación no tenía significado especial para DNS.
Al mezclar, el RRset crecía, cada respuesta llevaba material irrelevante y rotaciones independientes quedaban acopladas. Un programa descuidado incluso podía confundir una clave de aplicación comprometida con una clave de zona si ignoraba el campo de protocolo. La criptografía respondía correctamente a una pregunta semántica equivocada.
La reparación exigió protocolo 3 en nuevos datos autoritativos, reservó todas las banderas salvo el bit de zona 7 y cerró los valores 1, 2, 4, 255 y el rango de aplicaciones. Sólo Standards Action permitiría nuevas asignaciones. Los usos DNSSEC relacionados con RFC 2930, RFC 2931 y RFC 3007 seguían dentro; la vieja distinción host/usuario no.
No usar no significaba borrar
La compatibilidad de lectura era deliberada. Un valor distinto de 3 no podía autenticar datos DNS, pero debía conservarse al reconstruir el conjunto firmado. Eliminarlo antes de comprobar SIG cambiaba el objeto respecto del que firmó el emisor. Distintos filtros también podían dejar cachés con versiones incompatibles.
Así, RFC 3445 separó autoridad semántica de preservación probatoria: dejar de producir el formato antiguo, seguir analizándolo durante la transición y nunca conferirle una autoridad ya retirada. Es una estrategia más fina que “aceptar todo” o “rechazar todo”.
La familia RFC 4033, RFC 4034 y RFC 4035 sustituyó después a RFC 2535 y usó DNSKEY. Otros RR especializaron finalidades: SSHFP, CERT y TLSA. Son contexto de una arquitectura más explícita, no prueba de causalidad. IANA prueba el estado simbólico del registro, no adopción ni seguridad.
Compartir sintaxis no crea confianza común
Las capas de realidad de Heng Lu distinguen número registrado, bytes firmados, autoridad administrativa, código desplegado y resultado. El contenedor único borraba visualmente esas fronteras, pero no las gobernaba. La primacía del código en funcionamiento explica por qué el experimento pudo corregir al modelo: consultas, firmas y cachés mostraron el coste que el diagrama omitía.
La especificación inicial mínima favorece el menor objeto cuyos usuarios compartan reglas reales. DNS podía normalizar su clave de infraestructura sin convertirse en autoridad para todo uso criptográfico. Es una lectura editorial, no una atribución de motivos.
La lección queda en el límite del conjunto: si una consulta, firma y caché obligan a mover objetos juntos, ese conjunto ya define un dominio operativo. Debe coincidir con quién controla los objetos y qué ocurre cuando uno falla.
Fuentes
- RFC 3445
- Texto de RFC 3445
- Registro RFC Editor
- Datatracker
- Historia
- Referencias
- Citado por
- Erratas
- RFC 2535
- RFC 2930
- RFC 2931
- RFC 3007
- RFC 4033
- RFC 4034
- RFC 4035
- RFC 4255
- RFC 4398
- RFC 6698
- Parámetros DNS de IANA
- Heng Lu — capas de realidad
- Heng Lu — primacía del código
- Heng Lu — especificación inicial mínima
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
