[alibek]

Есть сервер с NSD и Unbound.

NSD работает на 127.0.0.53, Unbound работает на 127.0.0.1.

Зоны, обслуживаемые NSD, в Unbound сконфигурированы как stub с переадресацией stub-addr на 127.0.0.53.

Долгое время все работало без сбоев и какого-либо присмотра.

Некоторое время назад в одной из stub-зон стали возникать проблемы с ресолвингом.

Допустим есть хост server.provider.local с IP-адресом 10.1.128.2. В какой-то момент времени этот хост перестает ресолвится.

Если на сервере выполнить команду nslookup server.provider.local 127.0.0.53, то запрос выполняется (хост ресолвится), то есть авторитетный сервер, обслуживающий эту зону, работает.

Если на сервере выполнить команду nslookup server.provider.local 127.0.0.1, то запрос не выполняется, ошибку я точно не помню, не то nxdomain, не то refused.

При этом с другими зонами (в том числе с публичными хостами) проблем нет, они всегда работают нормально.

Если рестартовать Unbound, все тут же начинает работать. Время от рестарта до момента, когда хост снова перестает ресолвится, непредсказуемо, иногда недели, иногда часы. Иногда ресолвинг хоста восстанавливается сам, без перезапуска.

При verbosity:1 в логах ничего нет. При verbosity:2 в логах очень много всего (почти 3 ГБ логов за сутки), но каких-либо сбоев в логах я все равно не нашел.

 

Куда начать смотреть?

[ixi]

unbound-control dump_cache | grep domain

[Ivan_83]

Я бы посмотрел что там с кешем негативных ответов. Вероятно кто то пытается резолвить домены из той зоны которых там нет и оно всё как то уходит в кеш.

[alibek]

Дождусь глюка и проверю.

Заодно проверю как ресолвятся другие хосты в этой зоне — раньше как-то не сообразил проверить.

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

[alibek]

Наконец повторилось.

nslookup srv-bm-app.prov.local 127.0.0.1 - nxdomain

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

Видимо nxdomain как-то закешировался, что непонятно.

unbound-control dump_cache | grep "srv-bm-app"
msg srv-bm-app.prov.local. IN A 32899 1 69522 4 0 3 0
msg srv-bm-app.prov.local.prov. IN AAAA 32899 1 1576 3 0 1 0
msg srv-bm-app.prov.local.prov. IN A 32899 1 1576 3 0 1 0
msg srv-bm-app.prov.local. IN AAAA 32899 1 68081 4 0 3 0
msg srv-bm-app.prov.local.prov.local. IN A 32899 1 3322 3 0 1 0

Также не обязателен перезапуск сервера, достаточно очистить кеш:

unbound-control flush_zone prov.local
ok removed 7 rrsets, 28 messages and 0 key entries

В логе за все это время появилась только одна ошибка (unbound[20992:0] error: could not SSL_write crypto error), но навряд-ли она имеет отношение к проблеме с хостом.

[taf_321]

Будет ли повторяться ошибка если stub-зону заменить на auth?

[alibek]

Это с какой версии? У меня в 1.4 такая зона в конфиге не поддерживается.

Но не думаю, что это как-то влияет.

[ixi]

2 минуты назад, alibek сказал:

в 1.4

Кто знает, какие ошибки были с тех пор исправлены.. Можете заняться шаманством, поднять ещё один unbound на другом порту, с подробными логами и ресолвингом по крону. На основном сервере можно пока уменьшить ttl для ошибок.

[alibek]

А можно ли как-то глянуть подробности по rrset для тех записей msg, которые лежат в кеше при проявившемся глюке?

Или только детальные логи?

[taf_321]

51 минуту назад, alibek сказал:

Это с какой версии? У меня в 1.4 такая зона в конфиге не поддерживается.

Но не думаю, что это как-то влияет.

auth-zone появился начиная с 1.7. Но я бы рекомендовал догоняться до последнего релиза. Со времен 1.4 в Changelog вагон и тележка упоминаний пофиксеных утечек памяти, крашей, CVE, race condition, что мама не горюй.

[ixi]

1 час назад, alibek сказал:

А можно ли как-то глянуть подробности по rrset для тех записей msg, которые лежат в кеше при проявившемся глюке? 

Нет. Можете распарсить флаги или сохранить полный дамп, соседние строки может что подскажут.

[alibek]

Обновился до 1.4.22, это последняя версия в репозиториях Debian 8.

Посмотрим, может этого будет достаточно.

Не хотелось бы ставить софт не из репозиториев.

[GHhost]

