Случайные сбои при разрешении DNS, не знаю, что делать дальше. (20.04.02)

Последние 3 месяца я боролся со случайной проблемой на моем домашнем сервере, когда разрешение DNS снижалось на короткий период времени (10-60 секунд) без всякой причины. Пинг через имя хоста приводит к ping: signal.org: временный сбой в разрешении имен , и любые службы, которые пытаются выполнить поиск в DNS, почти мгновенно терпят неудачу. Нет журналов systemd-resolved или dnsmasq в / var / log / syslog , когда происходят эти отключения, но другие службы сообщают о проблемах. Например:

ddclient [573749]: сообщение повторяется 14 раз: [ПРЕДУПРЕЖДЕНИЕ: невозможно подключиться к checkip.dyndns.org:80 сокет: IO :: Socket :: INET: неправильное имя хоста 'checkip.dyndns.org']

dockerd [1811]: time = "2021-04-29T13: 50: 19.080258289-05: 00" level = info msg = "В resolv.conf не осталось серверов имен DNS, отличных от localhost. Использование внешних серверов по умолчанию: [nameserver 8.8.8.8 nameserver 8.8.4.4] "

rsyslogd: Ошибка DNS: не удается разрешить" "[v8.2001.0]

whoopsie [1816]: [17:38:15] Отправлено; сервер ответил: Не удалось разрешить имя хоста

Текущая настройка: Ubuntu 20.04.2, Netplan установлен на статический IP, dnsmasq - это DNS-сервер с dns -forward-max = 1024 , systemd-resolved отключен и остановлен.Сервер - Ryzen 3950X, ОЗУ 64 ГБ, ОС установлена ​​на накопитель NVMe. На сервере работает множество сервисов типа веб-приложений, но для DNS-запросов проще всего матрица-синапс .

Вещи, которые я пробовал:

· Я перезапускал службу systemd-resolved сотни раз, отключал службу десятки раз, выключал и снова включал резолвер-заглушку, а также удалял и повторно выполнял создал символическую ссылку.

· Я установил статический IP с помощью netplan и играл с /etc/NetworkManager/NetworkManager.conf.

