Ответы и таймауты 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 (Strace для 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

— dmourati
источник

dtrussвывод выглядит усеченным. Мы никогда не видим системных вызовов, которые записывают вывод программы в STDOUT.

— Андрей B

Вы пробовали другой публичный сервер имен, например, Google DNS.

— vasco.debian

@ vasco.debian да, такое же поведение.

— Дмурати

Единственное различие, которое я вижу между этими двумя парами запрос-ответ, - это задержки между запросом и ответом. Я тоже не вижу проблем в сети. Поэкспериментируйте и проверьте, имеет ли значение задержка - ОС может по какой-то причине сбросить некоторые пакеты udp в приложение, несмотря на то, что это показано в анализаторе. Определенно, это не проблема с сетью или общей конфигурацией, «копать» должно работать. Возможно, что-то не так с настройкой сетевого стека. Проверьте настройки sysctl для сети. Как этот rolande.wordpress.com/2010/12/30/…

— GioMac

Вы не говорите, если у вас работает брандмауэр на Mac?

— JustinP

Ответы:

Похоже, это ошибка в брандмауэре Lion. Это включено в вашей системе?

В этом потоке MacRumors ( проблемы с DNS после обновления до Mountain Lion (10.8) ) обсуждается возможный обходной путь:

Попробуйте уменьшить размер MTU.

Системные настройки> Сеть> Wi-Fi> Дополнительно> Оборудование> Вручную> MTU: Custom> 1300

Работал на меня.

Не могли бы вы проверить, уменьшает ли размер MTU вашу проблему?

— Мэлс
источник

Изменение настроек брандмауэра заставило проблему исчезнуть. MTU не имел никакого эффекта. Брандмауэр должен быть либо отключен, либо «Блокировать все входящие подключения».

— dmourati

Изменение брандмауэра на любую настройку уменьшило частоту проблемы, но не полностью устранило проблему. Возможность воспроизведения 1/200 раз или около того.

— dmourati

Я бы посчитал разумной потерю пакетов такой величины при прохождении через Интернет, особенно если на маршруте есть перегруженные переходы. Помните, DNS использует UDP, который не гарантирует доставку дейтаграмм. Именно поэтому в самом протоколе DNS есть повторы и встроен механизм тайм-аута.

— Мелс

Кстати, я знаю, что мы не должны публиковать здесь комментарии «спасибо», но вы только что повысили мою репутацию в шесть раз :)

— Mels

Недавно у меня была похожая проблема, и я обнаружил, что брандмауэр Cisco ASA не настроен для поддержки EDNS0, спецификации, которая позволяет DNS-пакетам UDP размером более 512 байт. Как только мой администратор FW разрешил до 4096 байт, проблема была решена. Отличная информация здесь:

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

— обкрадывать
источник

Я не думаю, что это применимо здесь. Ответ находится под 512 байтами для этого конкретного запроса DNS, даже с полномочиями и дополнительными разделами.

— Андрей B