alibek Опубликовано 12 марта, 2019 · Жалоба Есть сервер с 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 ГБ логов за сутки), но каких-либо сбоев в логах я все равно не нашел. Куда начать смотреть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ixi Опубликовано 12 марта, 2019 · Жалоба unbound-control dump_cache | grep domain Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 марта, 2019 · Жалоба Я бы посмотрел что там с кешем негативных ответов. Вероятно кто то пытается резолвить домены из той зоны которых там нет и оно всё как то уходит в кеш. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 12 марта, 2019 · Жалоба Дождусь глюка и проверю. Заодно проверю как ресолвятся другие хосты в этой зоне — раньше как-то не сообразил проверить. Просто оно после первоначальной настройки и тюнинга где-то с год работало без какого-либо внимания, я уже и забывать стал, что у меня DNS-сервер есть. И в сети ничего особо не менялось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 14 марта, 2019 · Жалоба Наконец повторилось. 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), но навряд-ли она имеет отношение к проблеме с хостом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 15 марта, 2019 · Жалоба Будет ли повторяться ошибка если stub-зону заменить на auth? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 15 марта, 2019 · Жалоба Это с какой версии? У меня в 1.4 такая зона в конфиге не поддерживается. Но не думаю, что это как-то влияет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ixi Опубликовано 15 марта, 2019 · Жалоба 2 минуты назад, alibek сказал: в 1.4 Кто знает, какие ошибки были с тех пор исправлены.. Можете заняться шаманством, поднять ещё один unbound на другом порту, с подробными логами и ресолвингом по крону. На основном сервере можно пока уменьшить ttl для ошибок. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 15 марта, 2019 · Жалоба А можно ли как-то глянуть подробности по rrset для тех записей msg, которые лежат в кеше при проявившемся глюке? Или только детальные логи? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 15 марта, 2019 · Жалоба 51 минуту назад, alibek сказал: Это с какой версии? У меня в 1.4 такая зона в конфиге не поддерживается. Но не думаю, что это как-то влияет. auth-zone появился начиная с 1.7. Но я бы рекомендовал догоняться до последнего релиза. Со времен 1.4 в Changelog вагон и тележка упоминаний пофиксеных утечек памяти, крашей, CVE, race condition, что мама не горюй. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ixi Опубликовано 15 марта, 2019 · Жалоба 1 час назад, alibek сказал: А можно ли как-то глянуть подробности по rrset для тех записей msg, которые лежат в кеше при проявившемся глюке? Нет. Можете распарсить флаги или сохранить полный дамп, соседние строки может что подскажут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 15 марта, 2019 · Жалоба Обновился до 1.4.22, это последняя версия в репозиториях Debian 8. Посмотрим, может этого будет достаточно. Не хотелось бы ставить софт не из репозиториев. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GHhost Опубликовано 18 марта, 2019 · Жалоба хм, творилось нечто подобное, unbound с форвардом около 10 зон, тоже работало года 2, ну обновлялось конечно, но проблемы начались с месяц назад - периодические факапы с резольвингом чего нибудь из этих зон лечащиеся рестартом, замена на stub ниче не дала, обновление до последнего тоже, стоял он в тепличном месте можно сказать - клиентских запросов к нему небыло, обслуживал он только почтовик и всякую его вспомогательную хрень фильтрующую спам. в итоге не стал разбираца - плюнул и переехал на bind. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 18 марта, 2019 · Жалоба Обновление до 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 минут так и не удалось поймать таймаут, хотя за это время выполнилось несколько тысяч запросов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GHhost Опубликовано 18 марта, 2019 (изменено) · Жалоба ну траффик большой понятие относительное, но клиентов у нас pdns сервит аш пыль столбом, проблем с ним небыло никогда. P.S. В моих глюках с unbound ситуация что авторитативный сервер не ответил была практически исключена, во первых их там два, во вторых на них логгинг - еслип не ответил написал бы, ну и они там под боком - настолько крутой packet loss я бы тоже практически исключил - мониторинг оборался бы значительно раньше. Еще пробовал форвардить на рекурсоры - тоже не помогло, тоесть чтото всетаки с unbound не так было. Изменено 19 марта, 2019 пользователем GHhost Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 марта, 2019 · Жалоба 16 часов назад, GHhost сказал: Еще пробовал форвардить на рекурсоры - тоже не помогло, тоесть чтото всетаки с unbound не так было. Заведи тикет в багтрекере, а то никто так и не узнает об этом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GHhost Опубликовано 19 марта, 2019 · Жалоба 3 минуты назад, Ivan_83 сказал: Заведи тикет в багтрекере, а то никто так и не узнает об этом. это бесполезно, никакой диагностики нет, способа воспроизвести тоже, одни подозрения что виноват unbound, че толку от этого тикета. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 марта, 2019 · Жалоба 2 минуты назад, GHhost сказал: это бесполезно, никакой диагностики нет, способа воспроизвести тоже, одни подозрения что виноват unbound, че толку от этого тикета. Там тебе объяснят как диагностировать. В любом случае лучше донести до разрабов чем варится в собственном соку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GHhost Опубликовано 19 марта, 2019 · Жалоба 1 минуту назад, Ivan_83 сказал: Там тебе объяснят как диагностировать. В любом случае лучше донести до разрабов чем варится в собственном соку. Мне не нада - я очень хорошо знаю как не круто дебажить днс на почтовом сервере, это вам не браузер где ой еррор - аборт ретрай ингнор? тут сразу отлуп всем с этого/на этот домен и субдомены и еще и закеширует, так что извините но тут дебажте без меня, не на столько незаменимиый софт чтоп оправдать такой геморой для меня. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 марта, 2019 · Жалоба 3 минуты назад, GHhost сказал: Мне не нада - я очень хорошо знаю как не круто дебажить днс на почтовом сервере, это вам не браузер где ой еррор - аборт ретрай ингнор? тут сразу отлуп всем с этого/на этот домен и субдомены и еще и закеширует, так что извините но тут дебажте без меня, не на столько незаменимиый софт чтоп оправдать такой геморой для меня. Такой подход неизбежно приводит к тому, что софта который тебе подходит не остаётся в природе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GHhost Опубликовано 19 марта, 2019 · Жалоба 3 минуты назад, Ivan_83 сказал: Такой подход неизбежно приводит к тому, что софта который тебе подходит не остаётся в природе. В теории, а по факту ДНС серверов куча - боюсь не доживу когда коньчаца. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 20 марта, 2019 · Жалоба On 3/15/2019 at 2:28 PM, alibek said: Обновился до 1.4.22, это последняя версия в репозиториях Debian 8. Посмотрим, может этого будет достаточно. Не хотелось бы ставить софт не из репозиториев. Все же попробуйте собрать самый последний. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 20 марта, 2019 · Жалоба В 19.03.2019 в 02:35, GHhost сказал: настолько крутой packet loss У меня же loopback, какие тут могут быть потери. Могли быть неответы из-за высокой нагрузке, но если в течение 5 минут с высоким qps (навскидку более 200) пропусков не было, значит дело не в этом. 18 минут назад, Telesis сказал: Все же попробуйте собрать самый последний. Это боевой сервер, который еще и дополнительными задачами нагружен. Так что на нем эксперименты со сборкой софта из исходников исключаются. Если получится воспроизвести проблему на тестовом сервере, тогда поэкспериментирую с обновлениями. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 марта, 2019 · Жалоба Всякие wmem и прочие линуксовые хрени для буферов крутил? А то потери могли быть просто от переполнения буферов сокета. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 20 марта, 2019 · Жалоба Раньше крутил, сейчас перепроверю. Но если бы дело было в этом, то проблемы должны были бы возникать вообще с любыми сервисами, а не с конкретной зоной и обычно конкретным хостом. К тому же судя по ответам, у меня unbound ошибочно кеширует nxdomain, а не не отвечает на запросы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...