хм, творилось нечто подобное,  unbound с форвардом около 10 зон, тоже работало года 2, ну обновлялось конечно, но проблемы начались с месяц назад - периодические факапы с резольвингом чего нибудь из этих зон лечащиеся рестартом, замена на stub ниче не дала, обновление до последнего тоже, стоял он в тепличном месте можно сказать - клиентских запросов к нему небыло, обслуживал он только почтовик и всякую его вспомогательную хрень фильтрующую спам. в итоге не стал разбираца - плюнул и переехал на bind.

[alibek]

Обновление до 1.4.22 не помогло.

Пока что важные хосты внес в /etc/hosts.

Переходить на BIND бы не хотелось, трафик на сервере достаточно большой и Unbound работает (работал) лучше.

 

Кстати, глюк случается не с одним конкретным хостом.

Чаще всего это бывает srv-bm-app, но иногда это бывает какой-то другой хост, а srv-bm-app работает нормально.

Скорее всего это зависит от частоты обращений, в данной зоне чаще всего обращения идут именно к srv-bm-app.

 

Дамп кеша я сделал, но ни на какие полезные мысли он меня не натолкнул.

В rrset находится большая пачка данных, как положительных, так отрицательных (msg), никаких зависимостей я не вижу.

Может быть авторитетный сервер однажды не дал ответ, а unbound это закешировал как nxdomain.

Правда мне так и не удалось эмулировать таймаут авторитетного сервера - даже при запуске в непрерывном цикле:

while true; do host srv-bm-app.prov.local 127.0.0.53; done

в течение где-то 5 минут так и не удалось поймать таймаут, хотя за это время выполнилось несколько тысяч запросов.

[GHhost]

ну траффик большой понятие относительное, но клиентов у нас pdns сервит аш пыль столбом, проблем с ним небыло никогда.

 

P.S. В моих глюках с unbound ситуация что авторитативный сервер не ответил была практически исключена, во первых их там два, во вторых на них логгинг - еслип не ответил написал бы, ну и они там под боком - настолько крутой packet loss я бы тоже практически исключил - мониторинг оборался бы значительно раньше. Еще пробовал форвардить на рекурсоры - тоже не помогло, тоесть чтото всетаки с unbound не так было.

Изменено 19 марта, 2019 пользователем GHhost

[Ivan_83]

16 часов назад, GHhost сказал:

Еще пробовал форвардить на рекурсоры - тоже не помогло, тоесть чтото всетаки с unbound не так было.

Заведи тикет в багтрекере, а то никто так и не узнает об этом.

[GHhost]

3 минуты назад, Ivan_83 сказал:

Заведи тикет в багтрекере, а то никто так и не узнает об этом.

это бесполезно, никакой диагностики нет, способа воспроизвести тоже, одни подозрения что виноват unbound, че толку от этого тикета.

[Ivan_83]

2 минуты назад, GHhost сказал:

это бесполезно, никакой диагностики нет, способа воспроизвести тоже, одни подозрения что виноват unbound, че толку от этого тикета.

Там тебе объяснят как диагностировать.

В любом случае лучше донести до разрабов чем варится в собственном соку.

[GHhost]

1 минуту назад, Ivan_83 сказал:

Там тебе объяснят как диагностировать.

В любом случае лучше донести до разрабов чем варится в собственном соку.

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

[Ivan_83]

3 минуты назад, GHhost сказал:

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

Такой подход неизбежно приводит к тому, что софта который тебе подходит не остаётся в природе.

[GHhost]

3 минуты назад, Ivan_83 сказал:

Такой подход неизбежно приводит к тому, что софта который тебе подходит не остаётся в природе.

В теории, а по факту ДНС серверов куча - боюсь не доживу когда коньчаца.

[Telesis]

On 3/15/2019 at 2:28 PM, alibek said:

Обновился до 1.4.22, это последняя версия в репозиториях Debian 8.

Посмотрим, может этого будет достаточно.

Не хотелось бы ставить софт не из репозиториев.

Все же попробуйте собрать самый последний.

[alibek]

В ‎19‎.‎03‎.‎2019 в 02:35, GHhost сказал:

настолько крутой packet loss

У меня же loopback, какие тут могут быть потери.

Могли быть неответы из-за высокой нагрузке, но если в течение 5 минут с высоким qps (навскидку более 200) пропусков не было, значит дело не в этом.

 

18 минут назад, Telesis сказал:

Все же попробуйте собрать самый последний.

Это боевой сервер, который еще и дополнительными задачами нагружен.

Так что на нем эксперименты со сборкой софта из исходников исключаются.

Если получится воспроизвести проблему на тестовом сервере, тогда поэкспериментирую с обновлениями.

[Ivan_83]

Всякие wmem и прочие линуксовые хрени для буферов крутил?

А то потери могли быть просто от переполнения буферов сокета.

[alibek]

Раньше крутил, сейчас перепроверю.

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

К тому же судя по ответам, у меня unbound ошибочно кеширует nxdomain, а не не отвечает на запросы.