Установка и настройка DNS сервера Unbound


		
		






Использование DNSSEC

Сначала приведу небольшой обзор-введение о самой теме. DNSSEC это инфраструктура для обеспечения контроля за целостностью данных передаваемых в сообщениях протокола DNS. DNSSEC построенна на базе шифрования с открытым ключем и работает примерно по такому же принципу как и SSL - отправитель сообщения имеет возможность подписать его своим закрытым ключем, а получатель проверить правильность передачи имея публичный ключ отправителя.



При использовании DNSSEC на стророне авторитарного DNS сервера (отправителя) происходит хеширование групп записей зоны и "подписивание" хешей с помошью закрытого ключа. Эти дополнительные данные сохраняются в файле зоны в виде записей типа RRSIG. Публичные ключи используемые при подписывании данных так же сохраняются в зоне в виде записей типа  DNSKEY. Сторона-получатель имея в своем распоряжении правильный/надежный публичный ключ отправителя может самостоятельно выполнить проверку полученныйх данных. Авторитарные сервера используют два типа ключей для подписи данных в зонах - это ZSK (Zone Signing Keys) ключи, и KSK (Key Signing Keys) ключи. Подобная схема применяется с целью ускорения процесса проверки подписей валидаторами DNS, так как, следуя рекомендациям, ZSK ключи выберают меньшего размера чем KSK ключи. Для обеспечения безопасности системы администраторы авторитарных серверов производят ротацию ZSK ключей примерно раз в месяц, в то время как KSK ключи (из-за их большей длины, а значит и устойчивости к подбору) меняют реже - примерно раз в год. KSK ключами подписывают ZSK ключи. Для того чтобы кеш сервер/валидатор с поддержкой DNSSEC мог бы произвести проверку полученных данных, ему необходимо сначала убедиться в достоверности KSK ключа, а затем, запросив данные о ZSK ключах непосредственно из записей зоны, провести их валидацию, и уже потом провести валидацию данных зоны подписанных этими ZSK ключами.



В идеале инфраструктура DNSSEC должна быть внедрена начиная с корневых серверов. В таком случае (как и при использование SSL сертификатов), клиенту для поведения проверки правильности данных необходимо иметь в своем распоряжении лишь ограниченное число "корневых" сертификатов которым он верит.



До недавнего времени DNSSEC можно было использовать ограничено. Для того чтобы иметь возможность проверять подписи какой-либо зоны, надо было устанавливать у себя ее публичные ключи - то есть для каждой зоны свой отдельный ключ. Это неприменимо для масштабов интернета. Летом 2010 года на корневых серверах была внедрена поддержка DNSSEC. В данный момент корневая зона подписана, а это значит, что для построения цепи доверия достаточно иметь в распоряжениии только публичный ключ IANA!



Unbound поддерживает использование DNSSEC (а так же инфраструктуры DLV). Для задействования этой возможности надо проделать следующие шаги:



Включение DNSSEC





Надо скачать с сайта IANA( https://data.iana.org/root-anchors/root-anchors.xml ) публичный ключ которым подписана корневая зона. Из файла root-anchors.xml надо извлеч секции


<KeyTag>
19036
</KeyTag>
<Algorithm>
8
</Algorithm>
<DigestType>
2
</DigestType>
<Digest>
49..[тут остальные символы]..B5
</Digest>

и преобразовать их к виду:


. IN DS 19036 8 2 49..[тут остальные символы]..B5

эти данные надо сохранить в файле /usr/local/etc/unbound/root.key



Файл root.key надо сделать доступным для записи процессу unbound:


# chown unbound:wheel /usr/local/etc/unbound/root.key

 



Надо изменит unbound.conf:

module-config: "validator iterator"
auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"

 



И перезапустить Unbound:

# /usr/local/etc/rc.d/unbound restart

 



Замечания

При использовании DNSSEC надо обращать свое внимание на следующие моменты:



Переодически происходит ротация ключа которым подписана корневая зона. Администратор Unbound сервера должен об этом помнить. В состав сервера unbound интегрирована отдельная компонента под названием autotrust. В ее задачи входит автоматизация ротации ключей. Использованная нами ранее директива "auto-trust-anchor-file" как раз активирует autotrust. Если сервер работает беспрерывно то autotrust самостоятельно отследит ротацию ключа и перезапишет файл root.key новыми данными. Если же сервер не работал продолжительное время, то может понадобиться вручную обновить root.key.



Вид root.key на роботающем сервере. Видна работа autotrust - были добавлены дополнительные служебные записи:


cat ./root.key
; autotrust trust anchor file
;;id: . 1
;;last_queried: 1283605654 ;;Sat Sep  4 13:07:34 2010
;;last_success: 1283605654 ;;Sat Sep  4 13:07:34 2010
;;next_probe_time: 1283646085 ;;Sun Sep  5 00:21:25 2010
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.       86400   IN      DNSKEY  257 3 8 AwEAAagA
IKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2
MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/Q
Zxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9
dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6
DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25A
sRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+
Uk1ihz0= ;{id = 19036 (ksk), size = 2048b} 
;;state=2 [  VALID  ] ;;count=0 
;;lastchange=1283605654 ;;Sat Sep  4 13:07:34 2010

 



IP/UDP пакеты протокола DNS с данными DNSSEC могут достигать больших размеров, в следствии чего, при прохождении через интернет они будут фрагментироваться. Если где-нибудь используется фаервол который неадекватно обрабатывает большие фрагментированные пакеты, то могут начаться проблемы. Например при использовании keep-state правил в ipfw из FreeBSD 7.2  и ниже. Такая конфигурация ipfw не работает:

add check-state
add allow icmp from me to any out keep-state
add allow tcp from me to any out keep-state
add allow udp from me to any out keep-state
add deny ip from any to any

Для решения этой проблемы можно либо разрешить прохождение через фаервол фрагментов IP пакетов перед keep-state правилами:

allow ip from any to me frag
add check-state
add allow icmp from me to any out keep-state
add allow tcp from me to any out keep-state
add allow udp from me to any out keep-state
add deny ip from any to any

либо наложить на FreeBSD 7.2 и ниже патч бекпортированный из FreeBSD 8.0-CURRENT который реализует функциональность дефрагментации IP на отдельном reass правиле. Патч здесь ( http://people.freebsd.org/~piso/ipfw-reass-7x.diff ). Пример правил с его применением:

add reass ip from any to any in
add check-state
add allow icmp from me to any out keep-state
add allow tcp from me to any out keep-state
add allow udp from me to any out keep-state
add deny ip from any to any

- Рекомендуется выставлять количество потоков по количеству процессоров (ядер процессора).

msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4

При использовании модели на основе потоков, значения этих параметров рекомендуется выставлять как значение степени двойки которое наиболее близко к значению num-threads. Параметры влияют на эффективность совместного использования потоками общего кеша. Если используется модель на основе форков процессов, то можно выставить эти значения в 1.

outgoing-range: 512 
#outgoing-port-avoid: 0-32767
#outgoing-port-avoid: 65001-65535

- Эти опции указывают на то, сколько различных случайных портов может использовать при проведении запросов, и на то из какого диапазона можно брать эти порты (закомментировано). По умолчанию, для исходящих запросов используется диапазон 1024 - 65535 из которого автоматически исключаются номера известных сервисов назначенных IANA. Если вдруг это понадобиться, то чтобы ограничить этот диапазон, скажем до 32768 - 65000 надо добавить в конфиг оба outgoing-port-avoid. Каждый новый запрос к авторитарным DNS серверам отправляется со своего порта — это сделано для секюрности.

msg-cache-size: 16m
rrset-cache-size: 32m
key-cache-size: 10m
cache-max-ttl: 86400

- Эти опции указывают на то, каким будет размер кеша полученных DNS ответов (msg-cache) и, собственно, кеша DNS записей (rrset-cache). Рекомендуется устанавливать размер rrset-cache в два раза больше чем размер msg-cache. Опция cache-max-ttl указывает на максимальный срок жизни записей в кеше даже не смотря на их оригинальный TTL (86400 = 24 часа). Параметр key-cache-size указывает на размер памяти выделенной для хранения DNSSEC ключей (если unbound работает в режиме "validator iterator")

num-queries-per-thread: 1024

- Указывает сколько одновременных клиентских запросов сможет обработать один поток.

infra-host-ttl: 60
infra-lame-ttl: 120

- Установка этих значений указывает срок жизни записей из внутреннего кеша "неработающих" и "неправильных" DNS серверов. По умолчанию эти значения выставлены в 900 секунд (15 мин). Имеет смысл все же снизить их значения. Так, например, если применяется схема форвардинга запросов через установку forward-zone: то в случае кратковременного прерывания связи с сервером на который происходит форвардинг, такой сервер может попасть в кеш неработающих серверов и доступ к нему будет возобновлен только через 15 минут, что не есть хорошее решение :) После установки этих значений, следующая попытка обращения к серверу из черного списка будет предпринята уже через 60 сек. Эта настройка связана с безопасностью (в большей мере параноидальной безопасностью :)

access-control: 192.168.1.0/24 allow

- Кому разрешено посылать рекурсивные запросы (пользоваться кешем)

statistics-interval: 300
logfile: ""
use-syslog: no

- Полное отключение любого логирования. Мне не нужно. Если надо — можно включить и установить уровень verbosity от 1 до 4. В отличии от NSD, Unbound пишет в свои логи очень много разной статистики. При вербозности 4, вывод в лог по насыщенности практически напоминает tcpdump. statistics-interval - вывод в лог переодических отчетов о работе серврера.

module-config: "iterator"

- Устанавливает режим работы как исключительно DNS кеша. Еще один вариант этой настройки "validator iterator". В таком случае появляется возможность использовать DNSSEC расширения.

local-zone:

- Возможность "засорить" кеш своими данными приоритет которых будет выше чем у данных оригинальной зоны. Параметр устанавливаемый после имени local-zone указывает на режим как надо отвечать на данные которые предварительно не были указаны. Варианты:

deny - serves local data (if any), else, drops queries.
refuse - serves local data (if any), else, replies with error.
static - serves local data, else, nxdomain or nodata answer.
transparent - serves local data, else, resolves normally .
direct - serves the zone data for any subdomain in the zone.
nodefault - can be used to normally resolve AS112 zones.

- Перенаправление всех запросов к этой зоне на указанный авторитарный сервер. Запросы отсылаются как итерационные.

forward-zone:

- Перенаправление всех запросов к этой зоне на указанный кеширующий сервер. Запросы отсылаются как рекурсивные. Это способ форвардинга запросов. Если указать здесь:

forward-zone: 
name: "."
forward-addr 192.168.2.1

То все запросы направляемые на наш сервер, будут перенаправляться на 192.168.2.1 который уже будет проводить всю рекурсию и возвращать ответ.

#extended-statistics: yes
remote-control:
        control-enable: yes
        control-interface: 127.0.0.1
        control-port: 953

- Данная секция включает возможность удаленного управления сервером через unbound-control. Указывается само разрешение удаленного управления, на каком IP и на каком TCP порту сервер будет ожидать подключений. Включение опции extended-statistics значительно расширяет диапазон выводимой статистики (например, начинает выводиться статистика по количеству отдельных типов DNS запросов), но это так же снижает скорость работы сервера.



Конфигурация для больших нагрузок



В mail-листах unbound было несколько обсуждений в которых поднимался вопрос об оптимальных настройках для серверов рассчитаных на большие нагрузки. Перепишу здесь основные мысли.



Главные опции влияющие на производительность сервера - это num-queries-per-thread, outgoing-range, а так же размеры кешей msg-cache-size и rrset-cache-size. 



num-queries-per-thread - устанавливает размер "очереди" запросов ждущих разрешения. Это максимальное количество одновременных рекурсий которое разрешено принять от клиетов и обработать одному процессу. Если очередь переполняется, то вновь пришедшие клиентские запросы все еще могут быть обслужанны, но только на основании тех данных, что уже находятся в кеше сервера. Если нужной информации в кеше нет то запрос может быть дропнут.



outgoing-range - устанавлиевает максимальное число одновременно инициированнных рекурсий к внешним серверам. Как много может быть паралельных разрешений имен которых еще нет в кеше.



Значения этих двух параметров надо держать близко друг к другу. Если размер num-queries-per-thread слишком большой, и при этом outgoing-range маленький, то это приведет к потерям в очереди запросов - запросы не будут обслужаны из-за задержек. В статистике такая ситуация будет видна так:

[1223529704] unbound[24517:0] info: server stats for thread 0: 42804
queries, 21012 answers from cache, 21792 recursions
[1223529704] unbound[24517:0] info: server stats for thread 0:
requestlist max 1031 avg 811.488 exceeded 10926

exceeded 10926 - столько раз очередь num-queries-per-thread "переполнялась" - следовательно столько запросов небыло разрешено. Клиентами это будет ощущаться как то, что DNS сервер не ответил на запрос.



Для того чтобы иметь возможность устанавливать большие значения outgoing-range необходимо использовать libevent.

Rimlyanin, 2008-07-09 в 14:04:13

Спасибо, сейчас буду пробовать настроить, тут как раз понадобилось в одной из сетей NS поднять, думал как всегда BIND :)

