Відповіді та час очікування сервера DNS

У нас в мережі локальна проблема. Періодично DNS запитує до таймауту наших серверів імен ISP, змушуючи затримати 5 секунд. Навіть якщо я обходжу їх /etc/resolv.confза допомогою прямого копання на одному з наших DNS-серверів, я все-таки стикаюся з проблемою. Ось приклад:

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

В іншому випадку запити відповідають миттєво, як і менше 20 мс. Я простежив пачку і виявив щось цікаве. Сервер DNS - буде відповідати на запити , але клієнт ігнорує початковий відповідь, а потім посилає другий ідентичний запит , який відразу ж відповів на.

Дивіться трасування пакетів . Зверніть увагу на однакові порти джерел у запитах (62076).

Запитання: що спричиняє збій першого запиту DNS?

ОНОВЛЕННЯ

Ресурси:

Слід пакету:

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

Dtruss (страйк для Mac):

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

Брандмауер Mountain Lion випадково затримує запити DNS від apple.stackexchange.com:

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

ОНОВЛЕННЯ 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

Схоже, це помилка в брандмауері Лева. Це ввімкнено у вашій системі?

У цьому потоці MacRumors ( проблеми DNS після оновлення до Mountain Lion (10.8) ) обговорюється можливе вирішення:

Спробуйте зменшити розмір MTU.

Налаштування системи> Мережа> WiFi> Додатково> Обладнання> Вручну> MTU: Користувацькі> 1300

Працювали для мене.

Чи можете ви перевірити, чи зменшує розмір MTU пом'якшення вашої проблеми?

У мене була аналогічна проблема нещодавно і з'ясувалося, що брандмауер Cisco ASA не налаштований на підтримку EDNS0, специфікації, яка дозволяє пакетам DNS UDP розміром більше 512 байт. Як тільки мій адміністратор fw дозволив до 4096 байтів, проблема була вирішена. Чудова інформація тут:

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