Resumen

  • RFC 2845 hizo que el MAC de una respuesta DNS firmada incluyera el MAC de la consulta que la había provocado.
  • En un intercambio DNS/TCP con varios mensajes, un MAC acumulativo cubría el MAC anterior y los mensajes intermedios, con TSIG en el primero, el último y, como mínimo, cada centésimo mensaje.
  • RFC 8945 cambió después la regla de envío para exigir TSIG en cada mensaje de respuesta, pero mantuvo una tolerancia limitada de compatibilidad para verificadores. Ninguna versión convierte la autenticación transaccional en confidencialidad, veracidad de los datos o autorización local.

Una respuesta no era un paquete aislado

Los identificadores y códigos de respuesta de DNS describían un intercambio, pero no autenticaban al interlocutor ni protegían la transacción frente a cambios. Publicada en mayo de 2000, RFC 2845 añadió TSIG: un registro de metadatos adjunto al mensaje DNS y verificado mediante un secreto compartido. Su alcance era deliberadamente entre dos pares. Ambos debían tener configurada la misma clave; distribuirla quedaba fuera de la especificación.

La decisión clave estaba en la entrada del cálculo del MAC. Primero, el cliente autenticaba su consulta. Al devolver una respuesta firmada, el servidor incorporaba el MAC de esa consulta, la respuesta y las variables TSIG de la respuesta. Así, el verificador no examinaba la respuesta como un objeto nuevo y sin contexto: la comprobación criptográfica retrocedía hasta la consulta. La hora firmada y el margen temporal también quedaban cubiertos; un intermediario no podía modificarlos y conservar un MAC válido.

Ese vínculo afirmaba algo sobre bytes cubiertos y una relación de claves. Como ambos pares compartían el secreto, una verificación correcta mostraba que el mensaje encajaba con la clave configurada; no identificaba a la persona o al proceso que la tenía. TSIG no cifraba DNS ni decidía si el servidor debía permitir una actualización. RFC 2136 definía DNS UPDATE; la política local aún debía determinar si ese par autenticado podía cambiar la zona.

Una transferencia se convirtió en una secuencia

El caso difícil era una respuesta repartida en varios mensajes, como una transferencia de zona por TCP. Si cada paquete se validaba por separado, se perdía la relación ordenada entre ellos. RFC 2845 exigía TSIG en el primero y el último, además de un punto de control firmado al menos cada cien mensajes. Entre puntos de control, cada mensaje DNS se incorporaba al cálculo del siguiente MAC en su orden, junto con el MAC anterior y los campos temporales pertinentes.

El verificador comprobaba continuidad dentro de un tramo acotado del flujo; no verificaba cada mensaje intermedio como si llevara una firma independiente. Si la comprobación fallaba, la RFC exigía cerrar la conexión TCP y tratar la transferencia como interrumpida, sin fijar un procedimiento exacto de reintento. Un punto de control válido cubre una parte del flujo recibido, no lo que el servidor almacenó después ni lo que un secundario llegó a servir.

La regla cambió; el límite, no

RFC 4635 añadió identificadores para algoritmos HMAC-SHA además del HMAC-MD5 original. En 2020, RFC 8945 sustituyó a RFC 2845 y RFC 4635 como estándar de Internet STD 93. Endureció el envío: un emisor conforme firma cada mensaje de la respuesta. La regla de compatibilidad del verificador es distinta: debe aceptar hasta 99 mensajes intermedios sin TSIG, pero exigir TSIG en el primero y el último. Esa tolerancia no autoriza a un emisor actual a omitir firmas.

RFC 8945 también delimita explícitamente lo que demuestra: TSIG autentica la transmisión entre dos pares que comparten un secreto, no el origen ni la corrección de los datos fuente. No es DNSSEC, que autentica datos con otro modelo de confianza. TKEY puede establecer claves en algunos despliegues, pero la distribución de claves no es una propiedad de TSIG. Los estándares describen un mecanismo acotado, no un sello de confianza universal.

Fuentes: RFC 1035; RFC 2104; RFC 2845; RFC 8945; RFC 4635; RFC 2136; RFC 2930.