dmitry, 2008-07-09 в 19:04:57

как ни крути, BIND намного лучше и быстрей. во всяком случае у меня с ним проблем никогда не было.

GR, 2008-07-09 в 19:11:49

>... гламурного BIND Прикольно :) У меня он ассоциируется скорее с огромным чёрным паровозом который бегает по современным электродорогам ,) Оно электричество конечно не пользует, дымит и пыхтит ... но таскает вагончики все эти скоро 30 лет :) PS: Интересно - Unbound подвержен http://www.us-cert.gov/cas/techalerts/TA08-190B.html или нет? Если нет - то просто статья "в руку" :) GR.

max, 2008-07-09 в 21:15:47

to GR проблема дизайна протокола - что непонятно тебе?

shutdown now, 2008-07-09 в 23:20:33

я вот powerdns-recursor около года использую, kevent умеет использовать и chrootиться тоже, но DNS валидатора как в unbound нет а вот bind с большим кешем тупит, использую его чисто как авторитетный

terminus, 2008-07-10 в 14:50:50

>как ни крути, BIND намного лучше и быстрей. Ну, это дело вкуса... Да, бинд как и sendmail - софт с традицией и все такое, но факты говорят о том, что в нем часто находят дыры (как вот недавно TA08-190B) и, что он не такой уж быстрый и масштабируемый (BIND vs NSD http://people.freebsd.org/~kris/scaling/bind-nsd.png). Я для себя напротив понятия BIND сделал ментальную пометку "это плохо" и, пока не жалею ;) К стати на счет TA08-190B - пока не ясно на сколько эта проблема серьезна (детали баги пока не известны - может проблема протокола, а может только реализации), но счастивые обладатели PowerDNS или Unbound или djbdns сейчас лениво пьют пиво, ибо эти продукты используют техники затрудняющие атаку...

opt1k, 2008-08-17 в 20:32:08

Статья супер, большое спасибо. Обратите внимание на: forward-zone: name: "." stub-addr: 192.168.2.1 надо так: forward-zone: name: "." forward-addr: 192.168.2.1

terminus, 2008-08-18 в 12:14:41

Немного погодя (когда время появится) мне предется исправить статью. Дело в том, что начиная с версии Unbound 1.0.2 он стал проверять наличие libevent и, если его нет, и количество потоков выствлено в 4 или больше (общее количество файловых дискрипторов >= 1024 на процесс), то Unbound не заводится и выкидывае сообщение об ошибке. Я спрашивал в unbound-users что делать если libevent 1.3e работает не стабильно, но надо использовать много потоков? Там посоветовали не использовать потоки, а использовать форки процессов... Лажа. Написал маинтаинеру libevent с просьбой обновить порт, но ответа пока не получил. В общем, пока я не исправил статью - кто будет ставить, учитывайте что без libevent максимум 3 потока можно использовать, или надо компилить без потоков чтобы форкались процессы (но тогда у каждлго будет свой кеш - возростают требования к памяти).

Kolesya, 2008-10-13 в 12:20:18

>В результате всех этих танцев с бубном, после >каждой перезагрузки компа будим иметь в ./dev: Перегружать не обязательно, хватит /etc/rc.d/devfs restart

Kolesya, 2008-10-13 в 12:21:53

в догонку: 1. правим /etc/fstab 2. правим /etc/devfs.rules 3. mount -a 4. /etc/rc.d/devfs restart

terminus, 2008-10-13 в 12:27:44

Спасибо за комментарий - внесу его в статью как вариант для тех кому нельзя перезапускаться. Сделал с перезагрузками просто как меру предосторожности - параноег йа ;)

