Настройка unbound centos 7

Обновлено: 06.07.2024

В релизе FreeBSD 10.0 DNS-сервер BIND заменен на связку из кеширующего DNS-сервера Unbound и библиотеки LDNS. Разбираясь с нововведениями, решил заодно ознакомиться и с настройкой Unbound.

Unbound распространяется под лицензией BSD, имеет модульную структуру и поддерживает работу резолвера в рекурсивном и кэширующем режиме. Во время работы сервера, кеш целиком распологается в памяти. Также имеется возможность проверки валидности DNSSEC-сигнатур, асинхронных запросов и библиотеки для интеграции кода резолвера в пользовательские приложения (stub-resolvers). Вначале прототип сервера был написан на языке Java, после чего был переписан на языке Си, что позволило значительно увеличить его производительность. По сравнению с BIND, стоит отметить скромные размеры и высокую производительность.

Конфигурационный файл unbound.conf должен находиться в каталоге /var/unbound.

С доступными опциями решил ознакомиться на страницах руководства man unbound.conf. Как оказалось, пример конфигурационного файла был предложен именно там. Попробуем собрать небольшой файл конфигурации, отталкиваясь от предложеного примера и доступных опций.

После создания конфигурационного файла проверим конфигурацию с помощью уже известной утилиты unbound-checkconf:

Кажется все в порядке. Добавим загрузку демона при старте системы:

Проверим, запустился ли процесс:

Демон запущен. Проверим, обрабатывает ли он запросы:

После этого необходимо добавить следующий блок в конфигурационный файл unbound.conf:

Чтобы изменения вступили в силу, необходимо перезапустить unbound:

Чтобы ознакомиться с возможностями утилиты unbound-control, достаточно вызвать ее без ключей, либо же с ключем -h:

Здесь, благодаря комментариям, все интуитивно понятно

Поддерживается возможность управления удаленным сервером unbound, используя локальную версию утилиты unbound-control. Для этого необходимо, чтобы на машине, с которой выполняются комманды, публичные pem-ключи удаленного сервера. Также необходимо, чтобы эти ключи были прописаны в конфигурационном файле unbound.conf.

Проверим поддержку DNSSEC:

;; Query time: 0 msec
;; EDNS: version 0; flags: do ; udp: 4096
;; SERVER: 127.0.0.1
;; WHEN: Wed Mar 12 16:37:19 2014
;; MSG SIZE rcvd: 446

Кэширование серверов имен с использованием ' Unbound ' (это программное обеспечение для проверки, рекурсии и кеширования DNS-серверов), еще в RHEL/CentOS 6.x (где x - номер версии) мы использовали bind программное обеспечение для настройки DNS-серверов.

В этой статье мы собираемся использовать «несвязанное» программное обеспечение для кэширования для установки и настройки DNS-сервера в системах RHEL/CentOS 7.


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

Кэширование будет действовать только как агент для разрешения запроса клиента от любого из серверов пересылки. Использование кэширующего сервера сократит время загрузки веб-страниц, сохраняя базу данных кеша на несвязанном сервере.

В демонстрационных целях я буду использовать две системы. Первая система будет действовать как главный (первичный) DNS-сервер, а вторая система будет действовать как локальный DNS-клиент.

Шаг 1. Проверьте имя хоста системы и IP-адрес.

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

2. После установки правильного имени хоста и статического IP-адреса вы можете проверить их с помощью следующих команд.


Шаг 2: установка и настройка несвязанного

3. Перед установкой «несвязанного» пакета мы должны обновить нашу систему до последней версии, после чего мы сможем установить несвязанный пакет.


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

5. Затем используйте любой из ваших любимых текстовых редакторов, чтобы открыть и отредактировать файл конфигурации unbound.conf.

После открытия файла для редактирования внесите следующие изменения:

Найдите Интерфейс и включите интерфейс, который мы собираемся использовать, или, если наш сервер имеет несколько интерфейсов, мы должны включить интерфейс 0.0.0.0 .

Здесь IP-адрес нашего сервера был 192.168.0.50 , поэтому я собираюсь использовать несвязанный в этом интерфейсе.

Найдите следующую строку и введите « Да ».

Чтобы включить журнал, добавьте переменную, как показано ниже, она будет регистрировать все несвязанные действия.

Включите следующий параметр, чтобы скрыть запросы id.server и hostname.bind .

Включите следующий параметр, чтобы скрыть запросы version.server и version.bind .

Затем найдите контроль доступа , чтобы разрешить. Это позволяет тем клиентам, которым разрешено запрашивать этот несвязанный сервер.

