UMGUM.COM 

Unbound ( Установка и базовая настройка легковесного кеширующего сервера рекурсивных DNS-запросов. )

2 октября 2017  (обновлено 4 декабря 2017)

OS: Linux Debian 9 Stretch, Linux Ubuntu 16 LTS.

Задача: запустить сервер для обслуживания DNS-запросов пользовательского сегмента сети с количеством пользователей более пяти-десяти тысяч, основная роль которого будет заключатся в кешировании ответов на запросы, но также он должен уметь отдавать свои сопоставления FQDN/IP для перенаправления трафика к локальным сервисам. Классически для таких задач используется "Bind", но для нашего случая достаточно более молодого, простого и легковесного DNS-сервера "Unbound":


# apt-get install unbound


В процессе инсталляции пакета в систему автоматически добавляется новый пользователь "unbound" от имени которого будет запускаться сервис.

Сервис "Unbound" сам не создаёт журнальный файл при работе, так что подготовим его заранее:

# touch /var/log/unbound.log
# chown unbound:root /var/log/unbound.log

Интересно, что в отличии от большинства сетевых сервисов, "Unbound" не имеет заготовленной настройки "по умолчанию". Однако в дистрибутивном пакете есть примеры с хорошим комментированием параметров, так что написать конфигурационный файл не трудно:

# mkdir -p /etc/unbound/conf.d
# 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

Обращаю внимание на то, что подключаемом конфигурационном файла аналогично основному обязательно нужно указать область применения параметров (разумно, но запросто может быть упущено, если исходить из предположения, что в конфигурацию включается не уже разобранный блок параметров, а кусок текста, который ещё предстоит "распарсить" в последовательно формируемом массиве данных):

# vi /etc/unbound/conf.d/additional.conf

# Обязательный указатель на область применения параметров
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

Применение изменённых настроек не требует перезапуска сервиса - достаточно отдать команду перезагрузить конфигурацию:

# 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

Как я упоминал ранее, "Unbound" сам себе файл журналирования событий не создаёт. Естественно, что настроек ротации такового тоже нет. Исправляем недочёт:

# vim /etc/logrotate.d/unbound

/var/log/unbound.log {
  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", так что наверное это как минимум неплохой продукт, справляющийся со своими задачами. У меня он уже несколько месяцев обслуживает тысячи клиентов настолько хорошо, что о существовании сервиса понемногу забывается.


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )