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


33

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.


2
Paging @Alnitak, estamos hablando de tu bebé. :)
Andrew B

¿Cómo puedo forzar la consulta DNS predeterminada para que funcione en modo TCP? . Aunque un OS X / macOS q / a con algunas modificaciones también funciona para Linux / Windows.
klanomath

Por supuesto, hoy en día con DNS sobre HTTPS y DNS sobre TLS y pronto DNS sobre QUIC ...
Patrick Mevzek

¿Por qué no redirigir todas las consultas DNS a (a) servidores DNS de su elección?
Craig Hicks

Respuestas:


38

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


1
Gracias George, cosas realmente útiles! Entonces, para aclarar rápidamente su primera oración: un paquete UDP solo puede caber 512 bytes, ¿verdad? Entonces, si una consulta DNS fuera mayor que 512, ¿no comenzaría a través de TCP directamente? Intenté probar esto yo mismo ejecutando wireshark y usando nslookup para resolver dominios grandes, pero parece que me impide probar dominios de más de 200 caracteres (no el número exacto, pero el punto es que no pude probar completamente este escenario) .
Caderade

3
No es la "consulta" sino la "respuesta" lo que sería más de 512 Bytes y el cliente no sabría cuál sería la "respuesta".
AbraCadaver el

77
@Caderade Sí, tiene razón en que pueden ser TCP o UDP, sin embargo, solo las Transferencias de Zona comenzarán como TCP. Las consultas del cliente serán UDP a menos que obtengan una respuesta del servidor que tiene el bit truncado establecido. Entonces puede usar TCP.
AbraCadaver el

1
¿Pueden los clientes usar TCP para respuestas pequeñas de todos modos?
Mehrdad

2
"un paquete UDP solo puede caber 512 bytes" No, es la suposición de que el búfer del cliente solo puede caber 512 bytes lo que hace que los servidores se comporten de esta manera. Los servidores pueden ser notificados de un búfer más largo usando EDNS.
Bryan

28

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.


Una de las razones para obtener un conjunto de bits truncado es la limitación de la tasa de respuesta (RRL). Como técnica de mitigación de amplificación de DNS, el servidor puede enviar paquetes truncados para que los clientes que se comportan bien cambien a TCP, con la esperanza de evitar respuestas a los paquetes de direcciones falsas.
Edheldil

Reutilización de la conexión: enseñe a su solucionador a pedir primero google.com, antes de que solicite scantycladladies.com, luego dnscap no se da cuenta. ;-)
Lenne

6

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.


2
Hola Ron: en realidad leí ese RFC antes de publicarlo, pero, por ejemplo, si miras en el primer párrafo, parece enfatizar que se requiere TCP para admitir respuestas más grandes: "El creciente despliegue de Seguridad de DNS (DNSSEC) e IPv6 ha aumentado los tamaños de respuesta y, por lo tanto, el uso de TCP ". Nuevamente, mi pregunta fue sobre consultas, pero gracias de todos modos.
Caderade

44
El RFC deja en claro que se requiere que TCP sea compatible con DNS, y analiza el uso de TCP por parte de los clientes. Por ejemplo, " Los clientes que utilizan TCP para DNS siempre deben estar preparados para restablecer las conexiones o volver a intentar consultas pendientes " .
Ron Maupin

Buen punto. Yo diría que ese comentario fue realmente útil dada la claridad adicional. Mi punto es que en realidad leí el RFC y todavía no estaba muy claro para mí que las consultas pudieran comenzar utilizando TCP, por lo que cuando volcó el RFC para obtener una respuesta, aunque cómico, no fue realmente útil. Me leyó como, las consultas van sobre UDP y si la respuesta es demasiado grande, el servidor DNS le informará al cliente que necesita comenzar todo esto y realizarlo a través de TCP. Así que pensé que aún cumpliría con mi requisito original porque habría capturado la solicitud original. En cualquier caso, agradezco su aporte.
Caderade

1
El INTERNET STANDARDRFC es tools.ietf.org/html/rfc1034 . Estás citando a PROPOSED STANDARDpara requerir TCP.
AbraCadaver el

3
Esa es una Normas Track RFC que actualizó una Norma Track RFC anterior sobre lo mismo. Esta respuesta aquí en Falla del servidor explica tales cosas. Incluso en el documento al que hace referencia, dice: " En Internet, las consultas se llevan a cabo en datagramas UDP o a través de conexiones TCP " . RFC 7766 es para aclarar que TCP es una parte requerida, más que opcional, de DNS.
Ron Maupin

3

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.


pregunta no tiene nada que ver con el filtrado, y su respuesta no agrega nada sobre las otras respuestas
Bryan

@Bryan, gracias por tu comentario muy útil y útil.
Patrick Mevzek

@PatrickMevzek Entendido: lo que intentaba decir es que solo permitimos el tráfico a direcciones IP específicas más allá de nuestro perímetro a través del puerto 53 (aunque TCP y UDP están permitidos).
Caderade
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.