Risposte e timeout del server DNS

Stiamo riscontrando un problema frustrante sulla nostra LAN. Periodicamente, le query DNS ai timeout dei nostri server dei nomi ISP impongono un ritardo di 5 secondi. Anche se ignoro /etc/resolv.confutilizzando uno scavo diretto su uno dei nostri server DNS, riscontro ancora il problema. Ecco un esempio:

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

Altre volte, le query rispondono istantaneamente, come in meno di 20 ms circa. Ho fatto una traccia dei pacchetti e ho scoperto qualcosa di interessante. Il server DNS si risponde ma il client ignora la risposta iniziale, quindi invia una seconda query identica che viene immediatamente reagito.

Vedi la traccia del pacchetto . Nota le porte di origine identiche alle query (62076).

Domanda: cosa sta causando il fallimento della prima query DNS?

AGGIORNARE

risorse:

Traccia pacchetto:

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

Dtruss (strace per mac):

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

Il firewall Mountain Lion sta ritardando casualmente le richieste DNS da apple.stackexchange.com:

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

AGGIORNAMENTO 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
fonte

dtrussl'output sembra troncato. Non vediamo mai le chiamate di sistema che scrivono l'output del programma su STDOUT.

— Andrew B,

Hai provato altri server di nomi pubblici, ad esempio Google DNS.

— vasco.debian

@ vasco.debian sì, stesso comportamento.

— dmourati,

L'unica differenza che vedo tra queste due coppie richiesta-risposta sono i ritardi tra richiesta e risposta. Non vedo alcun problema anche sulla rete. Sperimenta e controlla se il ritardo è importante: il sistema operativo potrebbe rilasciare alcuni pacchetti udp nell'applicazione per qualche motivo, nonostante sia mostrato nell'analizzatore. Sicuramente, non è un problema con la rete o la configurazione generale, "scavare" deve funzionare. Forse qualcosa non va nell'ottimizzazione dello stack di rete. Controlla le impostazioni sysctl per la rete. In questo modo rolande.wordpress.com/2010/12/30/…

— GioMac

Non dici se hai un firewall in esecuzione sul Mac?

— Giustino

Questo sembra essere un bug nel firewall di Lion. È abilitato sul tuo sistema?

In questo thread MacRumors ( problemi DNS dopo l'aggiornamento a Mountain Lion (10.8) ), viene discussa una possibile soluzione alternativa:

Prova a ridurre le dimensioni dell'MTU.

Preferenze di Sistema> Rete> WiFi> Avanzate> Hardware> Manualmente> MTU: Personalizzato> 1300

Ha funzionato per me.

Potresti verificare se la riduzione della dimensione MTU mitiga il tuo problema?

— Mels
fonte

La modifica delle impostazioni del firewall ha risolto il problema. L'MTU non ha avuto alcun effetto. Il firewall deve essere disabilitato o "Blocca tutte le connessioni in entrata".

— dmourati,

La modifica del firewall in entrambe le impostazioni ha ridotto la frequenza del problema ma non ha eliminato del tutto il problema. In grado di ripetere circa 1/200 volte.

— dmourati,

Considererei una perdita di pacchetti di tale portata abbastanza ragionevole quando si attraversa Internet, specialmente se ci sono salti congestionati sulla rotta. Ricorda, DNS utilizza UDP, che non garantisce la consegna dei datagrammi. Questo è esattamente il motivo per cui il protocollo DNS stesso ha nuovi tentativi e un meccanismo di timeout integrato.

— Mels

A proposito, so che non dovremmo pubblicare commenti "grazie" qui, ma hai appena aumentato di sei volte la mia reputazione :)

— Mels

Di recente ho riscontrato un problema simile e ho scoperto che il firewall Cisco ASA non era configurato per supportare EDNS0, la specifica che consente pacchetti UDP DNS di dimensioni superiori a 512 byte. Una volta che il mio amministratore fw ha consentito fino a 4096 byte il problema è stato risolto. Grandi informazioni qui:

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

— rapinare
fonte

Non penso che si applichi qui. La risposta è ben al di sotto di 512 byte per questa particolare query DNS, anche con l'autorità e sezioni aggiuntive.

— Andrew B,