Алексей, 2008-10-14 в 1:46:07

Что делать? Имею: devfs ruleset: ioctl DEVFSIO_SUSE: Inappropriate ioctl for device ./devfs: WARNING: devfs_set_ruleset: unable to set ruleset 20 to /usr/local/etc/unbound/dev devfs rule: ioctl DEVFSIO_SAPPLY: Inappropriate ioctl for device ./devfs: WARNING: devfs_apply_ruleset: unable to apply ruleset 20 to /usr/local/etc/unbound/dev freebsd 6.3

Алексей, 2008-10-14 в 2:04:37

Нет мне прощенья!!! Перепутал fstab c fbtab... ... - это судьба...

Kolesya, 2008-10-14 в 20:43:50

6.3-STABLE 7.0-STABLE ulimit не находит, юзайте limits

scan, 2009-01-20 в 17:25:31

Кстати, как уверяют в багфиксах для версии 1.2.0: The long standing bug with libevent use is fixed. It turns out to be a race condition in the calls to libevent. The builtin mini-event did not have a problem being called like this, but libevent and libev usage is now fixed. Libevent 1.1 is reported to still give problems, but 1.4.5 and 1.4.8 seem fine.

terminus, 2009-01-20 в 19:45:16

Да-да, спасибо что упомянули. Я в курсе о изменениях в новой версии unbound - сейчас я как раз перешел на 1.2.0 с использованием потоков вместе с libevent, и проблем больше не отмечаю. Чуть позже я перепишу статью по-новой. Есть план рассмотреть так же DNSSEC и DLV.

