Réponses et délais d'expiration du serveur DNS

17

Nous rencontrons un problème frustrant sur notre réseau local. Périodiquement, les requêtes DNS adressées à nos serveurs de noms ISP expirent, forçant un délai de 5 secondes. Même si je dérivation /etc/resolv.confen utilisant une fouille directe à l' un de nos serveurs DNS, je rencontre toujours le problème. Voici un exemple:

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

D'autres fois, les requêtes répondent instantanément, comme en moins de 20 ms. J'ai fait une trace de paquet et découvert quelque chose d'intéressant. Le serveur DNS est répond , mais le client ignore la réponse initiale, puis envoie une deuxième requête identique qui a répondu immédiatement à.

Voir trace de paquet . Notez les ports source identiques aux requêtes (62076).

Question: qu'est-ce qui provoque l'échec de la première requête DNS?

MISE À JOUR

Ressources:

Trace de paquets:

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

Dtruss (strace pour mac):

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

Le pare-feu Mountain Lion retarde de manière aléatoire les demandes DNS de apple.stackexchange.com:

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

MISE À JOUR 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
domain-name-system mac-osx timeout dig dmourati
la source
dtrussla sortie semble tronquée. Nous ne voyons jamais les appels système qui écrivent la sortie du programme dans STDOUT.
Andrew B
Avez-vous essayé un autre serveur de noms publics, par exemple Google DNS.
vasco.debian
@ vasco.debian oui, même comportement.
dmourati
1
La seule différence que je vois entre ces deux paires demande-réponse est le retard entre la demande et la réponse. Je ne vois pas non plus de problèmes sur le réseau. Expérimentez et vérifiez si le retard est important - le système d'exploitation peut abandonner certains packages udp à l'application pour une raison quelconque, bien qu'il soit affiché dans l'analyseur. Certainement, ce n'est pas un problème de réseau ou de configuration générale, "creuser" doit fonctionner. Peut-être que quelque chose ne va pas avec le réglage de la pile réseau. Vérifiez les paramètres sysctl pour le réseau. Comme ça rolande.wordpress.com/2010/12/30/…
GioMac
1
Vous ne dites pas si vous avez un pare-feu en cours d'exécution sur le mac?
JustinP

Réponses:

3

Cela semble être un bug dans le pare-feu de Lion. Est-il activé sur votre système?

Dans ce thread MacRumors ( problèmes DNS après la mise à jour vers Mountain Lion (10.8) ), une solution de contournement possible est discutée:

Essayez de réduire la taille du MTU.

Préférences Système> Réseau> WiFi> Avancé> Matériel> Manuellement> MTU: Personnalisé> 1300

A travaillé pour moi.

Pourriez-vous vérifier si la réduction de la taille MTU atténue votre problème?

Mels
la source
La modification des paramètres du pare-feu a fait disparaître le problème. Le MTU n'a eu aucun effet. Le pare-feu doit être désactivé ou "Bloquer toutes les connexions entrantes".
dmourati
La modification du pare-feu sur l'un ou l'autre paramètre a réduit la fréquence des problèmes mais n'a pas complètement éliminé le problème. Capable de reproduire environ 1/200 fois.
dmourati
Je considérerais une perte de paquets de cette ampleur tout à fait raisonnable lors de la navigation sur Internet, surtout s'il y a des sauts congestionnés sur la route. N'oubliez pas que DNS utilise UDP, ce qui ne garantit pas la livraison du datagramme. C'est exactement pourquoi le protocole DNS lui-même a des tentatives et un mécanisme de temporisation intégré.
Mels
1
Soit dit en passant, je sais que nous ne sommes pas censés publier des commentaires de "merci" ici, mais vous venez de multiplier par six ma réputation :)
Mels
0

J'ai eu un problème similaire récemment et j'ai découvert que le pare-feu Cisco ASA n'était pas configuré pour prendre en charge EDNS0, la spécification qui autorise les paquets DNS UDP supérieurs à 512 octets. Une fois que mon administrateur fw a autorisé jusqu'à 4096 octets, le problème a été résolu. Grande info ici:

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

Rob
la source
Je ne pense pas que cela s'applique ici. La réponse est bien inférieure à 512 octets pour cette requête DNS particulière, même avec l'autorité et les sections supplémentaires.
Andrew B