Servidor DNS respuestas y tiempos de espera

Estamos experimentando un problema frustrante en nuestra LAN. Periódicamente, las consultas de DNS a nuestros servidores de nombres de ISP exceden el tiempo de espera, lo que genera un retraso de 5 segundos. Incluso si omito el /etc/resolv.confuso de una excavación directa en uno de nuestros servidores DNS, todavía encuentro el problema. Aquí hay un ejemplo:

mv-m-dmouratis:~ dmourati$ time dig www.google.com @209.81.9.1 

; <<>> DiG 9.8.3-P1 <<>> www.google.com @209.81.9.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14473
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.com.            IN  A

;; ANSWER SECTION:
www.google.com.     174 IN  A   74.125.239.148
www.google.com.     174 IN  A   74.125.239.147
www.google.com.     174 IN  A   74.125.239.146
www.google.com.     174 IN  A   74.125.239.144
www.google.com.     174 IN  A   74.125.239.145

;; AUTHORITY SECTION:
google.com.     34512   IN  NS  ns2.google.com.
google.com.     34512   IN  NS  ns1.google.com.
google.com.     34512   IN  NS  ns3.google.com.
google.com.     34512   IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     212097  IN  A   216.239.34.10
ns3.google.com.     207312  IN  A   216.239.36.10
ns4.google.com.     212097  IN  A   216.239.38.10
ns1.google.com.     212096  IN  A   216.239.32.10

;; Query time: 8 msec
;; SERVER: 209.81.9.1#53(209.81.9.1)
;; WHEN: Fri Jul 26 14:44:25 2013
;; MSG SIZE  rcvd: 248


real    0m5.015s
user    0m0.004s
sys 0m0.002s

Otras veces, las consultas responden instantáneamente, como en menos de 20 ms o menos. Hice un rastreo de paquetes y descubrí algo interesante. El servidor DNS está respondiendo, pero el cliente ignora la respuesta inicial, a continuación, envía una segunda consulta idéntica que se respondió de inmediato a.

Ver rastreo de paquetes . Tenga en cuenta los puertos de origen idénticos a las consultas (62076).

Pregunta: ¿qué está causando que falle la primera consulta DNS?

ACTUALIZAR

Recursos:

Rastreo de paquetes:

http://www.cloudshark.org/captures/8b1c32d9d015

Dtruss (strace para mac):

https://gist.github.com/dmourati/6115180

El firewall de Mountain Lion está retrasando aleatoriamente las solicitudes de DNS de apple.stackexchange.com:

/apple/80678/mountain-lion-firewall-is-randomly-delaying-dns-requests

ACTUALIZACIÓN 2

System Software Overview:

  System Version:   OS X 10.8.4 (12E55)
  Kernel Version:   Darwin 12.4.0
  Boot Volume:  Macintosh HD
  Boot Mode:    Normal
  Computer Name:    mv-m-dmouratis
  User Name:    Demetri Mouratis (dmourati)
  Secure Virtual Memory:    Enabled
  Time since boot:  43 minutes

Hardware Overview:

  Model Name:   MacBook Pro
  Model Identifier: MacBookPro10,1
  Processor Name:   Intel Core i7
  Processor Speed:  2.7 GHz
  Number of Processors: 1
  Total Number of Cores:    4
  L2 Cache (per Core):  256 KB
  L3 Cache: 6 MB
  Memory:   16 GB

Firewall Settings:

  Mode: Limit incoming connections to specific services and applications
  Services:
  Apple Remote Desktop: Allow all connections
  Screen Sharing:   Allow all connections
  Applications:
  com.apple.java.VisualVM.launcher: Block all connections
  com.getdropbox.dropbox:   Allow all connections
  com.jetbrains.intellij.ce:    Allow all connections
  com.skype.skype:  Allow all connections
  com.yourcompany.Bitcoin-Qt:   Allow all connections
  org.m0k.transmission: Allow all connections
  org.python.python:    Allow all connections
  Firewall Logging: Yes
  Stealth Mode: No

— dmourati
fuente

dtrussLa salida parece truncada. Nunca vemos las llamadas al sistema que escriben la salida del programa en STDOUT.

— Andrew B

¿Has probado otro servidor de nombres públicos, por ejemplo, Google DNS?

— vasco.debian

@ vasco.debian sí, el mismo comportamiento.

— dmourati

La única diferencia que veo entre estos dos pares de solicitud-respuesta son los retrasos entre la solicitud y la respuesta. No veo ningún problema en la red también. Experimente y verifique si la demora es importante: el sistema operativo puede dejar caer algunos paquetes udp a la aplicación por alguna razón, a pesar de que se muestra en el analizador. Definitivamente, no es un problema con la red o la configuración general, "cavar" debe funcionar. Tal vez algo está mal con el ajuste de la pila de red. Verifique la configuración de sysctl para la red. Me gusta esto rolande.wordpress.com/2010/12/30/…

— GioMac

¿No dices si tienes un firewall ejecutándose en la Mac?

— JustinP

Esto parece ser un error en el firewall de Lion. ¿Está habilitado en su sistema?

En este hilo de MacRumors ( problemas de DNS después de actualizar a Mountain Lion (10.8) ), se discute una posible solución alternativa:

Intenta reducir el tamaño de MTU.

Preferencias del sistema> Red> WiFi> Avanzado> Hardware> Manualmente> MTU: Personalizado> 1300

Trabajó para mi.

¿Podría verificar si reducir el tamaño de MTU mitiga su problema?

— Mels
fuente

Cambiar la configuración del firewall hizo que el problema desapareciera. El MTU no tuvo efecto. El firewall debe estar desactivado o "Bloquear todas las conexiones entrantes".

— dmourati

Cambiar el firewall a cualquiera de las configuraciones disminuyó la frecuencia del problema, pero no eliminó por completo el problema. Capaz de repro 1/200 veces más o menos.

— dmourati

Consideraría una pérdida de paquetes de esa magnitud bastante razonable al atravesar Internet, especialmente si hay saltos congestionados en la ruta. Recuerde, DNS usa UDP, que no garantiza la entrega de datagramas. Que es exactamente por qué el protocolo DNS en sí tiene reintentos y un mecanismo de tiempo de espera incorporadas.

— Mels

Por cierto, sé que se supone que no debemos publicar comentarios de "gracias" aquí, pero acabas de aumentar mi reputación seis veces :)

— Mels

Recientemente tuve un problema similar y descubrí que el firewall Cisco ASA no estaba configurado para admitir EDNS0, la especificación que permite paquetes DNS UDP mayores de 512 bytes. Una vez que mi administrador fw permitió hasta 4096 bytes, el problema se resolvió. Gran información aquí:

http://www.petenetlive.com/KB/Article/0000312.htm

— Robar
fuente

No creo que eso se aplique aquí. La respuesta está muy por debajo de 512 bytes para esta consulta DNS particular, incluso con la autoridad y secciones adicionales.

— Andrew B