Как настроить DNS-резольвер для несвязанного кэширования на FreeBSD 10.1

Как настроить DNS Resolver для несвязанного кэширования на FreeBSD 10.1 или 10.2

Вступление

Система серверов доменных имен (DNS) - это глобальная иерархия баз данных, предназначенная для простой, но важной задачи поиска имен хостов, таких как «+ www.digitalocean.com +» и превращения их в один или несколько IP-адресов. Всякий раз, когда электронное письмо отправляется или соединение с хостом инициируется по его имени, используется система DNS. Существует хорошее introduction для системы DNS доступное в сообществе DigitalOcean.

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

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

Предпосылки

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

Одна капля FreeBSD 10.1

Шаг 1 - Включение Unbound

FreeBSD 10.1 включает в себя верифицирующий распознаватель кэширования Unbound (версия 1.4.22) как часть базовой системы; FreeBSD 10.2 включает в себя версию 1.5.3. Оба считаются безопасными и готовыми к использованию.

После того, как вы вошли на сервер через SSH, включить встроенный распознаватель FreeBSD так же просто, как выполнить следующую команду:

sudo sysrc local_unbound_enable=YES

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

Шаг 2 - Начало Unbound

Вы можете немедленно запустить распознаватель без полного перезапуска системы.

Чтобы запустить распознаватель:

sudo service local_unbound start

Если Unbound запускается успешно, вы должны увидеть вывод, подобный следующему:

Выход

Performing initial setup.
Extracting forwarders from /etc/resolv.conf.
/var/unbound/forward.conf created
/var/unbound/lan-zones.conf created
/var/unbound/unbound.conf created
/etc/resolvconf.conf created
original /etc/resolv.conf saved as /etc/resolv.conf.20150812.184225
Starting local_unbound.

В настоящее время вы запускаете распознаватель кэширующих имен Unbound проверки, но не все работающее в настоящее время программное обеспечение гарантированно заметит и подберет модификацию.

Шаг 3 - Сохранение этой настройки с помощью восстановления капли

Такие действия, как восстановление образа резервной копии или использование изображения моментального снимка в качестве основы для новой капли, обычно приводят к потере конфигурации, которую мы сделали до сих пор. Это связано с незначительной ошибкой в драйвере OpenStack для FreeBSD. К счастью, эта ошибка была исправлена в следующем выпуске. Сейчас мы будем индивидуально применять этот конкретный патч к текущему выпуску, чтобы обеспечить правильную работу Unbound с возможностями резервного копирования и создания моментальных снимков DigitalOcean.

Загрузите патч из официального репозитория для BSD-CloudInit (драйвер FreeBSD OpenStack):

fetch https://github.com/pellaeon/bsd-cloudinit/commit/a7ee246c23.diff

Примените патч к нужному файлу:

sudo patch -N -F3 /usr/local/bsd-cloudinit/cloudbaseinit/osutils/freebsd.py < a7ee246c23.diff

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

Выход

. . .
Patching file /usr/local/bsd-cloudinit/cloudbaseinit/osutils/freebsd.py using Plan A...
Hunk #1 succeeded at 4 with fuzz 2 (offset 1 line).
Hunk #2 succeeded at 83 with fuzz 3 (offset 4 lines).
done

Вам больше не нужен файл патча, и вы можете удалить его:

rm a7ee246c23.diff

Ваша система теперь настроена на использование Unbound через резервное копирование и восстановление системы или после клонирования на совершенно новый сервер.

Шаг 4 - Перезапуск затронутых сервисов

Самый простой способ убедиться, что все ваше программное обеспечение использует новый распознаватель, - это полностью перезапустить Droplet.

Вы можете отложить это до тех пор, пока это не окажет минимального влияния на сервис, предоставляемый вашей Droplet. Работающее программное обеспечение будет использовать либо старый распознаватель, либо новый, а не неисправность; любое программное обеспечение, способное в то же время уловить переход, сделает это изящно. и не должно быть никаких негативных последствий от того, что оба они временно используются бок о бок.

Когда вы будете готовы, перезапустите капельку:

sudo shutdown -r now

Вот и все, что нужно сделать!

Заключение

Из этого руководства вы узнали, как кэшировать поиск имени хоста и имени домена в вашей системе и почему вы можете захотеть это сделать. Вы можете узнать больше о решателе кэширования FreeBSD на странице home для проекта Unbound.

TOC