Unbound (Русский)

From ArchWiki
Jump to navigation Jump to search
Состояние перевода: На этой странице представлен перевод статьи Unbound. Дата последней синхронизации: 4 августа 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Unbound это удостоверяющий, рекурсивный и кеширующий DNS сервер. Согласно Википедии:

Unbound вытеснил Berkeley Internet Name Domain (BIND) став стандартом как именной сервер в множестве open source проектах, в которых рассматриваются такие преимущества как маленький размер, современность и безопасность.

Установка

Установите пакет unbound.

Дополнительно, пакет expat требуется для #DNSSEC validation[ссылка недействительна: раздел не найден].

Настройка

Стандартные настройки уже находятся в файле /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

Эта опция включена по умолчанию[1]. /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-адресов[2]:

/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 файла[3]:

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 из репозиториев.

Смотреть также