Не BIND'ом единым жив DNS

[Raven]

bammbr
Да, был такой момент - очепятко.

[robin13]

Спасибо за статью. Построил PDNS+PgSQL+Unbound, поднялось без проблем.
Но заметил такой нюанс, который как бы не совсем и нюанс, получается
В Вашем конфиге: PDNS сидит на внешнем интерфейсе, Unbound - на внутреннем.
При получении рекурсивного запроса (не из авторитарной зоны), PDNS проходится по БД (при этом делая 6!!! отдельных запросов), не находит соответствующие записи, и только тогда отправляет в поисках ответа к Unbound'у. Учитывая, что 99% DNS-запросов рекурсивные - это огромная нагрузка на БД (не поможет и кеширующий пг-прокси и т.п.), не думаю что разработчики не предусмотрели этот момент.
Нет ли в PDNS своего кэша (с актуальными зонами), не найдя в котором, запрос перенаправлялся б рекурсору (или чего-то подобного..).
Ничего похожего в манах, конфиге не нашел, гугл тоже как партизан..

З.Ы.
Пока не нашел решения с нагрузкой на БД, разнес Unbound и PDNS по разным внешним IP (сидят на одной железке). PDNS отвечает только за свои зоны. Клиентов обслуживает Unbound (при этом смысла прописывать форвардинг на PDNS не нашел, ведь он как никак кеширующий, а зон не мало). При первом тесте за 2 часа обслуживания клиентов (около 3000), нагрузка на железку составляла на 30-50% меньше, чем со стареньким биндом на этом же железе.

[Raven]

Вообще (по хорошему) оно так и делается - авторитативный сервер должен быть ТОЛЬКО авторитативным и смотреть в инет с отдельного интерфейса, клиентам же должен быть доступен только рекурсивный сервер. Описаное выше решение было в первую очередь обусловлено наличием только одного интерфейса и одного белого IP.

Использовалась данная связка в течении 1,5 лет на машине с весьма скромными параметрами, с около 100 зон и 15-20 тыс. клиентов. Весьма надо сказать успешно - bind ту машинку вообще валил в ступор. Потом сменилось руководство, а вместе с ним и 90% коллектива компании, и сервер успешно похоронили - вместо него поставили PleskPanel с bind'ом и погрузили все зоны на него.

В вашем случае главным потребителем ресурсов будет БД. Я бы порекомендовал в первую очередь заняться тюнингом ее сервера, либо сменой СУБД на что-нибудь получше (PostgreSQL например). Например задуматься о значении параметров query_cache_*, *_buffer_size