Задача: запустить сервер для обслуживания DNS-запросов пользовательского сегмента сети с количеством пользователей более пяти-десяти тысяч, основная роль которого будет заключатся в кешировании ответов на запросы, но также он должен уметь отдавать свои сопоставления FQDN/IP для перенаправления трафика к локальным сервисам. Классически для таких задач используется "Bind", но для нашего случая достаточно более молодого, простого и легковесного DNS-сервера "Unbound":
# apt-get install unbound
В процессе инсталляции пакета в систему автоматически добавляется новый пользователь "unbound" от имени которого будет запускаться сервис.
Сервис "Unbound" сам не создаёт журнальный файл при работе, так что подготовим его заранее:
# touch /var/log/unbound.log
# chown unbound:root /var/log/unbound.log
# chown unbound:root /var/log/unbound.log
Интересно, что в отличии от большинства сетевых сервисов, "Unbound" не имеет заготовленной настройки "по умолчанию". Однако в дистрибутивном пакете есть примеры с хорошим комментированием параметров, так что написать конфигурационный файл не трудно:
# mkdir -p /etc/unbound/conf.d
# vi /etc/unbound/unbound.conf
# vi /etc/unbound/unbound.conf
# Блок описания конфигурации DHS-сервера Unbound
server:
# Используемые для управления ресурсы
directory: "/etc/unbound"
pidfile: "/var/run/unbound.pid"
# Имя пользователя, от которого запускается сервис
username: unbound
# Запускаем в несколько потоков (по одному на ядро процессора)
num-threads: 8
# Включаем оптимизацию быстрого перераспределения ресурсов
so-reuseport: yes
# Описываем параметры сетевого подключения, на котором сервис принимает запросы
port: 53
interface: 0.0.0.0
# Опционально указываем, с какого из интерфейсов отвечать на запросы и высылать рекурсивные запросы
#outgoing-interface: 1.2.3.4
# Уточняем перечень протоколов, с которыми работаем
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
# Перечисляем сети, рекурсивные запросы от которых обслуживаются (по умолчанию всё неразрешенное запрещено)
access-control: 127.0.0.0/8 allow
access-control: 10.0.0.0/8 allow # Service LAN
access-control: 172.16.0.0/12 allow # Special LAN
access-control: 192.168.0.0/16 allow # Users LAN
# Скрываем данные о программном обеспечении в ответах на запросы
hide-identity: yes
hide-version: yes
# Уровень детализации журнала событий (0 - только ошибки; 1 - каждый запрос; 3 - детальный разбор)
verbosity: 1
# На период отладки полезно включить детальное журналирование запросов пользователей
log-queries: yes
# Месторасположение файла журнала событий
logfile: "/var/log/unbound.log"
# Использовать в журнале человекопонятный формат метки времени
log-time-ascii: yes
# Предписываем не дублировать сообщения о событиях в системный журнал
use-syslog: no
# Подставляем актуальный перечень корневых DNS-серверов (скачиваем отсюда: "ftp://ftp.internic.net/domain/named.cache")
#root-hints: "/etc/unbound/db.root"
# Перечисляем DNS-серверы, которые будут использоваться в качестве вышестоящих, для обслуживания неописанных явно "локальных" зон
forward-zone:
name: "."
forward-addr: 1.2.3.4 # ns.example.net
forward-addr: 6.7.8.9 # ns2.example.net
forward-addr: 8.8.8.8 # Google Public DNS
forward-addr: 77.88.8.8 # Yandex Public DNS
# Блок описания средства удалённого управления сервисом (отключаем за ненадобностью)
remote-control:
control-enable: no
control-interface: 127.0.0.1
control-port: 8953
# Включаем в конфигурацию файлы с описаниями зон
include: /etc/unbound/conf.d/*.conf
server:
# Используемые для управления ресурсы
directory: "/etc/unbound"
pidfile: "/var/run/unbound.pid"
# Имя пользователя, от которого запускается сервис
username: unbound
# Запускаем в несколько потоков (по одному на ядро процессора)
num-threads: 8
# Включаем оптимизацию быстрого перераспределения ресурсов
so-reuseport: yes
# Описываем параметры сетевого подключения, на котором сервис принимает запросы
port: 53
interface: 0.0.0.0
# Опционально указываем, с какого из интерфейсов отвечать на запросы и высылать рекурсивные запросы
#outgoing-interface: 1.2.3.4
# Уточняем перечень протоколов, с которыми работаем
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
# Перечисляем сети, рекурсивные запросы от которых обслуживаются (по умолчанию всё неразрешенное запрещено)
access-control: 127.0.0.0/8 allow
access-control: 10.0.0.0/8 allow # Service LAN
access-control: 172.16.0.0/12 allow # Special LAN
access-control: 192.168.0.0/16 allow # Users LAN
# Скрываем данные о программном обеспечении в ответах на запросы
hide-identity: yes
hide-version: yes
# Уровень детализации журнала событий (0 - только ошибки; 1 - каждый запрос; 3 - детальный разбор)
verbosity: 1
# На период отладки полезно включить детальное журналирование запросов пользователей
log-queries: yes
# Месторасположение файла журнала событий
logfile: "/var/log/unbound.log"
# Использовать в журнале человекопонятный формат метки времени
log-time-ascii: yes
# Предписываем не дублировать сообщения о событиях в системный журнал
use-syslog: no
# Подставляем актуальный перечень корневых DNS-серверов (скачиваем отсюда: "ftp://ftp.internic.net/domain/named.cache")
#root-hints: "/etc/unbound/db.root"
# Перечисляем DNS-серверы, которые будут использоваться в качестве вышестоящих, для обслуживания неописанных явно "локальных" зон
forward-zone:
name: "."
forward-addr: 1.2.3.4 # ns.example.net
forward-addr: 6.7.8.9 # ns2.example.net
forward-addr: 8.8.8.8 # Google Public DNS
forward-addr: 77.88.8.8 # Yandex Public DNS
# Блок описания средства удалённого управления сервисом (отключаем за ненадобностью)
remote-control:
control-enable: no
control-interface: 127.0.0.1
control-port: 8953
# Включаем в конфигурацию файлы с описаниями зон
include: /etc/unbound/conf.d/*.conf
Обращаю внимание на то, что подключаемом конфигурационном файла аналогично основному обязательно нужно указать область применения параметров (разумно, но запросто может быть упущено, если исходить из предположения, что в конфигурацию включается не уже разобранный блок параметров, а кусок текста, который ещё предстоит "распарсить" в последовательно формируемом массиве данных):
# vi /etc/unbound/conf.d/additional.conf
# Обязательный указатель на область применения параметров
server:
....
server:
....
Приятно, что у сервиса имеется удобный инструмент проверки корректности конфигурации:
# unbound-checkconf -f /etc/unbound/unbound.conf
unbound-checkconf: no errors in /etc/unbound/unbound.conf
Убедившись, что в конфигурации не обнаружено ошибок, стартуем сервис:
# /etc/init.d/unbound start
Элементарная проверка успешности запуска:
# netstat -apn | grep :53 | grep -i unbound
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 2500/unbound
udp 0 0 0.0.0.0:53 0.0.0.0:* 2500/unbound
udp 0 0 0.0.0.0:53 0.0.0.0:* 2500/unbound
Применение изменённых настроек не требует перезапуска сервиса - достаточно отдать команду перезагрузить конфигурацию:
# unbound-control reload
Перезагрузка конфигурации сервиса работающего в роли только кеширующего происходит мгновенно. В случае, если "Unbound" обслуживает ещё и локальные сопоставления FQDN/IP, то скорость загрузки может снизится, но настолько несущественно, что и говорить порой не о чем. Например у меня на файле описания 40000 (сорока тысяч) "local-zone" сервис задумывается менее чем на секунду. Кому и этот период простоя недопустим, в руки утилиту "unbound-control", предоставляющую возможности по управлению (включая добавление и удаление записей описания "зон" и "хостов") сервисом без его остановки.
Для порядка защищаем настройку от посторонних:
# chown -R root:unbound /etc/unbound
# chmod -R ug+rw /etc/unbound
# chmod -R o-rwx /etc/unbound
# chmod -R ug+rw /etc/unbound
# chmod -R o-rwx /etc/unbound
Как я упоминал ранее, "Unbound" сам себе файл журналирования событий не создаёт. Естественно, что настроек ротации такового тоже нет. Исправляем недочёт:
# vim /etc/logrotate.d/unbound
/var/log/unbound.log {
weekly
rotate 7
size 100M
missingok
notifempty
compress
delaycompress
copytruncate
su root root
}
weekly
rotate 7
size 100M
missingok
notifempty
compress
delaycompress
copytruncate
su root root
}
Проверяем корректность настроек ротации (реальных действий при этом не производится):
# logrotate -d /etc/logrotate.d/unbound
На этом настройка сервиса в рамках функционала обслуживания рекурсивных запросов и кеширования таковых полностью завершена. Имеются довольно богатые возможности "тюнинга" в сторону экономии ресурсов в условиях нагрузки от сотен тысяч конкурентных подключений, но мои несколько тысяч клиентов создают настолько мизерную нагрузку на несущий сервер, что её даже мониторить толком не получается - утилизация CPU, RAM и DiskIO выше одного процента редко поднимается.
P.S. DNS-сервер "Unbound" уже года три как пришёл на смену BIND9 в дистрибутивах "Open/FreeBSD", так что наверное это как минимум неплохой продукт, справляющийся со своими задачами. У меня он уже несколько месяцев обслуживает тысячи клиентов настолько хорошо, что о существовании сервиса понемногу забывается.
