Forzar solicitudes DNS del reenviador al modo TCP

He configurado un servidor DNS en SLES10 (actualmente bind 9.6) en un servidor multi-homed. Este servidor se puede consultar desde todas las redes internas y ofrece respuestas para todas las redes internas. Tenemos dos zonas DNS "maestras" separadas. Cada una de estas zonas está siendo servida por varios servidores autorizados de DNS de Windows.

Ahora mi servidor Linux es un servidor DNS secundario para una de estas zonas (zona interna privada) y actúa como reenviador para la otra zona (zona interna pública).

Hasta hace poco, esta configuración funcionaba sin problemas. Ahora recibo, al consultar la zona interna pública (por ejemplo, mediante el hostcomando en un cliente de Linux), el mensaje de error

;; Truncado, reintentando en modo TCP

un vaciado de wirehark reveló la causa de esto: la primera consulta sale en modo UDP, la respuesta no encaja en UDP (debido a la larga lista de NS autoritativo), luego se vuelve a intentar en modo TCP, entregando la respuesta correcta.

Ahora la pregunta: ¿puedo configurar mi enlace para consultar los reenviadores en modo TCP sin intentar UDP primero?

Actualización: Probar mi mano en ASCII-art ...

+--------------+   +--------------+   +-----------------+
| W2K8R2 DNS   |   | SLES 10 DNS  |   | W2K8R2 DNS      |
| Zone private +---+ All internal +---+ Zone public     |
| internal 2x  |   |   Zones      |   | internal 30+ x  |
+--------------+   +-+----------+-+   +-----------------+
                     |          |
                  +--+---+   +--+---+
                  |Client|   |Client|
                  +------+   +------+

— Nils
fuente

un pequeño diagrama de esto sería útil: estoy luchando por averiguar qué servidor es cuál de su descripción.

— Alnitak

algo mejor, aunque todavía no está claro exactamente qué hosts está ejecutando este hostcomando y qué consulta se está enviando.

— Alnitak

Los clientes solicitan a través de SLES10 las entradas de la zona pública interna. La zona privada interna no sufre, ya que solo hay 2 entradas NS allí.

— Nils

y los clientes son simples solucionadores de stub?

— Alnitak

le sugerimos que agregue minimal-responses: yesa la configuración BIND en SLES 10, ya que puede reducir los tamaños de respuesta. En cualquier caso, la mayoría de las consultas normales no excederán el límite de 512 bytes.

— Alnitak

Respuestas:

Primero, no llamaría a eso un error, solo un mensaje informativo.

En segundo lugar, los servidores DNS siempre responderán consultas UDP (al menos BIND, no puedo encontrar opciones para deshabilitar UDP) y los clientes siempre (?) Intentarán enviar una consulta UDP primero (por ejemplo, no hay opciones en resolv.conf para cambiar eso ni en la JVM) - si encajan en un paquete UDP (las solicitudes generalmente lo hacen)

Si tiene un caso de uso específico, puede especificar el uso de TCP, por ejemplo, en el script de shell use 'dig + tcp' o 'host -T' para la resolución, y puede usar las llamadas del sistema 'sethostent / gethostbyname / endhostent' (vea man página) para forzar TCP en otros casos.

Si realmente quiere intentar bloquear UDP, la única opción que puedo ver es con una regla iptable, pero no estoy seguro de que esa configuración funcione. Espero que la resolución de DNS simplemente falle.

— Dan Andreatta
fuente

Existe un beneficio de rendimiento nominal al saber a priori que la consulta UDP fallará e intentar primero con TCP. Ver RFC 5966 para una discusión de eso.

— Alnitak

@Alnitak y me gustaría obtener ese beneficio.

— Nils

@Nils, así que tenemos que descubrir por qué EDNS aparentemente no funciona ...

— Alnitak

No tengo un caso de uso especial (los clientes usarán su biblioteca de resolución), pero cada solicitud y cada respuesta pasarán por la red dos veces, eso no me gusta.

— Nils

@Nils, el problema es que el cliente decide UDP / TCP, pero el servidor conoce el tamaño de la respuesta.

— Dan Andreatta

Su servidor BIND debe estar utilizando EDNS (consulte RFC 2671) para permitir paquetes UDP de más de 512 bytes.

options {
    edns-udp-size 4096;
    max-udp-size 4096;
};

Esto debería permitir que su gran conjunto NS se recupere a través de UDP, sin requerir la sobrecarga de una conexión TCP para otras consultas más pequeñas.

Sin embargo, tenga en cuenta que estos son en realidad los valores predeterminados. Si no se usa EDNS, algo lo está bloqueando o los servidores que reciben las opciones de EDNS no lo admiten.

Además, tenga en cuenta que hostno es compatible con EDNS. Es perfectamente posible que su reenviador -> las consultas del servidor ya estén utilizando EDNS, y simplemente no puede verlo cuando intenta con su cliente local.

Prueba en dig +bufsize=4096 @server hostname Alugar de usar host.

— Alnitak
fuente

¿Quién debería estar usando esto? ¿Probablemente tanto mi servidor como mis reenviadores de la zona "público interno"?

— Nils

¿Cuál es el sentido de enviar la lista completa de NS en la respuesta de todos modos?

— Nils

@Nils el protocolo DNS requiere que el conjunto completo de entradas que coincidan con la misma tupla (QNAME, QTYPE y QCLASS) sean indivisibles (también conocido como "RRset")

— Alnitak

¿me puede indicar el RFC con respecto a este RRset?

— Nils

Actaully host utiliza la biblioteca de resolución estándar, y en mi estación de trabajo es compatible con EDNS0. Para probar si las solicitudes especifican EDNS0, ejecute 'tcpdump -x port 53' y el volcado hexadecimal debe contener (hacia el final, en la sección adicional) la secuencia 0029 1000 0000 8000 0000, que es la representación binaria del OPT RR.

— Dan Andreatta