¿Es cierto que un servidor de nombres tiene que responder consultas a través de TCP?

23

Soy el proceso de configurar un monitoreo de servidores DNS de varios hosts web grandes. Mi objetivo es comparar los tiempos de respuesta de sus servidores DNS mediante el seguimiento de su respuesta al ping.

En el proceso, descubrí que los servidores de nombres Bluehost no responden al ping. Traté de obtener más información ejecutando Pingdom DNS Check en bluehost.com y produjo el siguiente error:

El servidor de nombres ns1.bluehost.com (74.220.195.31) no responde consultas a través de TCP.

El servidor de nombres no pudo responder las consultas enviadas a través de TCP. Esto probablemente se deba a que el servidor de nombres no está configurado correctamente o debido a un filtro mal configurado en un firewall. Es una idea errónea bastante común que el DNS no necesita TCP a menos que proporcione transferencias de zona; tal vez el administrador del servidor de nombres no es consciente de que TCP generalmente es un requisito.

Me gustaría saber lo siguiente:

  • ¿En qué medida es verdadera la afirmación anterior?
  • ¿Cuáles son las implicaciones de un servidor de nombres que no responde consultas a través de TCP?
domain-name-system nameserver Taras Mankovski
fuente

Respuestas:

47

El texto de diagnóstico de Pingdom es exactamente correcto. TCP no es solo para transferencias de zona.

Las implementaciones del servidor DNS ahora son "obligatorias" (en la medida en que cualquier RFC requiere algo) para admitir TCP, según RFC 5966 , "Transporte DNS sobre TCP - Requisitos de implementación".

Tenga en cuenta que este es un requisito para la implementación del software del servidor, no se aplica estrictamente a la operación de ningún servidor; la práctica operativa no está cubierta.

Dicho esto, si sus servidores DNS particulares no están configurados para admitir TCP, o si está bloqueado, entonces el efecto a largo plazo será la incapacidad de admitir DNSSEC correctamente. De manera similar, cualquier otro dato DNS que provoque que las respuestas superen los 512 bytes podría bloquearse.

ob descargo de responsabilidad: escribí que RFC.

EDITAR RFC 5966 ahora ha sido reemplazado por RFC 7766

Alnitak
fuente
RE: práctica operativa, alguien que odia DNSSEC podría simplemente deshabilitar TCP y soltarlo en el firewall por si acaso. Como era de esperar, hay consecuencias. Ninguna cantidad de soporte para EDNS0 en dos puntos finales puede forzar a los dispositivos entre ellos a no interferir de alguna manera. (fragmentación, marcado falso por firewalls antiguos, etc.) Si tiene grandes registros DNS en su servidor de autenticación (TXT hinchado), se requerirá TCP si no desea excluir un segmento de su audiencia. Del mismo modo, deshabilitarlo en un servidor recursivo lo aísla de las respuestas DNS que su clúster de correo puede necesitar para tratar el correo no deseado.
Andrew B
3

debería admitir TCP y UDP: el TCP es para tamaños de respuestas> 512 bytes (lo que incluiría transferencias de zona) (de acuerdo con lo que he leído, de todos modos. Por lo general, habilito TCP y UDP para los NS que ejecuto ...)

Mark Regensberg
fuente
-2

Es bueno saber lo que dicen los RFC sobre el tema, y ​​ya tenemos una buena respuesta autorizada al respecto, pero para fines prácticos, encuentro el consejo del profesor Daniel J. Bernstein, PhD, autor de DJBDNS, bastante entretenido.

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

¿Cuándo se envían las consultas TCP?

Si se encuentra en una de las siguientes situaciones, debe configurar su servidor DNS para responder consultas TCP:

  • Desea publicar conjuntos de registros de más de 512 bytes. (Esto casi siempre es un error).
  • Desea permitir transferencias de zona salientes, por ejemplo a un servidor de terceros.
  • Un servidor principal se niega a delegarle un nombre hasta que configure el servicio TCP.

Si no se encuentra en ninguna de esas situaciones, no es necesario que proporcione el servicio TCP y no debe configurarlo. DNS-over-TCP es mucho más lento que DNS-over-UDP y es inherentemente mucho más vulnerable a los ataques de denegación de servicio. (Esto también se aplica a BIND).

Tenga en cuenta que omite una mención explícita de DNSSEC; la razón es que, según DJB, DNSSEC cae en la categoría de "siempre un error". Consulte https://cr.yp.to/djbdns/forgery.html para obtener más detalles. DJB tiene un estándar alternativo, llamado DNSCurve - http://dnscurve.org/ - que ya ha sido adoptado independientemente por algunos proveedores (como OpenDNS). De interés: /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption .

Tenga en cuenta que si la documentación anterior sobre la configuración de DJBDNS es una indicación de sus características, parece que solo es compatible con AXFR para TCP. Como muchos proveedores todavía usan DJBDNS, es poco probable que admitan DNS sobre TCP sin esfuerzos adicionales.

PD Tenga en cuenta que DJB, de hecho, practica lo que predica. Sus propios servidores, (1), ejecutan DNSCurve, (2), no responden correctamente TCP. Solo el +notcpéxito (que es el predeterminado):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

, mientras +tcpque a fallaría (aparentemente con un mensaje de error diferente, dependiendo de cuál de sus servidores se seleccione):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached
cnst
fuente
2
Tu acto de DJB fanboi se está desgastando bastante. La comunidad DNS ha elegido DNSSEC, y gran parte de la literatura sobre DNSCurve combina completamente los requisitos ortogonales de autenticidad de los datos y el cifrado de los datos . IMNSHO, la mayor parte de su respuesta no contribuye en nada a esta pregunta.
Alnitak
@Alnitak, su insistencia en que se requiere TCP para DNS no hace que sea un requisito real para DNS. Claramente, muchas personas se ejecutan sin TCP y no experimentan NINGÚN problema con la disponibilidad de sus propios sitios web. Sin embargo, continúa promoviendo la información errónea y el FUD.
cnst
2
¿Es ese documento realmente de 2003? ¿Cómo puede afirmar con franqueza que sigue siendo relevante en 2017?
Michael Hampton
1
@MichaelHampton, sí, de todo corazón y absolutamente. Algunas cosas no cambian, y DJB puede ser un imbécil, pero es bastante inteligente. Todos los argumentos que presenta son de naturaleza filosófica y no cambian como lo hace la tecnología. Mientras tanto, (1), por qué es tan difícil de creer, (2), por qué la vinculación a RFC aún más antiguas se realiza con una cara seria, y sin que seas un hipócrita, (3), qué contraargumentos reales tienes aparte de una cita"? La gente sigue diciendo que su camino tiene problemas de interoperabilidad, sin embargo, los mismos argumentos que se proponen (por ejemplo, correo devuelto) lo desacreditó en 2003.
cnst
-5

TCP solo se requiere, y generalmente solo se usa cuando se requiere una respuesta larga. Puede haber impactos negativos. Las transferencias de zona se realizan a través de TCP, ya que son grandes y deben ser confiables. No permitir TCP desde servidores no confiables es una forma de garantizar que solo se den respuestas pequeñas.

Con la introducción de respuestas DNS firmadas, ha habido un requisito para aflojar el límite de 512 bytes a las respuestas UPD. EDNS0 proporciona el mecanismo para respuestas UDP más largas. Si no se permite DNS sobre TCP, es muy probable que se rompa una implementación segura de DNS.

Es perfectamente posible ejecutar un servidor DNS que solo tenga el puerto UDP 53 abierto a Internet. Se requiere acceso TCP a pares DNS, pero esta es una pequeña lista de hosts.

Hay un RFC596 más nuevo que ahora requiere TCP para una implementación completa de DNS. Esto está dirigido a implementadores. Los documentos específicamente no se dirigen a los operadores, pero advierten que no permitir TCP puede dar lugar a una serie de escenarios de falla. Detalla una amplia variedad de fallas que pueden resultar si DNS sobre TCP no es compatible.

Ha habido discusiones sobre el uso de TCP para prevenir ataques de amplificación de DNS. TCP tiene sus propios riesgos de denegación de servicio, pero la distribución es más difícil.

BillThor
fuente
DNSSEC no aflojó el límite, EDNS0 sí, en 1999 (ver RFC 2671).
Alnitak
No, como explicó Alnitak, se requiere TCP en la mayoría de los casos (a menos que pueda estar absolutamente seguro de que nunca tendrá una respuesta> 512 bytes, algo que normalmente no sabe de antemano)
bortzmeyer
Ejecuté DNS con éxito a través de un firewall que solo permite UDP. Salvo configuraciones patológicas, las búsquedas de direcciones tendrán menos de 512 caracteres. He visto referencias de que las rutas DNS están limitadas a 256 caracteres. La evidencia en la base de datos de mi servidor de correo sugiere que las rutas DNS del servidor rara vez superan los 100 caracteres, y los sitios que tienen múltiples nombres devueltos por un registro PTR rara vez tienen más de 256 caracteres. Todas estas respuestas se ejecutarían en UDP. ¿Alguien tiene un caso razonable que se ejecute cerca de 512 caracteres sin DNSSEC o una transferencia de zona.
BillThor
En cuanto a DNSSEC, no verifiqué RFC para tamaños extendidos, pero las únicas referencias que he visto sobre el uso de tamaños de paquetes extendidos en UDP tienen DSNSEC.
BillThor
Uno de los grandes proveedores de contenido se deshizo hace unos años cuando agregaron tantos registros A para uno de sus granjas web que superaba los 512 bytes. Eso causó problemas reales de interoperabilidad.
Alnitak