Jump to content
Калькуляторы

Вопрос по траблшутингу Unbound

Есть сервер с 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 ГБ логов за сутки), но каких-либо сбоев в логах я все равно не нашел.

 

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

Share this post


Link to post
Share on other sites

unbound-control dump_cache | grep domain

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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), но навряд-ли она имеет отношение к проблеме с хостом.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
2 минуты назад, alibek сказал:

в 1.4

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
51 минуту назад, alibek сказал:

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

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

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

Share this post


Link to post
Share on other sites
1 час назад, alibek сказал:

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Обновление до 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 минут так и не удалось поймать таймаут, хотя за это время выполнилось несколько тысяч запросов.

Share this post


Link to post
Share on other sites

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

 

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

Edited by GHhost

Share this post


Link to post
Share on other sites
16 часов назад, GHhost сказал:

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

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

Share this post


Link to post
Share on other sites
3 минуты назад, Ivan_83 сказал:

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

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

Share this post


Link to post
Share on other sites
2 минуты назад, GHhost сказал:

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

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

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

Share this post


Link to post
Share on other sites
1 минуту назад, Ivan_83 сказал:

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

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

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

Share this post


Link to post
Share on other sites
3 минуты назад, GHhost сказал:

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

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

Share this post


Link to post
Share on other sites
3 минуты назад, Ivan_83 сказал:

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

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

Share this post


Link to post
Share on other sites
On 3/15/2019 at 2:28 PM, alibek said:

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

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

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

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

Share this post


Link to post
Share on other sites
В ‎19‎.‎03‎.‎2019 в 02:35, GHhost сказал:

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

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

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

 

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this