Что такое unbound linux

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

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

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

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

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

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

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

# Блок описания конфигурации 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

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

Приятно, что у сервиса имеется удобный инструмент проверки корректности конфигурации:

Убедившись, что в конфигурации не обнаружено ошибок, стартуем сервис:

Элементарная проверка успешности запуска:

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

Перезагрузка конфигурации сервиса работающего в роли только кеширующего происходит мгновенно. В случае, если «Unbound» обслуживает ещё и локальные сопоставления FQDN/IP, то скорость загрузки может снизится, но настолько несущественно, что и говорить порой не о чем. Например у меня на файле описания 40000 (сорока тысяч) «local-zone» сервис задумывается менее чем на секунду. Кому и этот период простоя недопустим, в руки утилиту «unbound-control», предоставляющую возможности по управлению (включая добавление и удаление записей описания «зон» и «хостов») сервисом без его остановки.

Для порядка защищаем настройку от посторонних:

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

Проверяем корректность настроек ротации (реальных действий при этом не производится):

На этом настройка сервиса в рамках функционала обслуживания рекурсивных запросов и кеширования таковых полностью завершена. Имеются довольно богатые возможности «тюнинга» в сторону экономии ресурсов в условиях нагрузки от сотен тысяч конкурентных подключений, но мои несколько тысяч клиентов создают настолько мизерную нагрузку на несущий сервер, что её даже мониторить толком не получается — утилизация CPU, RAM и DiskIO выше одного процента редко поднимается.

P.S. DNS-сервер «Unbound» уже года три как пришёл на смену BIND9 в дистрибутивах «Open/FreeBSD», так что наверное это как минимум неплохой продукт, справляющийся со своими задачами. У меня он уже несколько месяцев обслуживает тысячи клиентов настолько хорошо, что о существовании сервиса понемногу забывается.

