Resumen

  • SEP identifica un uso operativo previsto para una clave DNSKEY y puede servir a herramientas que preparan registros DS o gestionan claves; no acredita autenticidad ni crea una cadena de confianza.
  • Las RFC 4034 y 4035 fijan el límite decisivo: un validador no cambia su conducta por el bit 15. Una clave marcada SEP también necesita el indicador Zone Key para verificar firmas de conjuntos de registros.
  • Edward Lewis figura como uno de los tres coautores de RFC 3757. El documento demuestra esa contribución concreta, no autoría exclusiva, una implementación determinada ni empleo vigente.

El indicador que no decide

Al cambiar una clave DNSSEC no basta con publicar la nueva DNSKEY en la zona hija: la zona padre debe publicar el DS que corresponde a esa clave. Si la relación no coincide, un resolvedor que valida DNSSEC puede no validar la delegación. Marcar la clave con SEP no corrige el traspaso; solo orienta a ciertas herramientas sobre qué llave pretendía usar el operador. Esa diferencia convierte un bit pequeño en una decisión operativa con consecuencias para la resolución de nombres.

La RFC 3757 apareció en abril de 2004 con Olaf Kolkman, Jakob Schlyter y Edward Lewis como autores. Añadió SEP al campo de bits de DNSKEY para señalar claves destinadas a funcionar como puntos de entrada seguros. Su descripción contempla ayudar a generar registros DS y reconocer claves para una configuración estática. A la vez, aclara que el protocolo de verificación DNS no utiliza SEP. Esa limitación impide leer la etiqueta como una credencial.

El caso más claro ocurre al preparar el DS. Una herramienta puede seleccionar una clave marcada SEP dentro del conjunto publicado por la zona hija. Aun así, el operador debe comprobar que el material resultante corresponde a la clave correcta, y la zona padre debe publicar el registro apropiado. Un bit en la zona hija no confirma lo que hizo el padre, no fuerza su aceptación y no valida por sí solo el contenido de una firma.

Las RFC 4034 y 4035 sustituyeron la RFC 3757 en marzo de 2005 y conservaron esa separación. La RFC 4034 presenta SEP como una pista para programas de firma o depuración. La RFC 4035 exige que el comportamiento del validador no cambie por su presencia. Además, SEP no reemplaza al bit Zone Key: la clave sigue necesitando este último para verificar firmas de RRsets. Uno expresa tratamiento previsto; el otro habilita una función protocolaria.

La RFC 6781 muestra por qué los equipos operativos siguen prestando atención a SEP. En un diseño común se marca la KSK, que participa en intercambios con el padre, y se deja sin marcar la ZSK. Sin embargo, ciertos despliegues usan un único tipo de clave para funciones que el modelo dividido separa. Una herramienta que presupone siempre KSK y ZSK distintas podría seleccionar o mostrar las claves de forma confusa. La advertencia de la RFC justifica probar esas herramientas; no demuestra que haya ocurrido una validación incorrecta.

Tampoco hay que mezclar SEP con REVOKE. La RFC 5011 define la actualización automática de anclas de confianza y usa otro bit para indicar revocación dentro de ese mecanismo. SEP no es el estado de revocación ni una señal que el validador deba convertir en confianza.

La evidencia biográfica también tiene límites. La RFC 3757 acredita que Lewis participó con otros dos autores; su perfil de IETF registra el documento y la página de autor de Internet Society ofrece contexto profesional acotado. Ninguno de esos registros demuestra que diseñara SEP en solitario, implementara un producto específico o siga trabajando para ARIN. La mención de ARIN en la RFC es histórica. Del mismo modo, los estándares explican semántica y reglas, pero no ofrecen cifras sobre adopción, errores o incidentes.

SEP es útil como indicación para gestionar claves; la confianza depende de las verificaciones y de la relación publicada por el padre.

Fuentes