Resumen

  • GSS-TSIG transporta la negociación de un contexto GSS mediante TKEY y protege mensajes con TSIG, sin decidir qué cambios DNS están autorizados.
  • La investigación debe probar por separado identidad, regla aplicable, acción permitida, mutación del primario, propagación y respuesta observada.

Supongamos que el primer evento del registro dice que la verificación fue satisfactoria. La tentación es usarlo como final del relato. En realidad, solo abre la siguiente pregunta. ¿Qué principal quedó autenticado? ¿Qué política estaba vigente? ¿Abarcaba ese nombre y ese tipo de registro? ¿Se ejecutó la operación? ¿Llegó el estado a los servidores relevantes?

RFC 3645 divide GSS-TSIG en dos etapas. Durante la primera, cliente y servidor intercambian tokens opacos de GSS-API dentro de TKEY y llaman a GSS_Init_sec_context y GSS_Accept_sec_context. Durante la segunda, el contexto ya establecido alimenta GSS_GetMIC y GSS_VerifyMIC, y las firmas viajan en registros TSIG. La versión de texto delimita el resultado: autenticación, no autorización.

El vocabulario operativo debe conservar esa frontera. Autenticar vincula el mensaje con un principal y un contexto. Autorizar compara ese principal y la acción solicitada con la política local. Aceptar una actualización es una respuesta de protocolo. Modificar la base de datos de la zona es un hecho de ejecución. Propagar y contestar una consulta posterior son hechos adicionales. Una organización que guarda un solo «éxito» destruye la trazabilidad entre ellos.

La composición del protocolo ofrece pistas para diseñar el registro. RFC 2743 define GSS-API; RFC 2930 usa TKEY para establecer claves; RFC 2845 formuló TSIG y RFC 8945 lo actualizó; RFC 4121 describe el mecanismo Kerberos v5 para GSS. Son piezas coordinadas, no una única decisión de confianza.

El contexto también caduca. Pasa por estados no inicializado, en negociación y establecido; se asocia a la relación entre cliente y servidor y tiene una vida finita. La negociación puede necesitar varios mensajes, con un máximo de diez intentos en los bucles definidos. La respuesta final firmada debe verificarse antes de considerar establecido el contexto. Si falla la comprobación, el mensaje no es auténtico; si caduca el contexto, no sobrevive una autoridad invisible.

RFC 3645 recomienda SPNEGO para negociar mecanismos y exige soporte de Kerberos v5 en su perfil de interoperabilidad, aunque permite otros mecanismos. Por eso la etiqueta gss-tsig no basta para una auditoría. Hacen falta mecanismo negociado, nombre objetivo, origen de credenciales, nombre de clave, vida del contexto, controles de repetición y secuencia, identidad del par y resultado de cada verificación.

La política aparece con claridad en RFC 3007: el administrador de la zona la configura, el servidor la aplica y la decisión depende del principal y de la acción deseada. Sin concesión explícita, la respuesta segura es negar el cambio. RFC 2136 define los prerrequisitos y operaciones de actualización dinámica. El principal autenticado es, pues, una entrada de la decisión, no la decisión.

Tampoco conviene mezclar seguridad de datos con seguridad de la transacción. RFC 4033 explica la autenticación de origen e integridad que ofrece DNSSEC. Una respuesta validada puede probar algo sobre los datos recibidos, pero no reconstruye por sí sola qué solicitud administrativa los introdujo. Del mismo modo, una solicitud autenticada no prueba que el nuevo estado se sirviera después.

El registro IANA de algoritmos TSIG coordina el nombre gss-tsig. El registro general de parámetros DNS y RFC 6895 coordinan valores del protocolo. Ninguno certifica un contexto activo, una identidad concreta, una regla local o una actualización realizada.

Para acotar las afirmaciones están la ficha del RFC Editor, la entrada de Datatracker, el historial del documento y los errata. Sirven para verificar la norma, no para inventar datos de adopción o atribuir fallos a productos actuales.

La lectura de Heng Lu sobre capas de realidad, especificación común mínima y primacía del código en ejecución ayuda a ordenar el poder. El estándar crea un suelo común para que sistemas distintos se entiendan. La política permanece en la organización que administra la zona. El servidor real y las consultas posteriores deciden qué estado existe. Saltarse esas capas convierte una señal técnica en una autoridad que nunca recibió.