Последние 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: не удается разрешить"
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-адресов отлично работает, когда возникает проблема.
Я выдергивал волосы, пытаясь понять это. Если у кого-то есть идеи,Буду рад их услышать.
Сегодня я наконец нашел в Google «ограничение скорости пирамиды», и вот это недавнее сообщение в блоге упоминает:
... мы решили реализовать настраиваемое ограничение скорости в сам FTL . По умолчанию используется довольно консервативный предел, разрешающий не более 1000 запросов в 60-секундном окне для каждого клиента.
Я был вне себя и полностью пропустил эту новость. Я открыл запрос функции с помощью Pi-Hole, чтобы добавить в журнал запись о том, когда это произойдет, надеюсь, чтобы будущий домашний системный администратор не вырывал себе волосы.
1000 запросов за 60 секунд могут показаться большим количеством, но с 38 активными контейнерами Docker (и особенно Watchtower и matrix-synapse
) они заполняются в спешке.
Здравствуйте и добро пожаловать на форум!
Возможно, стоит рассмотреть возможность того, что ваша проблема на самом деле не в DNS, возможно, ваше сетевое соединение по какой-то причине просто ненадежно, что некоторые пакеты теряются. Тот факт, что сеансы ssh выживают, мало что говорит нам, потому что сеанс ssh использует TCP, поэтому он может работать, даже если много пакетов потеряно. DNS, с другой стороны, использует UDP, поэтому потеря некоторых пакетов UDP (входящих или исходящих) может привести к сбоям DNS.
Тестирование с использованием ping, как и вы, является хорошей идеей, возможно, стоит сделать больше этого, например, проверять связь чаще, чем один раз в секунду, чтобы узнать, не происходит ли потеря пакетов и коррелирует ли время этого с проблемами DNS. . Также стоит отметить, что ping использует другой протокол (ICMP), может случиться так, что с UDP есть какие-то проблемы, но этот ping все равно работает. Затем, возможно, стоит запустить тесты с использованием UDP, что можно сделать, например, с помощью инструмента iperf3
.
Если вы сами управляете DNS-сервером, вы можете отслеживать это, чтобы узнать, поступил ли DNS-запрос или нет, и чтобы увидеть, отправлен ли ответ с DNS-сервера.
Вы также можете попробовать отслеживать входящий и исходящий сетевой трафик локально, используя что-то вроде tcpdump
или tshark
, чтобы убедиться, что запрос DNS отправлен, и проверить, получен ли ответ от DNS. сервер можно увидеть.
В любом случае это некоторые идеи, я надеюсь, что некоторые из них могут быть полезны. Удачи!