Resumen

  • TC declara que el mensaje superó lo permitido por el canal. RFC 2181 aclaró que la marca corresponde a un RRset necesario que no pudo incluirse entero; el cliente debe ignorar esa respuesta y no aceptar como totalidad los registros visibles.
  • TCP permitió repetir la consulta con más capacidad y acabó siendo parte normal de DNS. RFC 7766 exigió UDP y TCP, incluso permitiendo empezar por TCP, y RFC 9210 convirtió su capacidad, paso por la red y observación en deber operativo.

Un límite de bytes podía convertirse en una mentira

RFC 1035 definió en 1987 el acceso a DNS por UDP y TCP en el puerto 53. Para preguntas ordinarias recomendó UDP: menos estado, menos preparación y la posibilidad de probar otro servidor si se perdía el datagrama. El mensaje UDP quedaba limitado a 512 bytes, sin contar las cabeceras de IP y UDP.

Cuando la respuesta era mayor, debía truncarse y activar TC. La sigla no describía el nombre consultado; describía el fracaso del canal para llevar todo el mensaje. No equivalía a NXDOMAIN, a validación fallida ni a una selección consciente de ciertos registros.

La diferencia protege el significado. Si cinco direcciones componen la respuesta y solo caben tres, el tamaño del paquete no puede decidir que el nombre tiene tres. La falta de espacio pertenece al transporte, no al propietario de los datos.

El RRset fijó la unidad indivisible

En 1997, RFC 2181 precisó que los registros con igual nombre propietario, clase y tipo forman un RRset. Una consulta que pide esos datos debe recibir el conjunto completo.

TC se reserva para el caso en que un RRset requerido no entra entero. No hace falta marcar truncamiento solo porque falten datos auxiliares de la sección Additional. El servidor puede omitir por completo ese RRset adicional y el cliente podrá pedirlo por separado.

Si TC sí aparece, el cliente debe ignorar la respuesta y repetir la consulta mediante un mecanismo que permita una contestación mayor, como TCP. La parte visible no es un anticipo válido que pueda mezclarse con registros antiguos del caché. Sigue siendo el residuo de una entrega incompleta.

La norma hizo explícita una disciplina poco vistosa: antes de optimizar con lo que llegó, hay que saber si aquello conserva la unidad semántica que se preguntó.

La nueva consulta pertenecía al resolutor

El servidor solo atestigua que este envío no bastó. El resolutor elige el siguiente acto: abrir TCP, reutilizar una conexión, consultar otro servidor o aplicar su política local.

TCP enmarca mensajes DNS con una longitud de dos bytes y no los ata a un único datagrama. A cambio, conserva estado, necesita admisión y añade tiempos de establecimiento e inactividad. Esos costes justifican límites operativos, pero no autorizan a alterar el RRset.

La responsabilidad acompaña al coste. El cliente decide cuántas conexiones inicia; el servidor decide cuántas admite y cuándo libera una sesión ociosa. El dueño de los registros conserva la autoridad sobre el contenido. TC mantiene esas funciones separadas.

EDNS aumentó la oferta sin conocer todo el camino

RFC 6891 permitió al solicitante anunciar cuánto contenido UDP podía recibir. Con EDNS(0), muchas respuestas dejaron atrás el límite original de 512 bytes sin abandonar el datagrama.

Pero ese número nace en un extremo. No describe necesariamente el MTU de todos los enlaces, túneles o equipos intermedios. Los fragmentos IP pueden perderse o filtrarse. DNSSEC añadió firmas y pruebas; otros usos modernos también hicieron crecer respuestas.

EDNS dice «ofrezco este espacio». TC dice «la respuesta requerida no entró en el espacio utilizable». Son afirmaciones complementarias. Si un datagrama grande desaparece antes de llegar, quizá ni siquiera haya TC que leer; por eso el silencio UDP debe distinguirse de una respuesta negativa de DNS.

TCP dejó de ser una rareza protocolaria