· Я установил pihole и несвязанный через apt только для самого сервера. ( pihole в настоящее время удален, а unbound работает, но ничего не использует для разрешения.

· Я установил dnsmasq и полностью отключил systemd -разрешено .

· Я полностью отключил IPv6 на сервере.

· Я установил * soft nofile 1048576 и * hard nofile 1048576 в /etc/security/limits.conf и / proc / sys / fs / file-max показывает 9223372036854775807 .

Я подозреваю, что проблема в Docker, но понятия не имею как это проверить. В настоящее время у меня работает 38 контейнеров Docker, и когда я запускаю sudo lsof -i: 53 , когда возникает проблема, я увижу:

thomcat@servername:~$ sudo lsof -i :53
COMMAND      PID            USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
dockerd     1623            root  217u  IPv4 1577888      0t0  UDP localhost:46003->localhost:domain 
dockerd     1623            root  226u  IPv4 1605902      0t0  UDP localhost:50192->localhost:domain 
dockerd     1623            root  227u  IPv4 1610070      0t0  UDP localhost:52637->localhost:domain 
dockerd     1623            root  228u  IPv4 1605907      0t0  UDP localhost:55021->localhost:domain 
dockerd     1623            root  229u  IPv4 1618981      0t0  UDP localhost:57618->localhost:domain 
dockerd     1623            root  230u  IPv4 1610081      0t0  UDP localhost:35776->localhost:domain 
dockerd     1623            root  231u  IPv4 1610086      0t0  UDP localhost:60635->localhost:domain 
dockerd     1623            root  232u  IPv4 1589998      0t0  UDP localhost:43036->localhost:domain 
dockerd     1623            root  234u  IPv4 1602056      0t0  UDP localhost:58408->localhost:domain 
dockerd     1623            root  235u  IPv4 1614011      0t0  UDP localhost:43421->localhost:domain 
dockerd     1623            root  236u  IPv4 1589999      0t0  UDP localhost:60957->localhost:domain 
dockerd     1623            root  237u  IPv4 1597695      0t0  UDP localhost:53026->localhost:domain 
dockerd     1623            root  242u  IPv4 1590000      0t0  UDP localhost:41842->localhost:domain 
dockerd     1623            root  244u  IPv4 1597696      0t0  UDP localhost:49179->localhost:domain 
dockerd     1623            root  246u  IPv4 1572736      0t0  UDP localhost:46471->localhost:domain 
dockerd     1623            root  266u  IPv4 1616008      0t0  UDP localhost:35262->localhost:domain 
dockerd     1623            root  267u  IPv4 1616009      0t0  UDP localhost:54501->localhost:domain 
dockerd     1623            root  268u  IPv4 1579887      0t0  UDP localhost:33130->localhost:domain 
dockerd     1623            root  269u  IPv4 1579888      0t0  UDP localhost:33491->localhost:domain 
dockerd     1623            root  270u  IPv4 1613280      0t0  UDP localhost:49504->localhost:domain 
dockerd     1623            root  273u  IPv4 1579890      0t0  UDP localhost:43801->localhost:domain 
dockerd     1623            root  278u  IPv4 1613283      0t0  UDP localhost:44804->localhost:domain 
dockerd     1623            root  279u  IPv4 1568692      0t0  UDP localhost:39425->localhost:domain 
dockerd     1623            root  293u  IPv4 1577890      0t0  UDP localhost:52194->localhost:domain 
dockerd     1623            root  296u  IPv4 1605903      0t0  UDP localhost:50866->localhost:domain 
dockerd     1623            root  319u  IPv4 1605904      0t0  UDP localhost:58574->localhost:domain 
dockerd     1623            root  341u  IPv4 1605910      0t0  UDP localhost:37123->localhost:domain 
dockerd     1623            root  342u  IPv4 1610067      0t0  UDP localhost:48734->localhost:domain 
dockerd     1623            root  343u  IPv4 1610069      0t0  UDP localhost:35580->localhost:domain 
dockerd     1623            root  344u  IPv4 1605905      0t0  UDP localhost:45133->localhost:domain 
dockerd     1623            root  345u  IPv4 1618982      0t0  UDP localhost:53052->localhost:domain 
dockerd     1623            root  346u  IPv4 1589996      0t0  UDP localhost:56714->localhost:domain 
dockerd     1623            root  347u  IPv4 1614009      0t0  UDP localhost:37216->localhost:domain 
dockerd     1623            root  348u  IPv4 1589997      0t0  UDP localhost:38032->localhost:domain 
dockerd     1623            root  349u  IPv4 1618984      0t0  UDP localhost:53714->localhost:domain 
dockerd     1623            root  350u  IPv4 1610084      0t0  UDP localhost:42922->localhost:domain 
dockerd     1623            root  351u  IPv4 1577893      0t0  UDP localhost:32865->localhost:domain 
dockerd     1623            root  352u  IPv4 1608975      0t0  UDP localhost:58307->localhost:domain 
dockerd     1623            root  353u  IPv4 1597699      0t0  UDP localhost:33564->localhost:domain 
dockerd     1623            root  354u  IPv4 1608977      0t0  UDP localhost:58235->localhost:domain 
dockerd     1623            root  355u  IPv4 1577896      0t0  UDP localhost:46068->localhost:domain 
dockerd     1623            root  356u  IPv4 1597702      0t0  UDP localhost:32827->localhost:domain 
systemd-r 106795 systemd-resolve   12u  IPv4  980615      0t0  UDP localhost:domain 
systemd-r 106795 systemd-resolve   13u  IPv4  980616      0t0  TCP localhost:domain (LISTEN)
http      165553            _apt    3u  IPv4 1611999      0t0  UDP localhost:54478->localhost:domain 

Дополнительные замечания:

· Восходящий DNS-сервер - это Raspberry Pi 3 B +, работающий под управлением pihole. Ни у кого в моей сети нет этих проблем с разрешением DNS , поэтому проблема не в pihole.

· сеансы ssh к серверу не падают, когда эта проблема происходит.

· ping ing внешних IP-адресов отлично работает, когда возникает проблема.

Я выдергивал волосы, пытаясь понять это. Если у кого-то есть идеи,Буду рад их услышать.

0
задан 29 April 2021 в 22:49

2 ответа

TL; DR: Убедитесь, что Pi-Hole не ограничивает скорость ваших запросов.

Сегодня я наконец нашел в Google «ограничение скорости пирамиды», и вот это недавнее сообщение в блоге упоминает:

... мы решили реализовать настраиваемое ограничение скорости в сам FTL . По умолчанию используется довольно консервативный предел, разрешающий не более 1000 запросов в 60-секундном окне для каждого клиента.

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

1000 запросов за 60 секунд могут показаться большим количеством, но с 38 активными контейнерами Docker (и особенно Watchtower и matrix-synapse ) они заполняются в спешке.

0
ответ дан 7 May 2021 в 17:42

Здравствуйте и добро пожаловать на форум!

Возможно, стоит рассмотреть возможность того, что ваша проблема на самом деле не в DNS, возможно, ваше сетевое соединение по какой-то причине просто ненадежно, что некоторые пакеты теряются. Тот факт, что сеансы ssh выживают, мало что говорит нам, потому что сеанс ssh использует TCP, поэтому он может работать, даже если много пакетов потеряно. DNS, с другой стороны, использует UDP, поэтому потеря некоторых пакетов UDP (входящих или исходящих) может привести к сбоям DNS.

Тестирование с использованием ping, как и вы, является хорошей идеей, возможно, стоит сделать больше этого, например, проверять связь чаще, чем один раз в секунду, чтобы узнать, не происходит ли потеря пакетов и коррелирует ли время этого с проблемами DNS. . Также стоит отметить, что ping использует другой протокол (ICMP), может случиться так, что с UDP есть какие-то проблемы, но этот ping все равно работает. Затем, возможно, стоит запустить тесты с использованием UDP, что можно сделать, например, с помощью инструмента iperf3 .

Если вы сами управляете DNS-сервером, вы можете отслеживать это, чтобы узнать, поступил ли DNS-запрос или нет, и чтобы увидеть, отправлен ли ответ с DNS-сервера.

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

В любом случае это некоторые идеи, я надеюсь, что некоторые из них могут быть полезны. Удачи!

0
ответ дан 7 May 2021 в 17:42

Другие вопросы по тегам:

Похожие вопросы: