¿Las consultas DNS siempre viajan a través de UDP?

He pasado un poco de tiempo investigando este tema y parece que no puedo encontrar una respuesta exacta, así que estoy bastante seguro de que no es un duplicado, y aunque mi pregunta se basa en una necesidad de seguridad, creo que todavía es seguro pregunte aquí pero avíseme si necesito moverlo a la comunidad de seguridad.

Esencialmente, ¿las consultas DNS alguna vez usan TCP (si es así, ¿qué escenario podría ocurrir esto?) De nuevo, solo estoy hablando de consultas. ¿Es posible que viajen a través de TCP? Si los dominios solo pueden tener un máximo de 253 bytes de longitud, y los paquetes UDP pueden ser tan grandes como 512 bytes, ¿las consultas no saldrán siempre como UDP? No pensé que una consulta resoluble pudiera ser lo suficientemente grande como para requerir el uso de TCP. Si un servidor DNS alguna vez recibió una solicitud de un dominio de más de 253 bytes, ¿el servidor lo descartaría / no intentaría resolverlo? Estoy seguro de que he hecho algunas suposiciones falsas aquí.

Por algún contexto, estoy trabajando con el grupo de seguridad para incorporar consultas DNS en su herramienta de monitoreo de seguridad, y por varias razones hemos decidido capturar este tráfico a través de la captura de paquetes estándar en servidores DNS y controladores de dominio. El requisito principal es capturar todas las consultas DNS para que puedan identificar qué cliente intentó resolver un dominio determinado. Según este requisito, no nos preocupa capturar respuestas DNS u otro tipo de tráfico, como transferencias de zona, lo que también se debe al hecho de que debemos limitar el volumen de registro tanto como sea posible. Como tal, estamos planeando capturar solo consultas DNS destinadas al servidor DNS y enviadas a través de UDP. Para más contexto (tipo de pregunta que se arrastra aquí), ahora se ha mencionado que podríamos necesitar expandir la seguridad ' s visibilidad para que puedan monitorear la actividad, como canales encubiertos que se ejecutan a través de DNS (lo que presentaría la necesidad de capturar también las respuestas de DNS y, posteriormente, el tráfico TCP). Pero incluso en ese tipo de escenario, pensé que cualquier tráfico DNS saliente sería en forma de búsquedas / consultas, y que siempre se realizarían a través de UDP, incluso desde una fuente maliciosa (debido a mi razonamiento en el primer párrafo). Entonces esto trae algunas preguntas adicionales:

• ¿No estaríamos al menos capturando la mitad de la conversación con el enfoque que describí? ¿O un cliente enviaría tráfico DNS que no sea en forma de consulta? (tal vez como algún tipo de respuesta a la respuesta de un servidor DNS, y tal vez termine saliendo por TCP)

• ¿Se pueden modificar las consultas DNS para usar TCP? ¿Un servidor DNS aceptaría y respondería a una consulta DNS que venga por TCP?

No estoy seguro de si es relevante, pero limitamos las solicitudes de DNS a servidores DNS autorizados y bloqueamos el resto del tráfico saliente a través del puerto 53. Definitivamente soy un novato, así que lamento si mi pregunta no cumple, y hágamelo saber Cómo debería modificar.

Las consultas DNS normales usan el puerto UDP 53, pero las consultas más largas (> 512 octetos) recibirán una respuesta 'truncada', que da como resultado una conversación TCP 53 para facilitar el envío / recepción de la consulta completa. Además, el servidor DNS se une al puerto 53, pero la consulta en sí se origina en un puerto aleatorio de alto número (49152 o superior) enviado al puerto 53. La respuesta se devolverá a este mismo puerto desde el puerto 53.

Puertos de red utilizados por DNS | Documentos de Microsoft

Por lo tanto, si está planeando hacer algunas indagaciones de seguridad en las consultas DNS de su red, deberá tener en cuenta lo anterior.

En cuanto al tráfico que no es de búsqueda, considere que el DNS también usa transferencias de zona (tipo de consulta AXFR) para actualizar otros servidores DNS con nuevos registros. Un hombre en el medio del ataque puede comenzar con una transferencia de este tipo, haciendo DDOS en un servidor de nombres primario para que esté demasiado ocupado para responder a un secundario que solicita registros actualizados. El hacker luego falsifica el mismo Primario para alimentar registros 'envenenados' al Secundario, que redirige los dominios DNS populares a hosts comprometidos.

Por lo tanto, su auditoría de seguridad debe prestar mucha atención al tipo de consulta AXFR, y sus sistemas DNS solo deben aceptar intercambios AXFR desde direcciones IP específicas.

Sala de lectura InfoSec del Instituto SANS | sans.org

Esto comenzó como un comentario a la respuesta de George, pero se hizo largo. La imagen más grande es algo complicada, ya que requiere comprender algo de historia.

• RFC 1035 originalmente solicitó un límite de 512 bytes para evitar la fragmentación UDP. Se eligieron datagramas fragmentados UDP y TCP como opciones de último recurso para minimizar la sobrecarga de las transacciones DNS. Las transferencias de zona siempre usan TCP, debido a que las transferencias de zona ocupan> 512 bytes por su propia naturaleza. (sería un desperdicio de ancho de banda comenzar con UDP)

