Resumen

  • TCP es una ruta normal del servicio DNS, no sólo una excepción para transferencias de zona.
  • EDNS amplía el margen UDP, pero no garantiza la entrega en cualquier trayecto.
  • La evidencia de preparación debe seguir una consulta desde TC hasta la respuesta TCP completa y la reutilización segura.

El incidente revelador empieza con un panel en verde. UDP/53 responde rápido y los datos autoritativos están al día. Una respuesta mayor vuelve con TC. El resolvedor abre TCP, pero el sitio tiene una cola de aceptación corta, un temporizador de cortafuegos inadecuado o procesos que quedan detrás de un cliente lento. Los datos DNS son correctos; la ruta para entregarlos no está preparada.

La RFC 1035 definió servicio DNS por UDP y TCP en el puerto 53 y el prefijo TCP de dos octetos que indica la longitud. También advirtió que esperar datos TCP no debe bloquear el resto del servicio. EDNS amplió después el límite UDP original, pero una respuesta truncada sigue cambiando el trabajo necesario para terminar la misma pregunta.

La RFC 6891 permite anunciar el tamaño máximo de carga útil UDP que el solicitante puede reensamblar y entregar a DNS. Es evidencia de capacidad local, no una promesa sobre toda la ruta. Evitar TC en el laboratorio no elimina TCP del contrato de producción.

La RFC 7766 exige TCP en implementaciones DNS de propósito general y presenta la reutilización como una forma de evitar un establecimiento por consulta. Por eso hay que medir finalización concurrente, bloqueos y cierres, no sólo una conexión aceptada. La RFC 9210 refuerza el límite: abrir un socket una vez no demuestra un ciclo de vida acotado bajo la mezcla real de consultas.