Здесь я использовал 0.0.0.0 , что означает, что любой отправляет запрос на этот сервер. Если нам нужно отклонить запрос для некоторого диапазона сети, мы можем определить, какая сеть должна быть отклонена от несвязанных запросов.

Примечание. Вместо allow мы можем заменить его на allow_snoop , это включит некоторые дополнительные параметры, такие как dig , и поддержит как рекурсивный, так и нерекурсивный.

Затем выполните поиск по запросу небезопасный домен . Если наш домен работает с ключами DNS sec , нам необходимо определить наш сервер, доступный для небезопасного домена . Здесь наш домен будет считаться небезопасным.

Затем измените серверы пересылки для нашего запрошенного запроса, который не выполняется этим сервером, он перенаправит в корневой домен (. ) и разрешит запрос.

Наконец, сохраните и закройте файл конфигурации с помощью wq! .

6. После выполнения вышеуказанной конфигурации проверьте файл unbound.conf на наличие ошибок с помощью следующей команды.


7. После того, как проверка файла прошла без ошибок, вы можете безопасно перезапустить «несвязанную» службу и включить ее при запуске системы.

Шаг 3. Протестируйте кеш DNS локально


Это означает, что первый запрос кэшируется в нашем DNS-кеше, поэтому, когда мы выполняем «детализацию» во второй раз запрос, обслуживаемый из нашего локального DNS-кеша, таким образом мы можем улучшить скорость загрузки веб-сайтов.

Шаг 4: очистите Iptables и добавьте правила Firewalld

9. Мы не можем использовать iptables и firewalld одновременно на одной машине, если мы это сделаем, оба будут конфликтовать друг с другом, поэтому удаление правил ipables будет хорошей идеей. Чтобы удалить или очистить iptables, используйте следующую команду.

10. После окончательного удаления правил iptables теперь навсегда добавьте службу DNS в список firewalld.

11. После добавления правил службы DNS перечислите правила и подтвердите.


Шаг 5: Управление и устранение неполадок несвязанного

12. Чтобы получить текущий статус сервера, используйте следующую команду.



14. Чтобы восстановить или импортировать кеш из выгруженного файла, вы можете использовать следующую команду.


15. Чтобы проверить, разрешен ли конкретный адрес нашими серверами пересылки на сервере несвязанного кеша, используйте команду ниже.

16. Иногда, если наш кэш-сервер DNS не отвечает на наш запрос, мы можем использовать его для очистки кеша, чтобы удалить такую u200bu200bинформацию, как A , AAA , NS , SO , CNAME , MX , PTR и т. Д. Записи из кеша DNS. Мы можем удалить всю информацию с помощью flush_zone , при этом будет удалена вся информация.

17. Чтобы проверить, какие форварды в настоящее время используются для разрешения.


Шаг 6: Настройка DNS на стороне клиента

18. Здесь я использовал сервер CentOS 6 в качестве моей клиентской машины, IP-адрес этой машины - 192.168.0.100 , и я собираюсь использовать IP-адрес своего несвязанного DNS-сервера. (т.е. первичный DNS) в его конфигурации интерфейса.

Войдите на клиентский компьютер и установите IP-адрес основного DNS-сервера на IP-адрес нашего несвязанного сервера.

Запустите команду установки и выберите конфигурацию сети в диспетчере сети TUI .

Затем выберите конфигурацию DNS , вставьте IP-адрес несвязанного DNS-сервера как Первичный DNS , но здесь я использовал как Первичный , так и Вторичный потому что у меня нет другого DNS-сервера.




Нажмите ОК -> Сохранить и выйти -> Выйти .

19. После добавления первичного и вторичного IP-адресов DNS пора перезапустить сеть, используя следующую команду.

20. Теперь пора зайти на любой из веб-сайтов с клиентской машины и проверить кеш на несвязанном DNS-сервере.



Заключение

Ранее мы использовали для настройки DNS-кеш-сервера с помощью пакета bind в системах RHEL и CentOS. Теперь мы увидели, как настроить сервер кеширования DNS с помощью несвязанного пакета. Надеюсь, это разрешит ваш запрос быстрее, чем bind pacakge.

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

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

Contents

Установка

Настройка

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

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

Запуск 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) для подробностей и поддерживаемых команд.

Советы и приёмы

Черный список доменов

Для добавления домена в черный список, используйте строку 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 .

Решение проблем

Определение нужного количества потоков (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 из репозиториев.

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

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

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

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

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

unbound-checkconf: no errors in /etc/unbound/unbound.conf

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

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

tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 2500/unbound
udp 0 0 0.0.0.0:53 0.0.0.0:* 2500/unbound

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

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

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

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

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

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

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

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


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

Читайте также: