Unbound (Русский)

Состояние перевода:
На этой странице представлен перевод статьи
Unbound
. Дата последней синхронизации: 4 августа 2021. Вы можете
помочь
синхронизировать перевод, если в английской версии произошли
изменения
.
Ссылки по теме
Domain name resolution (Русский)
Unbound
это удостоверяющий, рекурсивный и кеширующий DNS сервер. Согласно
Википедии
:
Unbound вытеснил Berkeley Internet Name Domain (
BIND
) став стандартом как именной сервер в множестве open source проектах, в которых рассматриваются такие преимущества как маленький размер, современность и безопасность.
Установка
Установите
пакет
unbound
.
Дополнительно, пакет
expat
требуется для
#Проверка достоверности DNSSEC
.
Настройка
Стандартные настройки уже находятся в файле
/etc/unbound/unbound.conf
. Следующие разделы освещают различные настройки для файла конфигурации. Подробности и другие настройки смотреть в
unbound.conf(5)
.
Если не указано другое, все нижеописанные опции находятся в секции
server
конфигурационного файла таким образом:
/etc/unbound/unbound.conf
server:
  ...
setting
:
value
...
Локальный DNS сервер
Если вы хотите использовать
unbound
как ваш локальный DNS сервер, установите в строке
nameserver
loopback адреса
127.0.0.1
и
::1
:
/etc/resolv.conf
nameserver ::1
nameserver 127.0.0.1
options trust-ad
Удостоверьтесь, что файл
/etc/resolv.conf
защищен от записи как описано в
Domain name resolution (Русский)#Перезапись файла /etc/resolv.conf
.
Совет
Простейший способ сделать это, установить
Openresolv (Русский)
и настроить
/etc/resolvconf.conf
данным образом:
/etc/resolvconf.conf
name_servers="::1 127.0.0.1"
resolv_conf_options="trust-ad"
Затем выполнить
resolvconf -u
чтобы сгенерировать
/etc/resolv.conf
.
Просмотрите
Domain name resolution (Русский)#Утилиты
для различных способов проверить ваши настройки
При проверке, удостоверьтесь, что используемый сервер имеет адрес
127.0.0.1
или
::1
после применения изменений в
resolv.conf
.
В разделе
#Переадресация запросов
вы можете настроить
unbound
для переадресации запросов к нужным DNS серверам, если требуется.
Корневые подсказки (Root hints)
Для рекурсивных запросов хоста который не имеет требуемого адреса в кеше, вашему DNS серверу нужно знать адреса корневых DNS серверов, у которых он будет запрашивать адреса DNS серверов доменов верхнего уровня и далее по цепочке, пока не будет достигнут именной сервер, обслуживающий запрашиваемый домен. Для этого требуются корневые подсказки (Root hints), файл содержащий в себе IP адреса корневых DNS серверов. Unbound имеет встроенные корневые подсказки, и если он обновляется регулярно, вмешательства не требуется. С другой стороны хорошей практикой является самостоятельное сопровождение корневых подсказок, так как встроенные могут потерять актуальность.
Для начала укажите
unbound
путь к файлу
root.hints
:
root-hints: root.hints
Затем, поместите файл
root.hints
в директорию
unbound
. Простой способ сделать это можно этой командой:
# curl --output /etc/unbound/root.hints https://www.internic.net/domain/named.cache
Если вы все таки используете этот файл вместо встроенных корневых подсказок, для поддержания актуальности нужно обновлять
root.hints
как минимум раз в шесть месяцев. Вы можете делать это вручную или используя
Systemd/Timers
. Смотрите пример файла службы в разделе
#Служба systemd для обновления корневых подсказок
.
Проверка достоверности DNSSEC
Для того, чтобы проверять достоверность домена с помощью
DNSSEC
, в файле конфигурации требуется указать путь файла trust anchor:
/etc/unbound/unbound.conf
trust-anchor-file: trusted-key.key
Эта опция включена по умолчанию.
/etc/unbound/trusted-key.key
копируется  из файла
/etc/trusted-key.key
, предоставленного зависимостью
dnssec-anchors
, которой
PKGBUILD (Русский)
генерирует этот файл, подробнее
unbound-anchor(8)
.
Проверка достоверности DNSSEC будет выполнятся только если запрашиваемый DNS сервер поддерживает эту технологию. Если в
#Переадресация запросов
были указаны сервера, не поддерживающие DNSSEC, все их ответы на запросы будут рассматриваться как небезопасные, так как невозможно доказать обратное.
Примечание
Проверка DNSSEC увеличивает задержку DNS запросов, которые еще не были кешированы.
Тестирование работоспособности
Для проверки работоспособности DNSSEC, после запуска службы
unbound.service
выполните:
$ unbound-host -C /etc/unbound/unbound.conf -v sigok.verteiltesysteme.net
В ответе должен быть IP адрес и
(secure)
после него.
$ unbound-host -C /etc/unbound/unbound.conf -v sigfail.verteiltesysteme.net
Этот ответ должен содержать
(BOGUS (security failure))
.
Так же вы можете использовать
drill
для проверки вашего сервера следующими командами:
$ drill sigfail.verteiltesysteme.net
$ drill sigok.verteiltesysteme.net
Первая команда должна в переменной
rcode
выдать
SERVFAIL
. Вторая команда должна выдать
NOERROR
.
Переадресация запросов
Если вам необходимо только перенаправлять DNS запросы на внешний DNS сервер, можете сразу перейти к
#Переадресация остальных запросов
.
Доступ локальной сети к DNS
Используя openresolv
Если ваш сетевой менеджер поддерживает
Openresolv (Русский)
, вы можете
настроить его
для предоставления доступа локальных DNS серверов и доменов к Unbound:
/etc/resolvconf.conf
...
private_interfaces="*"

# Путь к конфигурационному файлу для Unbound
unbound_conf=/etc/unbound/resolvconf.conf
Выполните
resolvconf -u
для внесения изменений.
Настройте
Unbound
для чтения файла, сгенерированного openresolv и разрешите содержать в ответных сообщениях
диапазоны частных IP-адресов
[1]
:
/etc/unbound/unbound.conf
include: "/etc/unbound/resolvconf.conf"
...
server:
...
	private-domain: "intranet"
	private-domain: "internal"
	private-domain: "private"
	private-domain: "corp"
	private-domain: "home"
	private-domain: "lan"

	unblock-lan-zones: yes
	insecure-lan-zones: yes
...
Вы также можете выключить проверку достоверности DNSSEC для локальных доменов, так как они не могут подтвердить свою достоверность (подробнее
RFC 6762 Appendix G
):
/etc/unbound/unbound.conf
...
server:
...
	domain-insecure: "intranet"
	domain-insecure: "internal"
	domain-insecure: "private"
	domain-insecure: "corp"
	domain-insecure: "home"
	domain-insecure: "lan"
...
Исключение приватных диапазонов IP адресов из ответов
Будет полезным исключить из ответов DNS сервера адреса из
диапазонов частных IP-адресов
, так как это защитит от уязвимости
перепривязывания DNS
. По умолчанию данная функция не включена, что бы добавить нужную подсеть в список исключения из ответа DNS сервера используйте данный шаблон:
private-address:
локальная_подсеть/маска_подсети
Вы можете добавить эти строки в ваш конфигурационный файл для исключения всего диапазона частных адресов:
private-address:  10.0.0.0/8
private-address:  172.16.0.0/12
private-address:  192.168.0.0/16
private-address:  169.254.0.0/16
private-address:  fd00::/8
private-address:  fe80::/10
Примечание
Блокирование подсети 127.0.0.0/8 может вызвать неполадки в работе приложений, например которые блокируют спам и рекламу. Блокирование подсети ::ffff:0:0/96 не позволяет правильно интерпретировать IPv4 адреса в нотации IPv6.
Стоит заметить, что блокированные с помощью параметра
private-address
адреса все еще можно получить в ответах от DNS сервера, если они принадлежат доменам из
private-domain
, либо содержаться в
local-data
. Поэтому для работоспособности запросов локальных доменов настройте Unbound как указано этом разделе
#Используя openresolv
.
Добавить локальный DNS сервер
Для использования локального DNS сервер для прямого и обратного поиска локальных адресов добавьте нужные зоны как показано ниже (выберите нужный IP адрес DNS сервера локальной сети вместо адреса 10.0.0.1 указанного ниже):
local-zone: "10.in-addr.arpa." transparent
Данные строки необходима для работы обратного поиска.
forward-zone:
name: "mynetwork.com."
forward-addr: 10.0.0.1
forward-zone:
name: "10.in-addr.arpa."
forward-addr: 10.0.0.1
Примечание
В отличии от зон переадресации (forward-zone), зоны заглушки(stub-zone) будут работать только если они указывают на авторитетный сервер напрямую. Например на
BIND
сервер если он настроен как авторитетный, но если вы укажите для зоны заглушки, например
unbound
сервер который переадресует локальные запросы на другой DNS сервер, то работать это не будет и самое главное вы не получите никаких ошибок.
Вы так же можете добавить localhost для переадресации и обратного поиска с помощью следующих строк:
local-zone: "localhost." static
local-data: "localhost. 10800 IN NS localhost."
local-data: "localhost. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"
local-data: "localhost. 10800 IN A 127.0.0.1"
local-zone: "127.in-addr.arpa." static
local-data: "127.in-addr.arpa. 10800 IN NS localhost."
local-data: "127.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 2 3600 1200 604800 10800"
local-data: "1.0.0.127.in-addr.arpa. 10800 IN PTR localhost."
Переадресация остальных запросов
Используя openresolv
Если ваш сетевой менеджер поддерживает
Openresolv (Русский)
, вы можете
настроить его
для предоставления внешних DNS серверов для Unbound:
/etc/resolvconf.conf
...
# Путь к конфигурационному файлу для Unbound
unbound_conf=/etc/unbound/resolvconf.conf
Выполните
resolvconf -u
для внесения изменений.
Затем настройте Unbound для чтения сгенерированного openresolv файла
[2]
:
include: "/etc/unbound/resolvconf.conf"
Ручное указание DNS серверов
Для использования серверов для стандартных зон переадресации, которые находятся за пределами локальной машины и сети, добавьте зону переадресации с именем
.
в ваш конфигурационный файл. В этом примере все запросы переадресуются на DNS сервера Google:
forward-zone:
  name: "."
  forward-addr: 8.8.8.8
  forward-addr: 8.8.4.4
Переадресация через DNS over TLS
Для использования
DNS over TLS
необходимо указать параметру
tls-cert-bundle
путь до системного корневого набора сертификатов, что позволит Unbound переадресовывать TLS запросы и использовать сервера с технологией DNS over TLS .
Для каждого сервера нужно указать используемый порт с помощью символа @ и требуется указать домен через символ #. Несмотря на то, что домен выглядит как комментарий, это позволяет имени TLS аутентификации быть использованным для зон заглушек (stub-zones) и командой
unbound-control forward control
. Удостоверьтесь в отсутствии пробелов до и после символов @ и #.
/etc/unbound/unbound.conf
...
server:
...
	tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
...
forward-zone:
        name: "."
        forward-tls-upstream: yes
        forward-addr: 1.1.1.1@853#cloudflare-dns.com
Контроль доступа
Вы можете указать интерфейсы, на которые будет отвечать сервер с помощью IP адреса. По умолчанию принимает запросы только от
localhost
.
Для прослушивания всех интерфейсов, используйте следующую строку:
interface: 0.0.0.0
Для определения доступа к серверу определенным IP адресам используйте опцию
access-control
:
access-control:
подсеть
действие
Например:
access-control: 192.168.1.0/24 allow
действие
может быть одним из:
deny
(игнорирует запросы),
refuse
(отвечает ошибкой),
allow
(разрешает рекурсивные запросы),
allow_snoop
(разрешает рекурсивные и остальные запросы) По умолчанию игнорируются все запросы, кроме от localhost.
Использование
Запуск Unbound
Запустите
и
включите
службу
unbound.service
.
Удаленное управление Unbound
В составе
unbound
присутствует утилита
unbound-control
которая позволяет удаленно контролировать сервер unbound. Команды схожи с
pdnsd-ctl
пакета
pdnsd
.
Настройка unbound-control
Перед тем, как начать, необходимо выполнить следующие шаги:
1) Для начала выполните следующую команду
# unbound-control-setup
которая сгенерирует пару самоподписанных сертификатов и ключей для сервера и клиента. Они будут находится в директории
/etc/unbound
.
2) После, отредактируйте
/etc/unbound/unbound.conf
используя следующий пример. Опция
control-enable: yes
обязательная, остальное можете настроить как необходимо вам.
remote-control:
    # Включает удаленный доступ с помощью unbound-control(8).
    # настройте ключи и сертификаты с помощью команды unbound-control-setup.
    control-enable: yes

    # Интерфейс, с которого будет происходить управление
    # задайте 0.0.0.0 и ::0 для прослушивания всех интерфейсов.
    control-interface: 127.0.0.1

    # номер порта для удаленного доступа.
    control-port: 8953

    # ключ unbound сервера.
    server-key-file: "/etc/unbound/unbound_server.key"

    # сертификат unbound сервера.
    server-cert-file: "/etc/unbound/unbound_server.pem"

    # ключ для unbound-control.
    control-key-file: "/etc/unbound/unbound_control.key"

    # сертификат для unbound-control.
    control-cert-file: "/etc/unbound/unbound_control.pem"
Использование unbound-control
Список команд, которые вы можете использовать для
unbound-control
:
выводит статистику не сбрасывая ее
# unbound-control stats_noreset
выводит кеш в стандартный вывод
# unbound-control dump_cache
Очищает кеш и перезагружает настройки
# unbound-control reload
Обратитесь к
unbound-control(8)
для подробностей и поддерживаемых команд.
Советы и приёмы
Черный список доменов
Для добавления домена в черный список, используйте строку
local-zone: "
домен
" always_refuse
.
Сохраните черный список как отдельный файл (например
/etc/unbound/blacklist.conf
) для удобности и включите его в файл конфигурации
/etc/unbound/unbound.conf
, например:
/etc/unbound/blacklist.conf
local-zone: "blacklisted.example" always_refuse
local-zone: "anotherblacklisted.example" always_refuse
/etc/unbound/unbound.conf
server:
...
  include: /etc/unbound/blacklist.conf
Совет
Если вы хотите возвращать статус OK на определенные имена, вы можете поменять переадресацию с 127.0.0.1 на ваш HTTP сервер который будет отвечать пустым ответом 204, подробнее
здесь
.
Для конвертации стороннего hosts файла в формат unbound, воспользуйтесь следующей командой:
$ grep '^0\.0\.0\.0'
путь_к_hosts_файлу
| awk '{print "local-zone: \""$2"\" always_refuse"}' > /etc/unbound/blacklist.conf
Список источников для черного списка можно взять со
страницы пакета adblock для OpenWrt
.
Использование вместе с авторитетный DNS сервером
Важно
Использование двух DNS серверов вместо одного по своей сути не делает систему более безопасной, как описано ниже. Это тема для спора о безопасности использования определенных приложений (в частности BIND) и решений (использующих BIND) затронутых в этом разделе.
Для пользователей, которые желают иметь подтверждающий, рекурсивный и кеширующий DNS сервер вместе с авторитетным на одной машине, может быть полезно обратиться к странице
NSD
в которой описан пример такой конфигурации. Наличие одного сервера как авторитетный и отдельного для выполнения подтверждения, рекурсии и кеширования повышает уровень безопасности по отношению к единому DNS серверу выполняющему эти функции. Многие пользователи используют Bind в этом случае как единый DNS сервер, и пример для миграции на комбинацию Bind и NDS серверов предоставлен на странице
NSD
.
Доступ к DNS серверу через WAN интерфейс
Вы можете поменять настройки и прослушиваемые интерфейсы для нужного сервера, чтобы машины за пределами локальной сети могли получить доступ к определенным машинам внутри локальной сети. Это будет полезно для различных веб-сервисов которым нужен доступ извне. Похожий способ использовался с помощью сервера bind в комбинации с использованием перенаправления портов на машинах принимающих запросы для переадресации запросов на нужные машины.
Служба systemd для обновления корневых подсказок
Можете использовать эти примеры для создания systemd службы которая будет обновлять
root.hints
ежемесячно методом, описанным в разделе
#Корневые подсказки (Root hints)
:
/etc/systemd/system/roothints.service
[Unit]
Description=Update root hints for unbound
After=network.target

[Service]
ExecStart=/usr/bin/curl -o /etc/unbound/root.hints https://www.internic.net/domain/named.cache
/etc/systemd/system/roothints.timer
[Unit]
Description=Run root.hints monthly

[Timer]
OnCalendar=monthly
Persistent=true

[Install]
WantedBy=timers.target
Запустите
и
включите
службу
roothints.timer
.
Решение проблем
Определение нужного количества потоков (num-threads)
В странице man руководства для
unbound.conf
говорится:
outgoing-range: <кол-во>
       Количество портов для работы. Это число файлов-дескрипторов которые могут быть использованы на один поток.
и другие источники предполагают, что параметр
num-threads
должен быть равен количеству ядер процессора. Пример конфигурации в {ic|unbound.conf.example}} имеет:
# количество потоков для использования. 1 отключает многопоточность.
       # num-threads: 1
Тем не менее невозможно установить количество потоков больше
1
в строке
num-threads
без вызывания предупреждений в логах от
unbound
о превышении количества файлов-дескрипторов. На самом деле для пользователей, использующих
unbound
для небольших сетей или на одной системе, нет необходимости стремится к увеличению производительности путем включения многопоточности параметром
num-threads
. Но если вы все таки желаете это сделать, рекомендуется обратиться к
официальной документации
и выбрать подходящие параметры:
Установите
num-threads
равное количеству ядер процессора в вашей системе. Например для систем с 4 физическими ядрами поддерживающих гиперпоточность (hyper-threading) используйте 8.
Установите параметр
outgoing-range
насколько можно большим, смотрите упомянутую выше страницу каким можно преодолеть лимит в
1024
. Это позволяет обслуживать большее количество клиентов в единицу времени. Для одного ядра попробуйте
950
, для двух
450
, для четырех
200
. Параметр
num-queries-per-thread
лучше всего установить в половину от велечины
outgoing-range
.
Потому как ограничение
outgoing-range
также ограничивает
num-queries-per-thread
, лучше всего использовать
unbound
вместе с библиотекой
libevent
, тогда не будет ограничения в
1024
параметра
outgoing-range
. Если вам нужен DNS сервер для большой нагрузки, вам потребуется скомпилировать собственный экземпляр, вместо использования
unbound
из репозиториев.
Смотреть также
Списки блокировки рекламных адресов для Unbound