Ответы и таймауты 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

domain-name-system mac-osx timeout dig 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