• El reintento de TCP en truncamiento es ampliamente compatible ya que se ha especificado en RFC 1123 desde 1989.

• EDNS (0) está definido por RFC 6891 (2013), y antes existía como un Estándar Propuesto que data de 1999 . Define un mecanismo en el que los clientes y servidores pueden negociar tamaños UDP superiores a 512. Debido a la novedad de EDNS (0), muchos dispositivos de hardware hacen suposiciones sobre la estructura de los paquetes DNS que hacen que se descarten los paquetes compatibles. La razón más frecuente es suponer que los mensajes DNS de más de 512 bytes no son válidos, pero este es uno entre varios.

Si dividimos eso en los comportamientos observados:

1. Las consultas DNS generalmente comienzan como UDP, a menos que se sepa de antemano que la respuesta será demasiado grande para empezar. (transferencias de zona)
2. La respuesta puede desencadenar un reintento de TCP en el cliente si se ve una respuesta truncada. Esto está bastante bien respaldado.
3. Se puede ver una respuesta UDP de más de 512 bytes si el cliente usó EDNS (0) para anunciar una carga útil más grande y el servidor receptor lo admite. Esto solo sucederá si el hardware que se encuentra entre los dos no interfiere y resulta en un paquete caído o destrozado.
4. El cliente puede optar por volver a intentar una consulta EDNS (0) con una carga útil anunciada más pequeña si no se ve una respuesta, pero los detalles variarán entre las implementaciones.
   • Es importante tener en cuenta que la respuesta que finalmente se realiza puede ser demasiado grande para caber dentro del tamaño solicitado, lo que resulta en el comportamiento # 2 anterior. (ye olde TCP reintento)
   • El lado del cliente puede elegir recordar el tamaño que finalmente resultó en un éxito. Esto le permite evitar el desperdicio de consultas innecesarias que lo prueban nuevamente. Hacerlo de otra manera sería un desperdicio, particularmente si el resultado final requiriera el respaldo de TCP.

También debe tener en cuenta que RFC 7766 permite la reutilización de la conexión a través de TCP , y es posible encontrar la canalización de consultas a través de TCP en la naturaleza. Algunas herramientas no detectan las consultas DNS más allá de lo visto por primera vez en una sesión TCP, dnscap es un ejemplo de ello.

No es RFC 7766, Transporte de DNS a través de TCP - Requisitos de implementación .

1. Introducción

La mayoría de las transacciones DNS [ RFC1034 ] se realizan a través de UDP [ RFC768 ]. TCP [ RFC793 ] siempre se usa para transferencias de zona completa (usando AXFR) y a menudo se usa para mensajes cuyos tamaños exceden el límite original de 512 bytes del protocolo DNS. La creciente implementación de Seguridad de DNS (DNSSEC) e IPv6 ha aumentado los tamaños de respuesta y, por lo tanto, el uso de TCP. La necesidad de un mayor uso de TCP también ha sido impulsada por la protección que proporciona contra la suplantación de direcciones y, por lo tanto, la explotación de DNS en ataques de reflexión / amplificación. Ahora se usa ampliamente en la limitación de la tasa de respuesta [ RRL1 ] [ RRL2 ]. Además, trabajo reciente sobre soluciones de privacidad de DNS como [ DNS-over-TLS] es otra motivación para revisar los requisitos de DNS sobre TCP.

La Sección 6.1.3.2 de [RFC1123] establece:

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

Sin embargo, algunos implementadores han tomado el texto citado anteriormente para significar que el soporte TCP es una característica opcional del protocolo DNS.

La mayoría de los operadores de servidores DNS ya admiten TCP, y la configuración predeterminada para la mayoría de las implementaciones de software es admitir TCP. La audiencia principal para este documento son aquellos implementadores cuyo soporte limitado para TCP restringe la interoperabilidad y dificulta la implementación de nuevas características de DNS.

Por lo tanto, este documento actualiza las especificaciones básicas del protocolo DNS, de modo que el soporte para TCP es en adelante una parte REQUERIDA de una implementación completa del protocolo DNS.

Existen varias ventajas y desventajas en el uso creciente de TCP (ver Apéndice A ), así como los detalles de implementación que deben considerarse. Este documento aborda estos problemas y presenta TCP como una alternativa de transporte válida para DNS. Extiende el contenido de [ RFC5966 ], con consideraciones adicionales y lecciones aprendidas de la investigación, desarrollos e implementación de TCP en DNS y en otros protocolos de Internet.

Si bien este documento no establece requisitos específicos para los operadores de servidores DNS, sí ofrece algunas sugerencias a los operadores para ayudar a garantizar que el soporte para TCP en sus servidores y redes sea óptimo. Cabe señalar que si no se admite TCP (o el bloqueo de DNS sobre TCP en la capa de red) probablemente se producirá un error de resolución y / o tiempos de espera de nivel de aplicación.

No debe filtrar TCP / 53 en ninguna dirección. Por ejemplo, las nsupdateconsultas pueden usar TCP tan pronto como la solicitud sea demasiado grande (lo que puede suceder rápidamente). Por lo tanto, debe dejar que UDP y TCP para el puerto 53 (en IPv4 y V6!) Fluyan en todas las direcciones.

También hay más y más trabajo hacia DNS sobre TLS, por lo que se necesitará TCP en ambas direcciones. Ver RFC7858.