По какой-то причине две из моих машин начали страдать от чрезвычайно медленного поиска DNS.
Пример синхронизированного вывода команды 'host':
[root@ns507403 ~]# time host www.google.com
www.google.com has address 172.217.5.4
www.google.com has IPv6 address 2607:f8b0:4006:80d::2004
real 0m3.050s
user 0m0.000s
sys 0m0.004s
Поиск занимает не менее 3 секунд независимо от того, какой адрес используется или сколько раз выполняется поиск. Наибольшее время, которое я видел, составляло 9 секунд для поиска www.paypal.com.
Я исключил возможность медленного DNS-сервера, потому что я использую один и тот же DNS-преобразователь на 4 других серверах, расположенных в одном центре обработки данных, и все они работают нормально. (<1 мс поиска)
То, что я уже безуспешно пробовал:
options single-request в /etc/resolv.confoptions single-request-reopen в /etc/resolv.confsysctl -w net.ipv6.conf.all.disable_ipv6=1Это мой текущий файл /etc/resolv.conf:
nameserver 127.0.0.1
nameserver 213.186.33.99
search ovh.net
В dig Кажется, команда работает нормально, показывая время запроса 0 мс.
Есть идеи, что может быть причиной этого? Я использую CentOS 6 на обеих машинах.
127.0.0.1 это ваш интерфейс обратной связи localhost, то есть вы достигаете своего собственного сервера. По разным причинам ваш сервер сначала использует его для поиска DNS, и, поскольку ваш сервер не знает, как ответить на DNS-запрос, вам нужно подождать, пока истечет время ожидания запроса и перейдет на второй сервер имен.
Просто используйте реальный DNS-сервер в качестве единственной записи:
nameserver 213.186.33.99
Почему у вас вообще 127.0.0.1 в качестве сервера имен?
Скорее всего, вы указали 127.0.0.1 (localhost), потому что в вашем дистрибутиве используется демон службы кэширования имен. Думайте об этом как о кеширующем DNS-сервере, который работает на вашем собственном компьютере. Эффективность использования такого демона спорна.
У него есть некоторые преимущества в ускорении некоторых типов использования Интернета за счет сокращения количества DNS-запросов, отправляемых в Интернет. Тем не менее, я видел, как они ломались и сгорали сами по себе, что приводило к ошибкам "медленная сеть", которые очень нравятся многим из нас.
Если я правильно помню, CentOS использует nscd (демон кэширования служб имен) для выполнения этой функции. Быстрый sudo service nscd restart должен это исправить.
Или вы можете сделать то, что вы сделали, и, так сказать, исключить посредника. Если это так, и вы не хотите запускать демон кеширования, вы должны отключить его с помощью:
sudo service nscd stop
sudo chkconfig nscd off
Поменяйте порядок серверов имен в обратном порядке, и это ускорится.
nameserver 213.186.33.99
nameserver 127.0.0.1
В моем случае я использовал DNS Google вместо своих маршрутизаторов (шлюз)
Я заменил 192.168.1.1 и добавил:
nameserver 8.8.8.8
nameserver 8.8.4.4
Оказывается, это все-таки проблема с брандмауэром ... У OVH есть действительно ошибочный сетевой брандмауэр, который вызывал проблемы. Сотрудники OVH сказали мне, что мой брандмауэр настроен на 100% нормально, потому что в противном случае было бы невозможно разрешить использование 213.186.33.99. Это было неверно, брандмауэр игнорируется для этого конкретного IP-адреса, потому что он, по-видимому, размещен внутри сети OVH.
Весь наш офис недавно испытал симптомы, точно такие же, как описано в OP, что указывает на проблему с устройством маршрутизатора (Fortigate).
Проблема оказалась в выборе серверов имён в конфиге роутера. Наши старые настройки указывали на надежные серверы Level3 на 4.2.2.1 и 4.2.2.2. По неизвестным причинам эти серверы работали очень плохо.
Мы перешли на 1.1.1.1 (CloudFlare) и 8.8.8.8 (Google) и проблема мгновенно решена, а общая скорость просмотра резко увеличилась.
Эта конфигурация работает для меня:
nameserver 213.186.33.99
nameserver 127.0.0.1
nameserver 208.67.222.222
search ovh.net