Resumen
- XoT protege el contenido de una transferencia de zona frente a la vigilancia pasiva de una conexión en claro; no oculta necesariamente los extremos, el ritmo, el tamaño ni la información obtenible por consultas o enumeración.
- La afirmación operativa necesita pruebas separadas de identidad del primario, autorización de la solicitud, TLS obligatorio, finalización, aceptación de la réplica, coherencia del transfer group y custodia posterior.
El oyente no necesitaba solicitar la zona
Una lista de control puede rechazar a un cliente desconocido. TSIG puede autenticar mensajes y demostrar que un participante con la clave compartida los originó. Pero si la respuesta AXFR o IXFR viaja por TCP sin cifrar, un tercero situado en el camino no necesita superar ninguno de esos controles. No pide la zona: la lee mientras otro la recibe.
RFC 9103 elimina ese atajo. Publicado en agosto de 2021 como documento Standards Track del IETF, define XFR over TLS para transferencias completas e incrementales. El resultado es importante porque una sola sesión de réplica puede reunir nombres, direcciones y relaciones operativas que, de otro modo, exigirían una recolección lenta mediante consultas.
El alcance, sin embargo, es deliberadamente concreto. El modelo protege el contenido y el tamaño actual de la zona durante la transferencia. No pretende ocultar que existe la zona, que dos servidores intercambian datos ni cuáles son esos servidores. Tampoco promete borrar las señales de tiempo y volumen del tráfico cifrado.
Por eso «la transferencia estuvo cifrada» es una conclusión válida, mientras «la zona es privada» necesita muchas pruebas más.
Cuatro controles que suelen mezclarse
El primero es la identidad del servidor. El secundario debe saber que llegó al primario previsto, usando el perfil estricto de TLS descrito por RFC 8310. El segundo es la admisión del cliente. El primario ha de decidir si ese secundario puede copiar esa zona, mediante mTLS o una ACL de IP combinada con TSIG/SIG(0).
El tercero es la confidencialidad del canal. Todos los mensajes de la solicitud y la respuesta deben permanecer bajo TLS. El cuarto es el origen e integridad del mensaje, propiedad que TSIG aporta incluso cuando existe un proxy entre los participantes.
Estos controles responden a preguntas diferentes. TSIG, definido en RFC 8945, no cifra. TLS estricto autentica al servidor y protege el canal, pero una conexión aceptada no concede acceso automático a cada zona. mTLS autentica también al cliente, aunque la política aún debe relacionar esa identidad con una autorización concreta. Una ACL por IP añade una señal topológica que tampoco prueba por sí sola el contenido ni la intención.
En muchos servidores, la ACL se aplica cuando llega cada solicitud XFR, después de establecer la conexión. Abrir el puerto, completar TLS y aprobar un AXFR determinado son tres estados que no deben comprimirse en una única marca verde.
La excepción de migración es parte del perímetro
Los primarios y secundarios que intercambian un conjunto de zonas forman, en la terminología de RFC 9103, el transfer group. La protección completa requiere que todas las rutas AXFR e IXFR del grupo usen XoT. Una sola ruta heredada en claro conserva el observador que las demás eliminaron.
El riesgo suele aparecer en el camino excepcional: un secundario antiguo, una alternativa durante una incidencia, un proxy que termina TLS y reenvía por TCP, o una política que cifra IXFR pero permite que el fallback AXFR salga del canal protegido. La ruta cotidiana puede pasar una auditoría mientras la ruta de recuperación contradice la promesa.
El TLS oportunista tampoco basta. Puede continuar sin autenticar correctamente al servidor o volver al claro si TLS no está disponible. Eso puede ser preferible a nada en otros servicios, pero no sustenta una política que prohíbe el claro en XoT.
Algunas propiedades pueden probarse con solicitudes negativas: pedir la zona sin TSIG, desde una dirección no autorizada o por transporte en claro. Otras son difíciles de observar desde fuera: si todos los secundarios exigen firmas, si usan TLS estricto o si replican después a terceros. La coordinación y la imposición de una política común quedan fuera del alcance de la RFC.
La réplica cruza una frontera administrativa
Cuando el intercambio funciona, el secundario recibe una copia utilizable. Puede guardarla como archivo, diario, instantánea, base de datos o copia de seguridad. El personal y las herramientas internas pueden acceder a ella. Puede viajar a otros secundarios y alimentar respuestas autoritativas públicas.
Nada de eso invalida TLS. Simplemente ocurre después del límite que TLS protege.
La custodia debe aparecer, por tanto, en el mismo expediente que la conexión. ¿Quién puede leer la copia? ¿Dónde se conserva? ¿Qué contienen los registros de depuración? ¿Qué copias de seguridad persisten? ¿Qué nuevos pares pueden recibirla y quién aprueba su alta? Una identidad criptográfica correcta demuestra quién recibió; no demuestra qué hará el receptor.
ZONEMD deja visible otra separación. RFC 8976 describe un resumen para validar un objeto de zona independiente del transporte. Puede complementar XoT. No lo sustituye: un resumen no oculta los registros en tránsito, y un canal confidencial no demuestra que esos registros sean correctos, actuales o aprobados por la autoridad humana adecuada.
Todavía se puede preguntar al DNS
XoT no es una política de secreto total. RFC 9103 considera ortogonales la escucha de una transferencia y la enumeración de zona. NSEC puede facilitar el recorrido de una zona firmada; NSEC3 intenta encarecer esa operación mediante nombres hash, con sus propios límites. Las consultas autoritativas ordinarias siguen devolviendo los registros destinados a publicación.
La evidencia debe distinguir tres rutas: extracción masiva del flujo de réplica, enumeración mediante pruebas de inexistencia y acumulación de respuestas públicas. Cerrar la primera no cierra automáticamente las otras dos. Al mismo tiempo, que algunos datos sean públicos no justifica ofrecer toda la secuencia de réplica en claro.
Un recibo con ocho estados
El alcance identifica zona, transfer group, versión de política y responsables. La identidad primaria registra nombre de autenticación o pin SPKI, certificado, versión TLS y extremo. La admisión secundaria registra mTLS o ACL más TSIG/SIG(0), autorización por zona y pruebas de rechazo.
El transporte fija AXoT o IXoT, prohibición del claro, fallback y proxies. La finalización conserva serie solicitada y aceptada, conversión de IXFR a AXFR y errores. La custodia documenta almacenamiento, accesos, copias, registros y réplica posterior.
La exposición residual cubre consultas públicas, NSEC/NSEC3, relaciones visibles y señales de tráfico. La revalidación se activa ante cambios de certificado, clave, ACL, proxy, secundario, topología, firma u operador.
Ningún estado hereda la autoridad de los demás. Un handshake es una prueba del canal. TSIG es una prueba del mensaje. Una serie aceptada es una prueba de estado de réplica. Ninguno demuestra, a solas, confidencialidad de todas las copias.
Fuentes
- Registro de RFC 9103 en RFC Editor
- RFC 9103 — DNS Zone Transfer over TLS
- RFC 1995 — Incremental Zone Transfer in DNS
- RFC 5936 — DNS Zone Transfer Protocol
- RFC 8310 — Usage Profiles for DNS over TLS and DNS over DTLS
- RFC 8945 — Secret Key Transaction Authentication for DNS
- RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence
- RFC 8976 — Message Digest for DNS Zones
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
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