Durante años se resumió TCP como transporte de transferencias de zona y reintentos por truncamiento. La simplificación animó a algunos cortafuegos a bloquear TCP/53, justo el camino necesario cuando UDP no entregaba la respuesta.

RFC 7766 cambió esa posición en 2016. Las implementaciones DNS de uso general —autoritativas, recursivas, reenviadores y resolutores del sistema— deben admitir UDP y TCP. Además, ya no es obligatorio empezar toda consulta ordinaria con UDP. El resolutor puede usar TCP primero por motivos locales y debería reutilizar una conexión abierta.

Por tanto, TC suele iniciar un reintento sobre TCP, pero no gobierna toda elección moderna. TCP es un transporte alternativo por derecho propio; el principio común es obtener la respuesta completa, no repetir siempre el mismo ritual.

Hacer escalable el flujo requirió reglas propias

Abrir y cerrar una conexión por pregunta multiplica el coste del handshake. RFC 7766 recomienda reutilizar conexiones y canalizar varias consultas sin esperar cada respuesta. El servidor puede procesarlas en paralelo y devolver resultados fuera de orden.

El cliente debe emparejar cada respuesta con su consulta. Los monitores y servidores, por su parte, deben reconstruir el flujo: un segmento TCP no coincide necesariamente con un mensaje DNS completo.

También hay límites. Conviene reducir conexiones simultáneas hacia un mismo servidor, fijar admisión por cliente o subred y cerrar sesiones ociosas. La protección frente al agotamiento de recursos forma parte del transporte, siempre que no convierta un fallo explícito en una media respuesta aceptada.

La red tuvo que dejar de mirar solo UDP

RFC 9210 llevó la obligación al terreno operativo. Servidores y resolutores deben dar servicio por UDP y TCP, y los operadores de red deben permitir ambos en el caso general. Filtrar TCP daña DNS porque corta una salida prevista para respuestas grandes.

El servidor puede imponer límites, pero no rechazar una consulta únicamente porque habría cabido en otro transporte. La decisión de capacidad debe seguir el consumo real y el riesgo, no una jerarquía artificial entre respuestas.

La observación también cambia: hay que reensamblar streams, reconocer conexiones reutilizadas, consultas en pipeline y respuestas desordenadas. Un panel que solo cuenta UDP no ve una parte normal de DNS y no puede saber si TC terminó en recuperación o en un callejón sin salida.

Evitar fragmentos devolvió protagonismo al bit

RFC 9715 recomendó en 2025 evitar la fragmentación IP en DNS/UDP y limitar la carga al menor valor aplicable, con 1400 bytes como máximo recomendado cuando no rige uno inferior. La fragmentación es frágil y puede facilitar ataques contra el caché.

El documento mantiene intacto el efecto de TC. Si la respuesta no puede viajar con seguridad, el servidor puede marcarla; si los fragmentos se pierden, el solicitante debería acabar probando otro transporte.

Eso no promete que TCP siempre funcione. Promete algo más gobernable: la falta de entrega no debe confundirse con una respuesta completa.

El alcance estrecho era una virtud

TC=1 no demuestra censura, ataque, inexistencia, error DNSSEC ni propiedad del nombre. Tampoco obliga a usar exclusivamente TCP entre todos los transportes posteriores. Su afirmación cabe en una sola frase: este canal no entregó todo lo requerido.

Gracias a esa modestia, el bit sobrevivió a paquetes mayores, firmas, nuevos registros y nuevas conexiones. DNS aceptó que el primer intento tuviera límites, pero no aceptó que esos límites definieran la verdad.

Fuentes y límites

La definición original procede de RFC 1035; la integridad del RRset, de RFC 2181; la oferta EDNS, de RFC 6891; los deberes de TCP, de RFC 7766 y RFC 9210; y la guía de fragmentación, de RFC 9715. Ninguna de estas fuentes mide tasas actuales y globales de TC, filtrado o éxito de resolutores.