Назад | Перейти на главную страницу

Задержка, связанная с запросом AAAA

У меня есть автономная изолированная сеть, работающая под управлением смешанных систем Windows и Linux, с сервером Windows 2008 R2, выполняющим обязанности AD и DNS.

Я наблюдаю 5-секундные задержки с использованием getaddrinfo в системах Linux.

В Wireshark я вижу (C-> S означает клиент для DNS-сервера):

t=0.000   C->S Query A     foo.example.com    ID=0x1111
t=0.000   C->S Query AAAA  foo.example.com    ID=0x2222
t=0.004   S->C Response to 0x2222, No error
          (Query is echoed)
          Authoritative nameservers:
             example.com: type SOA, class IN, mname svr01.example.com
               Name: example.com
               Type: SOA
               Class: IN
               TTL: 1 hour
               Primary name server: svr01.example.com
               Refresh interval: 15 minutes
               Retry interval: 10 minutes
               Expiration limit: 1 day
               Minimum TTL: 1 hour

[5 second delay]

t=5.004   C->S Query A     foo.example.com    ID=0x1111
t=5.005   S->C Query response A  192.168.1.17'

Если я сделаю тот же запрос снова, вскоре после этого, я не увижу задержки, как и ожидалось:

t=0.000   C->S Query A     foo.example.com    ID=0x3333
t=0.000   C->S Query AAAA  foo.example.com    ID=0x4444
t=0.001   S->C Query response A  192.168.1.17'

Я могу продолжать получать немедленные ответы в течение некоторого периода времени. Через некоторое время (еще экспериментирую) задержка вернется.

Что здесь происходит? Если я использую gethostbyname() (что делает только IPv4) или nslookup foo.example.com, задержки нет.

Дополнительная информация:

Обновить:

Этот ответ на Ask Ubuntu предложил добавить 

options single-request

к /etc/resolv.conf. Похоже, это решило проблему для меня.

Однако мне все еще любопытно:

Ваш DNS-сервер кажется неисправным. На DNS-сервер отправляются два запроса, но он отправляет только один ответ. Клиент делает то, что должны делать клиенты в этом случае, он ждет некоторое время, а затем повторно передает запрос.

Первоначальная задержка в 5 секунд может быть разумной для неинтерактивного использования. Но для интерактивного использования я считаю, что это слишком много.

Правильным исправлением было бы обновить DNS-сервер до версии без ошибки или связаться с поставщиком, если исправление еще не выпущено. Все остальное - обходной путь.

С помощью man resolv.conf в системе Ubuntu объяснит, что single-request и single-request-reopen варианты делаем. Это два разных варианта обхода известной ошибки в определенных DNS-серверах. Недостатком этих опций является то, что они замедляют разрешение имен примерно в два раза. Однако, учитывая, что ошибка, похоже, замедляет разрешение имен примерно в 1000 раз, вам все же может быть лучше использовать обходной путь.

При запросе несуществующей записи вы можете вместо этого получить ответ с записью SOA. Причина отправки не только кода ошибки, но и записи SOA заключается в том, что запись SOA содержит информацию, которая позволит кэшировать отрицательный результат.

Правильный способ интерпретации захвата вашего пакета состоит в том, что вы видите отброшенные пакеты ответа для обе то A и AAAA записывать ответы.

В SOA запись, кажется, сбивает вас с толку и заслуживает уточнения:

  • В SOA запись фактически находится в разделе полномочий, а не в разделе ответов.
  • NXDOMAIN означает «нет записей с таким именем». Если есть Другой записи с тем же именем, но разных типов, вы увидите ответ NOERROR с нулевыми записями в разделе ответов.
  • Вы видите NOERROR ответ с нулевыми ответами и раздел авторитетных данных, сообщающий вам, из какой зоны пришел этот ответ. Вы можете игнорировать SOA компонент целиком. Этот ответ говорит вам, что нет AAAA запись.

Теперь, когда мы установили, что AAAA ответ - это правильно отформатированный пакет и то, что вы должен Если вы видите в этом сценарии, он полностью меняет контекст того, на что вы смотрите. Вы видите случаи, когда A записи ответов теряются, в дополнении к AAAA ответы теряются. Ваше исследование показывает, что AAAA ответы теряются чаще, но не исключительно.

Основываясь на предоставленной информации, мы не сможем объяснить, что здесь происходит. Вам необходимо настроить захват пакетов на самих DNS-серверах и определить следующие факторы:

  1. Действительно ли запросы, связанные с отсутствующими ответами, поступают на DNS-сервер?
  2. Если запросы поступают на DNS-сервер, действительно ли отправляются ответы?
  3. Если сервер не отправляет ответы, ваш DNS-сервер должен получать эту информацию от другого DNS-сервера, который долго отвечает? (время ожидания истекает при первой попытке, но запрос находится в кеше для второй попытки) Вы видите достаточно большую нагрузку запроса для переполнить вашу очередь сокетов?
  4. Если сервер является отправляя ответы, какие устройства между сервером и клиентом могут терять пакеты? Есть ли у одного из ваших DNS-серверов проблемы с маршрутизацией по сравнению с другими? Кажется, что пакеты теряются со всех DNS-серверов, что свидетельствует о сетевой проблеме где-то между клиентом и сервером?

Как видите, здесь может происходить много всего. Вам нужно будет сузить круг вопросов, чтобы исключить возможные варианты. Я прошу прощения за то, что этот ответ не был окончательным, но это было намного больше, чем можно было бы описать в нескольких комментариях. Не стесняйтесь обновлять свой вопрос.