Имеется пара DNS серверов, один master, второй slave, исправно работали несколько лет. Master обслуживает как внутренних так и внешних клиентов (четыре внешних зоны), slave только внутренних. С нового года начались проблемы - систематически (2-3 раза в неделю, иногда пару раз в день) ответы обоих серверов начинают приходить с большой задержкой и в конце концов пропадают синхронно на обоих серверах. Логфайлы обоих bind показывают, что запросы приходят, но ответов клиенты не получают (time out), даже если запрос делать на самом сервере. Помогает только рестарт всей машины, рестарт только bind9 не помогает. В то же время другие сервисы (почта, ssh) работают. То есть, проблема пока наблюдается только с работой bind. В то же время, поскольку bind продолжает записывать в лог запросы и его рестарт не помогает, причина связана с чем то еще.

Какая-то корреляция наблюдается с нагрузкой - когда оба сервера обслуживают всех клиентов внутренних сетей, то перестают отвечать синхронно и время работы меньше двух суток. Когда сервера обслужиавют разные сети (клиенты не прекрываются), то работают немного дольше и ответы пропадают в разное время. Физически машины не нагружены - процессор менше 1%, память 3.5%, диск 1%.

Кто либо встречался с подобным? И как определить, куда деваются ответы bind (запросы он получает и пишет в лог, рестарт bind9 на помогает)?

Я бы порылся в ситемном логе OS на предмет всяких errors о достижении лимита соединений, файлов пер процесс и т.д.

Там бежит только DNS, так что логи весьма пустые и ошибок не видать. Единственный "error" такой:

CODE

Jan 14 10:45:35 ns kernel: [    0.997174] PM: Resume from partition 8:1 Jan 14 10:45:35 ns kernel: [    0.997175] PM: Checking hibernation image. Jan 14 10:45:35 ns kernel: [    0.997354] PM: Error -22 checking image file Jan 14 10:45:35 ns kernel: [    0.997358] PM: Resume from disk failed.

Но это на всех серверах, поиск hibernation image после рестарта. Поскольку его нету, выдается общение об ошибке.

Лимит файлов bind сам увеличивает уже в процессе старта:

CODE

Jan 14 10:45:36 ns named[1160]: adjusted limit on open files from 1024 to 1048576

Все другие сетевые вещи работают, в том числе и почта, повидимому потому, что что в resolv.conf прописан и другой DNS серве (но при следующем глюке проверю, работают ли запросы на 127.0.0.1). Единственный видимый глюк это отсутствие ответов bind9, запросы он видит и пишет в лог.
:pig:

По поводу лога bind. У меня все запросы и security пишуться в отдельный лог. Поскольку (кроме одного случая), серверы "зависали" в одно время, возникло подозрение, что они получили какие-то "плохие" запросы (время от времени появляются попытки захватить сервер путем всяких нехороших запросов). Однако никакого подобного криминала в логах заметно не было. Да и bind исправно принимал запросы и писал их в лог.

Правда, одну интересную штуку я заметил. Похоже, что NOD32 посылает информацию в свою контору, используя для этого DNS запросы:

CODE

15-Jan-2016 07:15:48.447 queries: client 192.168.40.124#49913: view internal: query: g63suaacaakj2myaaeaaaagsaqaabyxdca4gxz36vvdk7byjagetcak3aaaabou.lkalqaaaraahaaa7rc2b5vk5hwugtkpmk3isgoujzjrdygb6zgaskxk2arepexi.wkzfblix2d3zsqcdiz6icpnsfhmx5i3zwhlp45ksn3pcprougf67sgv3qjtl3hc.sif7f6znuy2ofeql6l5s3jru.a.j.e5.sk IN TXT + (192.168.10.3) 15-Jan-2016 07:15:48.656 queries: client 192.168.40.124#49913: view internal: query: aj7suaacaakj2myaaeaaaagsaqaabyxdca4gxz36vvdk7byjagetcai3aaaaajz.x6tbacaaoaafqakjt6e2ynxorfwyugd7qgyemnnirbhuzt7y.a.j.e5.sk IN TXT + (192.168.10.3)

Метода, конечно, неспешная, но зато такая передача данных не шибко заметна и запросы DNS выглядят (для сервера) вплоне себе легитимными. :rolleyes:
Или это какая-то зараза? :w00t:

Смущает что на двух серверах сразу, или почти сразу. Точно локально не работает когда с самого сервера запрос идет (имя из кеша в том числе)?

А если демон остановить минут на 5 и перезапустить без ребута?

Если (с самого сервера) запрос посылать на реальноый ИП-адрес:

CODE

nslookup eee.ee 192.168.10.3

получается таймаут. К сожалению не пробовал (но в следующий раз попробую) обращаться по адресу 127.0.0.1

CODE

nslookup eee.ee 127.0.0.1

но подозреваю, что там тоже таймаут. eee.ee я при таких тестах использую часто (обычно сразу после перезапуска сервера, чтобы убедиться в его работе), так что он сидит в кеше. Выжидать 5 минут не пробовал, но в следующий раз можно попробовать (перегрузив второй сервер).

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

что-то я не понял, сервера не отвечают на запросы на авторизированные зоны или на рекурсивные запросы? Или и на те и на те?

Для начала таки проверь, что сервера именно, что свои (авторизированные) зоны не могут отресолвить.
Если-же окажется, что проблема только с рекурсивными запросами, то надо смотреть куда он там далее обращается и что там может быть не так.
Собственно, можно изначально послушать сеть и посмотреть что там куда идет и идет-ли.

P.S. Вообще 9.7.3 в плане дырок весьма того. Его-бы проапгрейдить до 9.9.8-P2 или чего-нить подобного.

Рекурсивные запросы точно не работают, а свои зоны я как то сознательно и не проверял, при следующем глюке обязатльно проверю. А дальше серверы обращаются к DNS серверам провайдера, т.е ражим forward only.

Чтобы апгрейдить bind, придется и сам линукс проапгрейдить (9.7.3 для Squeeze последняя версия). Поскольку там кроме DNS ничего нет, то запустить новые серверы на свежем линуксе очень просто и явно решит проблему. Но очеь хочется сперва узнать, "откуда происходит подземный стук". :)

Поразмышлял над вашми впросами/советами и, возможно, понял, что не так. Собак зарыт в "forward only". Это пережиток старых времен, когда ответ от сервера провайдера приходил гораздо быстрее чем при самостоятельном поиске.

Сервера провайдера имеют какой-то лимит на число запросов в секунду с одного IP. Когда число запросов с одного из серверов переходит эту границу, ответы перстают поступать (или приходят с очень большой задержкой). Далее все наши запросы идут со второго сервера и скоро блокируется и второй сервер.

Это объясняет, почему рестарт bind9 на помогает - рестарт очень быстрый и запросы практически не прерываются. А при рестарте всего сервера возникает более знчительная пауза в запросах и сервер провайдера начинает отввечать нормально.

Проверка проста (при следующем глюке):
1. С сервера запрос локального адреса из своей зоны. Если я прав, ответ будет.
2. С сервера запросить прямо сервер провайдера. Если я прав, будет тайм-аут.
3. Остановить bind9 на несколько минут и запустить опяь. Если я прав, все заработает.

Для лечения достаточно будет изменить "forward only" на "forward first" или вообще убрать. В общем, увидим на будущей неделе, когда у серверов опять будет полная нагрузка.

ну что там с настройками у провайдера - это к штатному телепату.

Что касается более новой версии - тут зависит. Если лень переставлять систему, то можно скомпилить новый бинд на старой. Не великий труд.

Сегодня подземного стука не было. Буду ждать дальше. По крайней мере ясно, как сузить круг поиска.

FiL
ПО поводу ограничений на сервере провайдера просто мое предположение, почему-то не написал слово "возможно" :)

Сегодня опять замолчал один из серверов.

1. На любые рекурсивные nslookup запросы (все рано, локально или из сети) ответ:

CODE

; Connection timed out; no servers could be reached

2. На запросы своих зон ответ нормальный.
3. Все запросы пишутсяв лог запросов.
3. Forward серверы на запрос отвечают сразу.
4. На файерволе прямые обращения к Forward серверам регистрируются и не блокируются.
5. Не успел проверить, идет ли обращение к Forward серверам, если обращаться к bind, так как к этому времени (прошло примерно 5 мин) все вдруг заработало! :fear2:

Другими словами, картина такая:

1. Все обращения к bind9 пишутся в лог, т.е. сервер живой.
2. Запросы про свои сети работают нормально.
3. Рекурсивные запросы не работают - таймаут, так как forward only.
4. Прямые обращения к Forward серверам с серверной машины работают нормально (т.е. внешней блокировки нет).
5. Не успел выяснить причину таймаута, то есть посылет ли bind9 вообще запрос к форвардерам или посылает запрос но не воспринимет ответа, так как (см следующий пункт)
6. Примерно через 5 мин все оживает само и сервер работает нормально.

Вот такие пироги. :pig:

Ну, если bind на свои зоны отвечает, а проблемы только с рекурсивными запросами к форвардерам, то это скорее надо у форвардеров проблему искать. А лучше впиши в список форвардеров еще пару гугловых серверов, авось поможет.

FiL
В том то и дело, что

QUOTE

4. Прямые обращения к Forward серверам с серверной машины работают нормально (т.е. внешней блокировки нет).

То есть, находясь на серверной машине

CODE

nslookup eee.ee provider_IP

- сервера провайдера отвечают сразу

CODE

nslookup eee.ee 127.0.0.1 (или 192.168.10.3)

- обращение к локальному bind9 - таймаут. И тут я просто не успел проверить на файерволе, посылает ли bind9 вообще запрос к сервреру провайдера. Я подозреваю, что нет.

Или ты имел в виду, что сервер провайдера отличет запросы bind9 и nslookup с одной и той же машины и игнорирует первые но отвечает на вторые?

PS. Добавил 8.8.8.8, но боюсь, это не поможет.

Тоже правда. Уговорил.

И все-таки, для проверки, не поленись, скачай и скомпилируй новенький bind. Это со всех сторон полезно будет.