У меня есть машина с сервером ubuntu 10.04. У меня начались длительные (5-10 секунд) задержки при подключении к (некоторым) сайтам за пределами локальной сети с помощью таких инструментов, как curl и wget.
С помощью tcpdump и wirehark, я обнаружил, что проблема заключается в поиске DNS, который выполняется для настройки соединения:
ПРИМЕР
Когда я бегу:
wget www.site1.com
Я вижу следующее поведение:
LOOKUP: AAAA www.site1.com
# => fail, no delay, site1 doesn't have an IPv6 AAAA record
LOOKUP: AAAA www.site1.com.mydomain.lan
# => fail, BIG DELAY, crazy domain doesn't exist
LOOKUP: A www.site1.com
# => success, no delay, resolves as expected (site1 has IPv4 A record)
CONNECTION PROCEEDS ...
МОЯ НАСТРОЙКА
Файл resolv.conf моего сервера выглядит так:
nameserver 192.168.0.1 # my router
domain mydomain.lan # made up domain name, for my lan
search mydomain.lan
Файл hosts моего сервера выглядит так:
127.0.0.1 localhost.localdomain localhost
192.168.0.10 server1.mydomain.lan server1
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
РЕЗОЛЮЦИИ?
Почему мой список поиска resolv.conf используется при построении имени для второго поиска, когда справочная страница resolv.conf предполагает, что он используется только при поиске имен хостов (без точек):
«Запросы Resolver, содержащие менее ndots точек (по умолчанию 1), будут выполняться по очереди с использованием каждого компонента пути поиска, пока не будет найдено совпадение».
У меня сложилось впечатление, что второй поиск ошибочен и вообще не должен выполняться ...
Если я удалю domain и search строк из resolv.conf, второй поиск больше не выполняется, и мои задержки исчезают.
(также, если я заставляю wget работать только с IPv4, поиск AAAA не выполняется, поэтому задержки исчезают):
wget --inet4-only www.site1.com
Такое поведение является особенностью.
IPv6 является предпочтительным, поэтому статус ресурса в AAAA сроки определяются в первую очередь. An NXDOMAIN ответ возвращается - поэтому клиент считает, что ему нужно добавить search дорожка.
Обратите внимание, что ndots замечание, которое вы сделали, правильное - но не вся история. Если ndots число выше, чем запрашиваемое имя (в данном случае, если это было имя одной метки), единственное отличие от поведения запроса состоит в том, что запрос с добавленным суффиксом будет выполняться перед необработанное имя. Поскольку вы прошли ndots порог, имя проверяется первым, как указано. См. Ниже на странице руководства:
По умолчанию для n установлено значение 1, что означает, что если в имени есть какие-либо точки, имя будет сначала проверено как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.
Этот запрос не удался, поэтому необходимо использовать список поиска. Обратите внимание на разницу в поведении запроса с wget http://site1/.
То, что вы видите, является предполагаемым поведением - я думаю, вам нужно исправить стечение факторов, вызывающих этот медленный поиск.
NXDOMAIN он исходит из корней, когда пытается найти несуществующий TLD. Поскольку отключение IPv6 исправляет это, у вас может быть DNS-сервер на пути, который с треском терпит неудачу при кэшировании, когда AAAA поиск задействован. Попробуйте изменить свой резолвер на 8.8.8.8 проверять.search значение, которое можно использовать, поскольку это недопустимое имя в публичной иерархии), он немедленно ответит. Вам это, наверное, не нужно search конфигурации, но установите для него то, что разрешится, чтобы он не пытался угадать его по имени хоста машины. search com должно хорошо работать.Если в приглашении оболочки вы скажете $ hostname и вернуться foo.bar.baz, то преобразователь DNS понимает, что ваше имя хоста foo и ваше доменное имя bar.baz. Обычно строки «домен» и «поиск» в /etc/resolv.conf используются только в том случае, если это не истина (или если вы собираетесь спровоцировать необычное поведение).
Если ваше доменное имя действительно bar.baz, то, скорее всего, вам следует не укажите либо «домен», либо «поиск» в /etc/resolv.conf. В отличие от того, что часто бывает в других местах, в /etc/resolv.conf "чопорный" переопределение информации, которая уже доступна из hostname обычно вызывает причудливое и нежелательное поведение (включая глупые длительные таймауты). Это верно как для больших коммерческих, так и для небольших домашних сред.
(Предостережение: каждая прикладная программа потенциально может интерпретировать /etc/resolv.conf немного по-разному, поэтому теоретически это может быть не всегда верно. В большинстве современных систем, хотя 99% запросов резолвера проходят через GLIBC, поэтому на практике выше почти всегда верно.)