Ce$$, 2009-05-26 в 16:22:21

Искал замену dnscache, 1,5 месяца работает unbound, нареканий нет. Спасибо за статью.

Митра, 2009-10-30 в 22:09:32

Поставил, работает. Спасибо.

kirgudu, 2009-12-03 в 13:21:13

Кстати, очень не рекомендуется stateful firewall для DNS. При большой нагрузке - клеит ласты, т.к. стейтов становится очень и очень много.

Den, 2012-03-18 в 13:33:24

здрасте.. я по вопросу Генерируем связку ключей необходимых для работы unbound-control: # unbound-control-setup что-то не совсем понял как сгенерировать ключи..

terminus, 2012-03-18 в 14:55:24

Находясь в директории /usr/local/etc/unbound запускаете команду unbound-control-setup. Она сгенерирует несколько файлов (публичный и закрытый ключи). Далее действуете по оставшимся в руководстве шагам.

Raven_kg, 2012-06-21 в 8:58:09

А что случилось с аттачем? Не могу скачать, говорит у мну нет прав.

terminus, 2012-06-21 в 18:22:00

У меня все нормально скачивается. Вот закинул копию на другой хостинг: http://www.sendspace.com/file/mbh3t8

Саша, 2012-08-30 в 17:32:28

А расскажите, пожалуйста, как в unbound логировать хосты, с которых приходят запросы? Мне кажется, что это очень важно и нужно для ДНС-сервера, а бегло не смог найти как. :(

terminus, 2012-09-02 в 14:04:44

Логировать IP адреса клиентов можно только выставив 5й уровень вербозности лог файла.

Александр, 2013-03-22 в 12:32:14

Если вдруг это понадобиться, то чтобы ограничить этот диапазон, скажем до 32768 - 65000 надо добавить в конфиг оба outgoing-port-avoid. А разве не достаточно будет указать один раз outgoing-port-avoid: 32768-65000 ?

GK, 2013-11-13 в 16:01:50

подключение от провайдера по DHCP!!!! указываю ip адрес полученный по DHCP в outgoing-interface: стартую unbound /usr/local/etc/rc.d/unbound start unbound-checkconf: no errors in /usr/local/etc/unbound/unbound.conf Obtaining a trust anchor:/usr/local/etc/rc.d/unbound: WARNING: failed precmd routine for unbound пробовал прописывать статические ip и dns unbound работает до 1 перезагрузки а потом то же самое unbound-checkconf: no errors in /usr/local/etc/unbound/unbound.conf Obtaining a trust anchor:/usr/local/etc/rc.d/unbound: WARNING: failed precmd routine for unbound unbound.log debug: failed address 178.*.*.* port 55574 [1386736099] unbound[10707:0] error: can't bind socket: Can't assign requested address HELLP!!!

Юрий, 2014-05-29 в 9:12:30

Наткнулся на статью в свете отказа в 10-ке от Бинда в пользу Unbound. Статья очень толковая и довольно полная. Большое спасибо!

Александр, 2016-02-23 в 1:38:51

Статья огонь! Перерыл, наверное, 3 десятка разных мануалов. В т.ч. зачитал до дыр мануалы и советы от разрабов на оф.сайте, но такой целостной и последовательной статьи не видел. В виду все еще недостаточного опыта для самостоятельного понимания всех нюансов статья была находкой и собрала в единую картину все, что было перечитано до нее по сабжу. Автору спасибо.

Vano, 2016-05-05 в 15:36:38

кеш целиком распологается в памяти

Андрей, 2017-07-05 в 22:23:05

Команда unbound-control-setup в директории /etc/unbound (FreeBSD 11.0) отвечает Command not found

Андрей, 2018-04-25 в 20:56:33

Сам себе и отвечу. В феврале 2016 года local_unbound изменили и unbound_control_setup убрали. И теперь надо все ставить из портов или пакет собирать, чтобы нормально настроить.

`Оставьте свой комментарий:`
`Ваше имя: *`
`e-mail:`
`жирный` `наклонный` `подчёркнутый` `ссылка` `цвет`	Товарищщи! Это поля для ввода комментариев к статье, а не для вопросов. Сюда пишите найденные баги, или какие-то фичи :) Для вопросов есть форум!
`Нынешний год: *`