Большинство администраторов, когда становятся уже слишком серьезными, чтобы просто так использовать DNS-сервера провайдера, часто выбирают bind в качестве DNS-сервера. Дальше bind подталкивает их к использованию не самых хороших практик, например, совмещению ролей резольвера и авторитетного DNS.

Несмотря на все свои крутые преимущества, вроде split horizon, bind, к сожалению, далек по своей производительности от оптимального выбора.

В докладе рассматриваются следующие конфигурации:

1. Просто (быстрый) резольвер. Области применения: организация, провайдер, ЦОД

Провайдеру и ЦОДу это нужно по-умолчанию. Организациям это нужно тогда, когда объем запросов к провайдерским DNS начинает жать спереди.

Здесь властвует unbound. Важные пункты:
- никаких форвардов на Яндекс или Гугл
- SO_REUSEPORT
- prefetch
- DNSSEC-валидация обязательно
- что мониторить?

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

2. Свои зоны. Области применения: организация, провайдер, иногда ЦОД

Своя DNS-зона рано или поздно появляется у каждого. Здесь, конечно, только PowerDNS. Важные пункты:
- почему только база данных, только хардкор
- почему никаких XFR, а только уровень базы данных
- почему репликация БД тут плохо, и что тут хорошо?
- и как насчет хранения зоны, гм, в git-репозитории?
- что мониторить?

3. Сочетание своих зон и резольвера

У провайдеров, да и часто в крупных организациях, возникает необходимость блокировать резолвинг каких-то записей. Причин тому масса - от требований закона до вирусов. Здесь нужно использовать PowerDNS и unbound в режиме Apache + nginx.

- PowerDNS принимает запрос изначально
- если может ответить на него, то отвечает
- а если не может, то отдает unbound для обработки