[ уже посетило: 11158 / +3 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Источник

Про Debian

Для начала поговорим о том, для чего нужен локальный dns-резолвер. Вообще, полезен он и на сервере, и на вашем ноутбучке (только для разного, пожалуй), а написать эту статью меня вынудил именно новый провайдер (самизнаетепочему).
Локальный резолвер позволяет получать мгновенный ответ от dns (кроме случая, когда мы впервые спрашиваем определенную запись). Резолверы провайдера/хостера бывают перегружены, запрос в них в любом случае занимает какие-то миллисекунды, да и протокол UDP весьма не надежен, если говорить про один конкретный запрос — от этого мы спасаемся резолвером без форвардинга, выигрывая пару миллисекунд на любом обращении к dns. Вкупе с опцией prefetch — ответ всегда будет мнгновенным, потому что unbound будет самостоятельно в фоне (без запросов на резолв от системы) обновлять отдельные записи, когда их ttl в кэше будет подходить к концу.
Защищает локальный резолвер и от того, что провайдер знает и логгирует все записи, которые мы спрашиваем у его dns-сервера. Таким образом провайдер узнаёт, какие именно https-сайты вы посещаете (можно и из заголовка SNI узнать, но не весь софт шлёт этот заголовок). Бывают и хреновые случаи — когда провайдер перехватывает весь dns-трафик с нашего компа/сервера и заворачивает его в свой резолвер (фильтруя и подменяя записи), но от этого спасёт использование форварда в tls-резолвер (в статье будут приведены для примера публичные, но и свой поднять в доверенной сети никто не мешает).
Свой резолвер защищает и от самодурства администраторов чужого — некоторые провайдеры и хостеры выставляют у себя опцию min-ttl большую (тем самым, повышая минимальный ttl в своём кэше, снижая нагрузку — в отдельных упоротых случаях мне встречался min-ttl в 30 дней), подменяют записи, ломают DNSSEC, дропают CAA записи, да много чего делают. Если при этом они не заворачивают весь трафик по 53-му порту во всей сети в свой резолвер — то и от этого защитимся (а если заворачивают — привет, dns over tls).
Ещё один плюс — вы сами контролируете (если не используете forward, или используете forward в свой сервер) сброс кэшей на резолвере. Например, ваши сервера ходят в какое-то API бэкэнда. У вас появилась необходимость переключить запись для этого бэкэнда. Меняем запись в dns, рестартим все резолверы, вуаля — на всех уже новая запись. Очень удобно.
Почему именно unbound. Не буду чего-то придумывать — в unbound опция prefetch появилась давно, а в bind — только в десятой версии (которая до сих пор не доехала до стабильных дистрибутивов в базовых репозиториях). Unbound есть во всех поддерживаемых убунтах и дебианах, не нужно подключать сторонние репозитории. Других причин, в целом, нет.
Для начала ставим пакет с unbound:

# apt-get install unbound

Редактируем файл /etc/unbound/unbound.conf
Полностью он у нас будет выглядеть так:

# эта строчка есть в дефолтном конфиге, оставляем её.
include: «/etc/unbound/unbound.conf.d/*.conf»

# открываем секцию server
server:
# разрешаем подключения только с localhost-а
access-control: 127.0.0.0/8 allow
# слушать внешние интерфейсы смысла тоже нет.
interface: 127.0.0.1
# запись с ttl больше 14400 секунд в кеш записываем с ttl равным 14400
cache-max-ttl: 14400
# запись с ttl меньше 60 секунд записываем в кэш с ttl равным 60 секунду
cache-min-ttl: 60
# Скрываем то, что у нас unbound и его версию.
hide-identity: yes
hide-version: yes
# если в них нет необходимости, то unbound убирает из своего ответа информацию о NS-серверах домена. Чуть увеличивает скорость и уменьшает трафик (если в unbound ходим по сети).
minimal-responses: yes
# Эта опция включает обновление записей в кэше в фоне, ради неё мы всё и затеяли.
prefetch: yes
# снижаем количество информации, которую unbound отправляет на чужие NS в своих исходящих запросах.
qname-minimisation: yes
# unbound будет отдавать записи одного типа (если их несколько, т.н. round-robin) в случайном порядке.
rrset-roundrobin: yes
# приводит все ответы сервера (и записи в кэше) к нижнему регистру
use-caps-for-id: yes
# включает хождение наружу по tcp. Я пытался использовать её совместно с «do-udp no», но без форварда вместе они работать не будут. Но для примера пусть полежит.
do-tcp: yes
# включаем эту опцию, если собираемся форвардить dns через TLS (см.
список серверов ниже)
ssl-upstream: yes

Если нам всё же хочется использовать форвард в другой dns-сервер (при этом стоит понимать, что unbound всё ещё будет делать prefetch для записей в кэше, даже при включенном форварде), то добавляем в конфиг такие буквы (сторонние сервера, само собой, можете указать другие):

Если же вам хочется dns загнать через tls, то добавляем кусок конфига ниже (вместо куска конфига выше, само собой). Все коннекты к этим серверам (а значит, и все записи, которыми вы обмениваетесь) будут зашифрованы. Это ещё не dnscrypt, который вовсе не подвержен MItM, но и не plain-dns, который спуфят все, кому ни лень.
Я привожу рабочий список tls-серверов, но они «чьи-то». Вы скрываете свой dns-трафик от провайдера, но дарите его кому-то ещё, имейте в виду.

После операций с конфигом, само собой, рестартим unbound

# /etc/init.d/unbound restart

Потестируем наш резолвер (если команды host нет — поставьте пакет bind9-host) на записи, которая уже в кеше локально:

# time host debian.pro 127.0.0.1
.
real 0m0,006s
user 0m0,004s
sys 0m0,000s

# time host debian.pro 8.8.8.8
.
real 0m0,090s
user 0m0,004s
sys 0m0,000s

И это — при RTT в 5ms до адреса 8.8.8.8. Экономия — 80мс.
Остаётся самая малость, заставить систему использовать наш резолвер. Для начала выясняем, является ли /etc/resolv.conf симлинком куда-то там:

# file /etc/resolv.conf
/etc/resolv.conf: symbolic link to .

Если видим такую надпись — делаем так:

# unlink /etc/resolv.conf

Тем самым мы запрещаем всяким NetworkManager-ам менять этот файл. Ну а сам файл создаём и приводим к такому виду:

Если беспокоимся о том, что unbound упадёт и резолв сломается, то оставляем резервом другие резолверы:

Если у вас systemd (ubuntu 16+, debian 8+), то resolv.conf нужно «применять» перезапуском сервиса resolvconf:

# service resolvconf restart

Источник

Unbound

Unbound is a validating, recursive, and caching DNS resolver. According to Wikipedia:

Unbound has supplanted the Berkeley Internet Name Domain (BIND) as the default, base-system name server in several open source projects, where it is perceived as smaller, more modern, and more secure for most applications.

Contents

Installation

Additionally, the expat package is required for #DNSSEC validation.

Configuration

A default configuration is already included at /etc/unbound/unbound.conf . The following sections highlight different settings for the configuration file. See unbound.conf(5) for other settings and more details.

Unless otherwise specified, any options listed in this section are to be placed under the server section in the configuration like so:

Local DNS server

If you want to use unbound as your local DNS server, set your nameserver to the loopback addresses ::1 and 127.0.0.1 in /etc/resolv.conf :

Make sure to protect /etc/resolv.conf from modification as described in Domain name resolution#Overwriting of /etc/resolv.conf.

Then run resolvconf -u to generate /etc/resolv.conf .

Check specifically that the server being used is ::1 or 127.0.0.1 after making permanent changes to resolv.conf.

You can now setup unbound such that it is #Forwarding queries, perhaps all queries, to the DNS servers of your choice.

Root hints

For recursively querying a host that is not cached as an address, the resolver needs to start at the top of the server tree and query the root servers, to know where to go for the top level domain for the address being queried. Unbound comes with default builtin hints. Therefore, if the package is updated regularly, no manual intervention is required. Otherwise, it is good practice to use a root-hints file since the builtin hints may become outdated.

First point unbound to the root.hints file:

Then, put a root hints file into the unbound configuration directory. The simplest way to do this is to run the command:

When actually using this file, and not the builtin hints, it is a good idea to update root.hints every six months or so in order to make sure the list of root servers is up to date. This can be done manually or by using Systemd/Timers. See #Roothints systemd timer for an example.

DNSSEC validation

To use DNSSEC validation, the following setting for the server trust anchor should be under server: :

This setting is done by default[1]. /etc/unbound/trusted-key.key is copied from /etc/trusted-key.key , which is provided by the dnssec-anchors dependency, whose PKGBUILD generates the file with unbound-anchor(8) .

DNSSEC validation will only be done if the DNS server being queried supports it. If general #Forwarding queries have been set to DNS servers that do not support DNSSEC, their answers, whatever they are, should be considered insecure since no DNSSEC validation could be preformed.

Testing validation

To test if DNSSEC is working, after starting unbound.service , do:

The response should be the ip address with the word (secure) next to it.

Here the response should include (BOGUS (security failure)) .

Additionally you can use drill to test the resolver as follows:

The first command should give an rcode of SERVFAIL . The second should give an rcode of NOERROR .

Forwarding queries

If you only want to forward queries to an external DNS server, skip ahead to #Forward all remaining requests.

Allow local network to use DNS

Using openresolv

If your network manager supports openresolv, you can configure it to provide local DNS servers and search domains to Unbound:

Run resolvconf -u to generate the file.

Configure Unbound to read the openresolv’s generated file and allow replies with private IP address ranges[2]:

Additionally you may want to disable DNSSEC validation for private DNS namespaces (see RFC 6762 Appendix G):

Exclude local subnets from answers

Will be useful to exclude local networks from DNS answers because it would protect against DNS rebinding attacks. By default this feature is not active but you can add any subnet you want in config file:

You can add all private and link-local subnets by this strings:

Note that Unbound may have adresses from excluded subnets in answers if they belong to domains from private-domain or specifed by local-data , so you need to define private-domain how described at #Using openresolv to able query local domains adresses.

Include local DNS server

To include a local DNS server for both forward and reverse local addresses a set of lines similar to these below is necessary with a forward and reverse lookup (choose the IP address of the server providing DNS for the local network accordingly by changing 10.0.0.1 in the lines below):

This line above is important to get the reverse lookup to work correctly.

You can set up the localhost forward and reverse lookups with the following lines:

Forward all remaining requests

Using openresolv

If your network manager supports openresolv, you can configure it to provide upstream DNS servers to Unbound.

Run resolvconf -u to generate the file.

Finally configure Unbound to read the openresolv’s generated file[3]:

Manually specifying DNS servers

To use specific servers for default forward zones that are outside of the local machine and outside of the local network add a forward zone with the name . to the configuration file. In this example, all requests are forwarded to Google’s DNS servers:

Forwarding using DNS over TLS

To use DNS over TLS, you will need to specify tls-cert-bundle option that points to the local system’s root certificate authority bundle, allow unbound to forward TLS requests and also specify any number of servers that allow DNS over TLS.

For each server you will need to specify that the connection port using @, and you will also need to indicate which is its domain name with #. Even though it looks like an comment the hashtag name allows for the TLS authentication name to be set for stub-zones and with unbound-control forward control command. There should not be any spaces between the @ and # markups.

Access control

You can specify the interfaces to answer queries from by IP address. The default, is to listen on localhost.

To listen on all interfaces, use the following:

To control which systems can access the server by IP address, use the access-control option:

action can be one of deny (drop message), refuse (polite error reply), allow (recursive ok), or allow_snoop (recursive and nonrecursive ok). By default everything is refused except for localhost.

Usage

Starting Unbound

Start/enable the unbound.service systemd service.

Remotely control Unbound

unbound ships with the unbound-control utility which enables us to remotely administer the unbound server. It is similar to the pdnsd-ctl command of pdnsd .

Setting up unbound-control

Before you can start using it, the following steps need to be performed:

1) Firstly, you need to run the following command

which will generate a self-signed certificate and private key for the server, as well as the client. These files will be created in the /etc/unbound directory.

2) After that, edit /etc/unbound/unbound.conf and put the following contents in that. The control-enable: yes option is necessary, the rest can be adjusted as required.

Using unbound-control

Some of the commands that can be used with unbound-control are:

• print statistics without resetting them

• dump cache to stdout

• flush cache and reload configuration

Please refer to unbound-control(8) for a detailed look at the operations it supports.

Tips and tricks

Domain blacklisting

To blacklist a domain, use local-zone: «domainname» always_refuse .

Save the blacklist as a separate file (e.g. /etc/unbound/blacklist.conf ) for ease of management and include it from /etc/unbound/unbound.conf . For example:

Adding an authoritative DNS server

The factual accuracy of this article or section is disputed.

For users who wish to run both a validating, recursive, caching DNS server as well as an authoritative DNS server on a single machine then it may be useful to refer to the wiki page NSD which gives an example of a configuration for such a system. Having one server for authoritative DNS queries and a separate DNS server for the validating, recursive, caching DNS functions gives increased security over a single DNS server providing all of these functions. Many users have used Bind as a single DNS server, and some help on migration from Bind to the combination of running NSD and Bind is provided in the NSD wiki page.

WAN facing DNS

It is also possible to change the configuration files and interfaces on which the server is listening so that DNS queries from machines outside of the local network can access specific machines within the LAN. This is useful for web and mail servers which are accessible from anywhere, and the same techniques can be employed as has been achieved using bind for many years, in combination with suitable port forwarding on firewall machines to forward incoming requests to the right machine.

Roothints systemd timer

Here is an example systemd service and timer that update root.hints monthly using the method in #Root hints:

Start/enable the roothints.timer systemd timer.

Troubleshooting

Issues concerning num-threads

The man page for unbound.conf mentions:

and some sources suggest that the num-threads parameter should be set to the number of cpu cores. The sample unbound.conf.example file merely has:

However it is not possible to arbitrarily increase num-threads above 1 without causing unbound to start with warnings in the logs about exceeding the number of file descriptors. In reality for most users running on small networks or on a single machine it should be unnecessary to seek performance enhancement by increasing num-threads above 1 . If you do wish to do so then refer to official documentation and the following rule of thumb should work:

Set num-threads equal to the number of CPU cores on the system. E.g. for 4 CPUs with 2 cores each, use 8.

Set the outgoing-range to as large a value as possible, see the sections in the referred web page above on how to overcome the limit of 1024 in total. This services more clients at a time. With 1 core, try 950 . With 2 cores, try 450 . With 4 cores try 200 . The num-queries-per-thread is best set at half the number of the outgoing-range .

Because of the limit on outgoing-range thus also limits num-queries-per-thread , it is better to compile with libevent , so that there is no 1024 limit on outgoing-range . If you need to compile this way for a heavy duty DNS server then you will need to compile the programme from source instead of using the unbound package.

Источник