Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи Kea DHCP

Автор: Уваров А.С. 29.06.2024Время чтения: 5 мин Debian и Ubuntu Server Свой DNS-сервер

По мере роста любой сети возникает необходимость перехода от обращения к узлам с IP-адресов на FQDN, что позволяет полностью отвязаться от IP-адресации и использовать постоянные и удобные для запоминания доменные имена. А задачу преобразования доменных имен в IP-адреса берет на себя DNS-сервер. Но как быть с узлами, которые получают IP-адрес по DHCP? Все просто — необходимо настроить динамическое обновление записей DNS-сервера, и сегодня мы расскажем, как сделать это для DHCP-сервера Kea.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Прежде всего будем считать, что у вас уже есть рабочий DNS-сервер на базе BIND, его можно настроить по нашей статье:

Рекомендуем к прочтению

Настраиваем отказоустойчивый DNS-сервер на базе BIND 9

Базовую настройку DHCP сервера Kea можно выполнить при помощи другого нашего материала:

Рекомендуем к прочтению

Установка и базовая настройка DHCP-сервера Kea

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

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

Сеть: 192.168.72.0/24
DHCP-сервер: 192.168.72.1
DNS-сервер (первичный): 192.168.72.8
Домен: it-31.lab

В данной статье мы будем рассматривать настройку сервисов в среде Debian или Ubuntu, все действия, если не указано иного, выполняются с правами суперпользователя (root).

Настройка первичного DNS-сервера BIND 9

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

Прежде всего убедимся, что файлы зоны находятся в /var/lib/bind, это важно, так как AppArmor блокирует для службы named возможность записи в другие расположения. Если это не так, то просто скопируйте файлы зон в /var/lib/bind.

Затем откроем файл /etc/bind/named.conf.local и в самом начале добавим строку:

1include "/etc/bind/rndc.key";

Она указывает на RNDC-ключ, который нужен для проверки подлинности серверов, имеющих право вносить изменения в зону, данный ключ создается автоматически при установке BIND.

Теперь добавим в каждую зону опцию allow-update, которая разрешает обновлять зоны предъявителю RNDC-ключа.

Для прямой:

1zone "it-31.lab" {
2    type master;
3    file "/var/lib/bind/db.it-31.lab";
4    ...
5    allow-update { key rndc-key; };
6};

Обратной:

1zone "72.168.192.in-addr.arpa" {
2    type master;
3    file "/var/lib/bind/db.192.168.72";
4    ...
5    allow-update { key rndc-key; };
6};

Не забываем проверить опцию file, которая обязательно должна указывать на расположение файлов зон в /var/lib/bind.

Проверяем отсутствие ошибок в конфигурации:

1named-checkconf

И перезапускаем службу DNS-сервера:

1systemctl restart named

Более никаких настроек DNS-сервера не требуется.

Настройка DHCP-серверов ISC Kea

Если у вас настроено более одного DHCP-сервера (отказоустойчивая конфигурация), то выполнить указанные ниже действия потребуется на каждом сервере.

Как мы уже рассказывали в статье о базовой установке Kea, продукт построен по модульному принципу: сам DHCP-сервер не умеет работать с DNS-сервером, за это отвечает отдельная служба — kea-dhcp-ddns-server. Поэтому сначала убедимся, что она установлена, посмотреть все установленные компоненты Kea можно командой:

1dpkg -l | grep kea

Если пакет отсутствует, то установим его командой:

1apt install kea-dhcp-ddns-server

После чего перейдем к его конфигурационному файлу /etc/kea/kea-dhcp-ddns.conf. Kea использует конфигурационные файлы в формате JSON, они состоят из JSON-объектов, каждый из которых заключен в фигурные скобки. Каждый объект содержит параметры либо вложенные JSON-объекты. Все параметры разделяются запятыми (а вложенный объект — тоже параметр), поэтому, редактируя конфигурацию, не забывайте о правильной расстановке запятых.

Информация

Рекомендуем для работы с конфигурационными файлами Kea использовать редактор с поддержкой синтаксиса JSON, например, VS Code.

Если отбросить многочисленные комментарии, то интересующее нас начало конфигурационного файла выглядит так:

 1{
 2"DhcpDdns":
 3{
 4    "ip-address": "127.0.0.1",
 5    "port": 53001,
 6    "control-socket": {
 7       "socket-type": "unix",
 8       "socket-name": "/tmp/kea-ddns-ctrl-socket"
 9    },
10 "tsig-keys": [],
11 "forward-ddns" : {},
12 "reverse-ddns" : {},

Начнем с объекта tsig-keys, в котором следует разместить RNDC-ключ в формате JSON. Он находится на DNS-сервере в файле /etc/bind/rndc.key, прочитать его содержимое можно командой:

1cat /etc/bind/rndc.key

При этом вы увидите примерно следующее:

1key "rndc-key" {
2      algorithm hmac-sha256;
3      secret "LSWXnfkKZjdPJI5QxlpnfQ==";
4};

На основании этого приводим объект к следующему виду:

1"tsig-keys": [ 
2   {
3     "name": "rndc-key",
4     "algorithm": "hmac-sha256",
5     "secret": "LSWXnfkKZjdPJI5QxlpnfQ=="
6   }
7 ],

Объект forward-ddns отвечает за настройки обновления прямой зоны, в нашем случае настройки будут следующие:

 1"forward-ddns" : {
 2   "ddns-domains": [
 3     {
 4       "name": "it-31.lab.",
 5       "key-name": "rndc-key",
 6       "dns-servers": [
 7         {"ip-address": "192.168.72.8"}
 8       ]
 9     }
10   ]
11 },

Параметр name сообщает, для какой доменной зоны производить обновление. Обратите внимание, что зона записывается по полному пути, т.е. с точкой на конце. Далее указывается ключ для обновления зоны и адрес первичного DNS-сервера зоны.

Для обратной зоны настройки будут аналогичные:

 1"reverse-ddns" : {
 2   "ddns-domains": [
 3     {
 4       "name": "72.168.192.in-addr.arpa.",
 5       "key-name": "rndc-key",
 6       "dns-servers": [
 7         {"ip-address": "192.168.72.8"}
 8       ]
 9     }
10   ]
11 },

Сохраняем конфигурационный файл и проверяем его на ошибки:

1kea-dhcp-ddns -t /etc/kea/kea-dhcp-ddns.conf

Если ошибок нет, то перезапускаем службу:

1systemctl restart kea-dhcp-ddns-server

Служба настроена и работает, но теперь нужно научить работать с ней сам DHCP-сервер, поэтому откроем файл /etc/kea/kea-dhcp4.conf и перед двумя последними закрывающими фигурными скобками добавим следующие глобальные параметры (не забудьте поставить запятую после последнего существовавшего в файле объекта):

1"ddns-send-updates": true,
2 "ddns-qualifying-suffix": "it-31.lab",
3 "ddns-override-no-update": true,
4 "ddns-override-client-update": true,
5 "dhcp-ddns": {
6    "enable-updates": true,
7    "server-ip": "127.0.0.1"
8 }

Параметр ddns-qualifying-suffix определяет, для какого доменного суффикса мы обновляем DNS-зоны, суффикс записывается в обычном виде, без точки на конце. Опции ddns-override разрешают серверу переопределять параметры клиента. И самым последним указывается расположение службы kea-dhcp-ddns-server.

Если у вас в сети существуют ПК с именами, содержащими недопустимые для DNS-имен символы (согласно RFC 1035 это: A-Z, a-z, 0-9, и -), то для таких ПК не получится зарегистрировать доменные имена. Однако можно заставить DHCP-сервер заменять недопустимые символы на указанный. Для этого добавьте в конфигурацию еще два глобальных параметра:

1"hostname-char-set": "[^A-Za-z0-9.-]",
2 "hostname-char-replacement": "x",

Теперь все недопустимые символы будут заменены на символ "x". В случае если будут преобразованы несколько имен, содержащих одинаковое количество недопустимых символов на одинаковых местах, то регистрация DNS-записи будет выполнена только для первого из них.

Закончив редактирование, проверим файл конфигурации на ошибки: