Dns unbound что это
Обновлено: 02.05.2024
Unbound - это очень безопасный, рекурсивный и кэширующий DNS-сервер, разработанный в первую очередь NLnet Labs, VeriSign Inc, Nominet и Kirei. Программное обеспечение распространяется бесплатно по лицензии BSD. Двоичные файлы написаны с высокой степенью защиты на языке C и настроением на то, что он всегда находится под атакой, или удаленные серверы всегда пытаются передать ему недостоверную информацию.
Проект Unbound представляет собой набор модульных компонентов, которые включают в себя такие функции, как набор расширений безопасности протокола DNS (DNSSEC), интернет-протокол версии 6 (IPv6) и API библиотеки распознавателя клиентов как неотъемлемая часть архитектуры.
Что касается конфигурации, простой кеширующий DNS-сервер, который можно использовать в локальной сети с одним или несколькими компьютерами, занимает всего несколько строк. Обратите внимание, что Unbound не является полноценным авторитетным сервером, но вы можете поместить в A записи для прямого и обратного разрешения небольшой частной локальной сети.
В будущем ожидается, что многие, если не все, другие дистрибутивы с открытым исходным кодом перейдут на Unbound. FreeBSD 10 уже внесла изменения, так как BIND больше не включен в установку по умолчанию. BIND, также известный как named, становится чрезвычайно раздутым, медленным и чрезмерно сложным. Сложность приводит к уязвимостям безопасности, и более двадцати (20) из последних семидесяти (70) критических ошибок во FreeBSD были найдены в самом BIND. Другая проблема заключается в том, что BIND используется около 70% мировых DNS-серверов, что ведет к монокультурной среде. Когда появляется атака или эксплойт, злоумышленнику выгодно использовать наиболее используемое программное обеспечение. В отличие от этого, Unbound является невероятно быстрым и безопасным DNS-сервером, благодаря небольшому размеру которого может быть легко выполнен аудит исходного кода для обеспечения безопасности.
[edit] Простое рекурсивное кеширование DNS, UDP-порт 53 в незашифрованном виде
Contents
[edit] DNS через TLS
[edit] Полезные команды
Вывод этой полезной утилиты от BusyBox покажет, какой DNS вы используете.
Установка
Unbound (Русский)
Unbound это удостоверяющий, рекурсивный и кеширующий DNS сервер. Согласно Википедии:
Unbound вытеснил Berkeley Internet Name Domain (BIND) став стандартом как именной сервер в множестве open source проектах, в которых рассматриваются такие преимущества как маленький размер, современность и безопасность.
[edit] Пользовательская конфигурация
Начиная с версий сервера r30220 и r36376 можно использовать пользовательские конфигурации с хранилища USB. Таким образом, вы можете объединить несколько функций вместе на одном DNS-сервере. Например, у вас может быть кеширующий DNS, рекурсивный кеширующий DNS, проверяющий рекурсивный кеширующий DNS, авторитетный проверяющий рекурсивный кеширующий DNS, DNS Over TLS, простой рекурсивный кеширующий DNS, TCP-порт 853 ENCRYPTED и т.д.
Использование
Запуск Unbound
Запустите и включите службу unbound.service .
Удаленное управление Unbound
В составе unbound присутствует утилита unbound-control которая позволяет удаленно контролировать сервер unbound. Команды схожи с pdnsd-ctl пакета pdnsd .
Настройка unbound-control
Перед тем, как начать, необходимо выполнить следующие шаги:
1) Для начала выполните следующую команду
которая сгенерирует пару самоподписанных сертификатов и ключей для сервера и клиента. Они будут находится в директории /etc/unbound .
2) После, отредактируйте /etc/unbound/unbound.conf используя следующий пример. Опция control-enable: yes обязательная, остальное можете настроить как необходимо вам.
Использование unbound-control
Список команд, которые вы можете использовать для unbound-control:
- выводит статистику не сбрасывая ее
- выводит кеш в стандартный вывод
- Очищает кеш и перезагружает настройки
Обратитесь к unbound-control(8) для подробностей и поддерживаемых команд.
Настройка
Стандартные настройки уже находятся в файле /etc/unbound/unbound.conf . Следующие разделы освещают различные настройки для файла конфигурации. Подробности и другие настройки смотреть в unbound.conf(5) .
Если не указано другое, все нижеописанные опции находятся в секции server конфигурационного файла таким образом:
Локальный DNS сервер
Если вы хотите использовать unbound как ваш локальный DNS сервер, установите в строке nameserver loopback адреса 127.0.0.1 и ::1 :
Совет: Простейший способ сделать это, установить Openresolv (Русский) и настроить /etc/resolvconf.conf данным образом:Затем выполнить resolvconf -u чтобы сгенерировать /etc/resolv.conf .
При проверке, удостоверьтесь, что используемый сервер имеет адрес 127.0.0.1 или ::1 после применения изменений в resolv.conf.
Корневые подсказки (Root hints)
Для рекурсивных запросов хоста который не имеет требуемого адреса в кеше, вашему DNS серверу нужно знать адреса корневых DNS серверов, у которых он будет запрашивать адреса DNS серверов доменов верхнего уровня и далее по цепочке, пока не будет достигнут именной сервер, обслуживающий запрашиваемый домен. Для этого требуются корневые подсказки (Root hints), файл содержащий в себе IP адреса корневых DNS серверов. Unbound имеет встроенные корневые подсказки, и если он обновляется регулярно, вмешательства не требуется. С другой стороны хорошей практикой является самостоятельное сопровождение корневых подсказок, так как встроенные могут потерять актуальность.
Для начала укажите unbound путь к файлу root.hints :
Затем, поместите файл root.hints в директорию unbound. Простой способ сделать это можно этой командой:
Проверка достоверности DNSSEC
Для того, чтобы проверять достоверность домена с помощью DNSSEC, в файле конфигурации требуется указать путь файла trust anchor:
Эта опция включена по умолчанию[1]. /etc/unbound/trusted-key.key копируется из файла /etc/trusted-key.key , предоставленного зависимостью dnssec-anchors , которой PKGBUILD (Русский) генерирует этот файл, подробнее unbound-anchor(8) .
Примечание: Проверка DNSSEC увеличивает задержку DNS запросов, которые еще не были кешированы.Тестирование работоспособности
Для проверки работоспособности DNSSEC, после запуска службы unbound.service выполните:
В ответе должен быть IP адрес и (secure) после него.
Этот ответ должен содержать (BOGUS (security failure)) .
Так же вы можете использовать drill для проверки вашего сервера следующими командами:
Первая команда должна в переменной rcode выдать SERVFAIL . Вторая команда должна выдать NOERROR .
Переадресация запросов
Доступ локальной сети к DNS
Используя openresolv
Если ваш сетевой менеджер поддерживает Openresolv (Русский), вы можете настроить его для предоставления доступа локальных DNS серверов и доменов к Unbound:
Выполните resolvconf -u для внесения изменений.
Вы также можете выключить проверку достоверности DNSSEC для локальных доменов, так как они не могут подтвердить свою достоверность (подробнее RFC 6762 Appendix G):
Вы можете добавить эти строки в ваш конфигурационный файл для исключения всего диапазона частных адресов:
Добавить локальный DNS сервер
Для использования локального DNS сервер для прямого и обратного поиска локальных адресов добавьте нужные зоны как показано ниже (выберите нужный IP адрес DNS сервера локальной сети вместо адреса 10.0.0.1 указанного ниже):
Данные строки необходима для работы обратного поиска.
Примечание: В отличии от зон переадресации (forward-zone), зоны заглушки(stub-zone) будут работать только если они указывают на авторитетный сервер напрямую. Например на BIND сервер если он настроен как авторитетный, но если вы укажите для зоны заглушки, например unbound сервер который переадресует локальные запросы на другой DNS сервер, то работать это не будет и самое главное вы не получите никаких ошибок.Вы так же можете добавить localhost для переадресации и обратного поиска с помощью следующих строк:
Переадресация остальных запросов
Используя openresolv
Если ваш сетевой менеджер поддерживает Openresolv (Русский), вы можете настроить его для предоставления внешних DNS серверов для Unbound:
Выполните resolvconf -u для внесения изменений.
Затем настройте Unbound для чтения сгенерированного openresolv файла[3]:
Ручное указание DNS серверов
Для использования серверов для стандартных зон переадресации, которые находятся за пределами локальной машины и сети, добавьте зону переадресации с именем . в ваш конфигурационный файл. В этом примере все запросы переадресуются на DNS сервера Google:
Переадресация через DNS over TLS
Для использования DNS over TLS необходимо указать параметру tls-cert-bundle путь до системного корневого набора сертификатов, что позволит Unbound переадресовывать TLS запросы и использовать сервера с технологией DNS over TLS .
Контроль доступа
Вы можете указать интерфейсы, на которые будет отвечать сервер с помощью IP адреса. По умолчанию принимает запросы только от localhost.
Для прослушивания всех интерфейсов, используйте следующую строку:
Для определения доступа к серверу определенным IP адресам используйте опцию access-control :
действие может быть одним из: deny (игнорирует запросы), refuse (отвечает ошибкой), allow (разрешает рекурсивные запросы), allow_snoop (разрешает рекурсивные и остальные запросы) По умолчанию игнорируются все запросы, кроме от localhost.
[edit] Настройка
Конфигурация по умолчанию хранится в файле /tmp/unbound.conf.
Вы можете проверить, проверяет ли ваш DNS-сервер сигнатуры DNSSEC по этой ссылке.
Вы можете проверить, уязвим ли ваш DNS-сервер к утечкам DNS, вы можете проверить здесь/
Избавляемся от BIND в пользу Unbound на CentOS 6
Если вам нужен кеширующий и рекурсивный DNS сервер, то почему бы не отказаться от надоедливого BIND в пользу легкого и производительного Unbound.
Unbound распространяется под лицензией BSD, поддерживает DNSSEC. В стандартных репозиториях CentOS отсутствует, поэтому будем подключать EPEL.
Имеем клиентскую сетку 192.168.0.0/16, на eth1 поступают запросы, которому присвоен адрес 192.168.0.250.
Удаляем BIND
Подключаем EPEL
Устанавливаем Unbound
Конфигурация сервера
Файл конфигурации Unbound находится по адресу /etc/unbound/unbound.conf. Отправляем его содержимое в корзину:Разбирать файл unbound.conf по кусочкам нет смысла, для этого есть команда man unbound.conf, где каждый может доскональна изучить мануал. Приведу минимальный листинг конфига для нетерпеливых:
server:
verbosity: 0
port: 53
interface: 127.0.0.1
interface: 192.168.0.250
outgoing-interface: 10.0.3.15
access-control: 192.168.0.0/16 allow
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
username: unbound
directory: "/etc/unbound"
logfile: "/var/log/unbound.log"
use-syslog: no
pidfile: "/var/run/unbound/unbound.pid"
hide-version: yes
verbosity: 0 — указывает на уровень ведения логов, в нашем случае это только вывод ошибок.
port: 53 — без комментариев.
interface: 127.0.0.1 — а также строка ниже указывает на каких интерфейсах (точнее ip-адреса этих интерфейсов) слушать 53-й порт. В моем случае это localhost и eth1 подключенный к локальной сети.
outgoing-interface: 10.0.3.15 — ip адрес интерфейса, который подключен к сети Интернет.
access-control: 192.168.0.0/16 allow — указывает адрес сети и статус запросов. В нашем случае разрешены запросы клиентов из сетки 192.168.0.0/16 к нашему DNS серверу.
do-ip4: yes — разрешить запросы по IPv4.
do-ip6: no — запретить запросы по IPv6.
username: unbound — от какого имени пользователя запускается Unbound.
directory: "/etc/unbound" — рабочая директория.
logfile: "/var/log/unbound.log" — файл логов, необходимо создать вручную и выставить владельца указанного в username.
use-syslog: no — не используем syslog, пишем в собственный файл.
pidfile: "/var/run/unbound/unbound.pid" — файл с pid'ом.
hide-version: yes — скрыть версию Unbound от кулхацкеров.
Это минимальный набор опций, необходимый для старта и функционирования Unbound.
Теперь в этом же файле опишем наш локальный домен, добавив PTR-запись и описав зону.
local-zone: "192.in-addr.arpa." static
local-data: "192.in-addr.arpa. 10800 IN NS local.lan."
local-data: "192.in-addr.arpa. 10800 IN SOA local.lan. admin.local.lan. 1 3600 1200 604800 10800"
local-data: "250.0.168.192.in-addr.arpa. 10800 IN PTR local.lan."
local-data: "local.lan. 10800 IN A 192.168.0.250"
Стоит заметить, что в отличии от BIND, в Unbound не нужно описывать зону в файле named.conf, а потом создавать сам файл зоны в /var/named (к примеру в CentOS). Здесь все записывается сразу.
Открываем 53-й tcp/udp порты в файле /etc/sysconfig/iptables
-A INPUT -m state --state NEW -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -p udp -m udp --dport 53 -j ACCEPT
и не забываем перезапустить Iptables.
Стартуем Unbound
Проверяем, слушается ли 53-й порт
Различные аспекты эксплуатации DNS уже неоднократно затрагивались автором в ряде статей опубликованных в рамках блога. При этом, основной акцент всегда делался на повышение безопасности этого ключевого для всего Интернет сервиса.
Отправка DNS-запроса может производится стандартными методами GET и POST. В первом случае запрос трансформируется base64URL-encoded строку, а во-втором — через тело POST-запроса в двоичной форме. При этом при запросе и при ответе DNS используется специальный MIME-тип данных application/dns-message.
Обратите также внимание на заголовок cache-control: в ответе со стороны веб-сервера. В параметре max-age содержится значение TTL для возвращаемой записи DNS (или минимальное значение если возвращается их набор).
Исходя из вышеизложенного, функционирование DoH сервера состоит из нескольких этапов.
Наиболее простым, быстрым и эффективным способом запустить свой собственный DNS-over-HTTPS сервер представляется использование HTTP/2 веб-сервера H2O, о котором автор уже вкратце писал (см. "Высокопроизводительный веб-сервер H2O").
В пользу этого выбора играет тот факт, что весь код собственного DoH сервра может быть полностью реализован средствами интегрированного в сам H2O интерпретатором mruby. Помимо стандартных библиотек, для обмена данными с DNS сервером необходима библиотека (mrbgem) Socket, которая, по счастью, уже включена в текущую девелоперскую версию H2O 2.3.0-beta2 присутствующую в портах FreeBSD. Впрочем, не трудно добавить её и в любую предыдущую версию клонировав репозиторий библиотеки Socket в каталог /deps перед компиляцией.
Конфигурация веб-сервера, в целом, стандартная.
Обратие внимание, что за обработку пакетов DNS отвечает локальный кэширующий сервер, в данном случае Unbound из стандратной поставки FreeBSD. С точки зрения безопасности это оптимальное решение. Впрочем, ничто не мешает заменить localhost на адрес другого DNS, который вы предполагаете использовать.
Отстаётся перезапустить H2O и посмотреть что же из этого получилось.
Советы и приёмы
Черный список доменов
Для добавления домена в черный список, используйте строку local-zone: "домен" always_refuse .
Сохраните черный список как отдельный файл (например /etc/unbound/blacklist.conf ) для удобности и включите его в файл конфигурации /etc/unbound/unbound.conf , например:
Использование вместе с авторитетный DNS сервером
Важно: Использование двух DNS серверов вместо одного по своей сути не делает систему более безопасной, как описано ниже. Это тема для спора о безопасности использования определенных приложений (в частности BIND) и решений (использующих BIND) затронутых в этом разделе.Для пользователей, которые желают иметь подтверждающий, рекурсивный и кеширующий DNS сервер вместе с авторитетным на одной машине, может быть полезно обратиться к странице NSD в которой описан пример такой конфигурации. Наличие одного сервера как авторитетный и отдельного для выполнения подтверждения, рекурсии и кеширования повышает уровень безопасности по отношению к единому DNS серверу выполняющему эти функции. Многие пользователи используют Bind в этом случае как единый DNS сервер, и пример для миграции на комбинацию Bind и NDS серверов предоставлен на странице NSD.
Доступ к DNS серверу через WAN интерфейс
Вы можете поменять настройки и прослушиваемые интерфейсы для нужного сервера, чтобы машины за пределами локальной сети могли получить доступ к определенным машинам внутри локальной сети. Это будет полезно для различных веб-сервисов которым нужен доступ извне. Похожий способ использовался с помощью сервера bind в комбинации с использованием перенаправления портов на машинах принимающих запросы для переадресации запросов на нужные машины.
Служба systemd для обновления корневых подсказок
Запустите и включите службу roothints.timer .
4. Тестирование
Итак, проверим результаты отправив вновь пробный запрос и посмотрев сетевой трафик при помощи утилиты tcpdump.
Теперь осталось активировать наш сервер в браузере Firefox. Для этого на страницы конфигурации следует изменить несколько настроек about:config.
Во-первых, это адрес нашего API по которому браузер будет запрашивать в DNS информацию в network.trr.uri. Рекомендуется также указать IP домена из этого URL для безопасного разрешения в IP средствами самого браузера без обращения к DNS в network.trr.bootstrapAddress. И, наконец, собственно сам параметр network.trr.mode включающий использование DoH. Установка значения в "3" заставит браузер использовать исключительно DNS-over-HTTPS для разрешения имён, а более надёжное и безопасное "2" отдаст приоритет DoH отставив стандартное обращение к DNS в качестве резервного варианта.
5. PROFIT!
Статья была полезной? Тогда прошу не стесняться и поддерживать деньгами через форму доната (ниже).
Решение проблем
Определение нужного количества потоков (num-threads)
В странице man руководства для unbound.conf говорится:
и другие источники предполагают, что параметр num-threads должен быть равен количеству ядер процессора. Пример конфигурации в
Тем не менее невозможно установить количество потоков больше 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 из репозиториев.
Читайте также: