Приветствую вас, Уважаемые Читатели!
Совсем недавно с удивление узнал, что оказывается два весьма популярных продукта BIND сервер и DHCP сервер, выпускаются и распространяются одним производителем - Internet Systems Consortium. Первый является старейшей и популярнейшей реализацией сервера DNS. Второй является также популярнейшей реализацией DHCP сервера, вообще-то я даже и не знаю выпускает-ли такой сервер кто-то ещё. И как только я это понял, сразу подумал, что было бы странно если бы этот производитель не обеспечил свои известнейшие продукты возможностью взаимодействовать друг с другом.
Т.е. было бы логично, что бы DHCP-сервер выдал адрес очередному хосту, а потом ещё и передал это имя действующему в этой области DNS-серверу. И немного поискав на просторах интернета нашёл как настроить такую возможность. У нас уже имеется в сети заготовленный именно под эту цель сегмент LAN1, в котором уже имеются настроенные DHCPи DNSсервера. Ещё раз напомню схему построения.
И приступим к настройкам:
+ сначала настроим DNS сервер deb-lan1-bind-prim.lan1.loc., благо настроек там немного, в файле /etc/bind/named.conf.local пропишем файл с rndc ключом, который будет использоваться между серверами DNS и DHCP для опознавания друг друга, для это пропишем в начало строку
inclulde /etc/bind/rndc.key
(предварительно убедившись, что этот файл наличествует по этому пути)
+ на сервере DNS deb-lan1-bind-prim.lan1.loc. в описаниях прямой и обратной доменных зон пропишем строчку
allow-update {key rndc-key;};
(наверное она указывает способ авторизации)
+ теперь на сервере DNS deb-lan1-bind-prim.lan1.loc.всё проверяем утилитами named-checkconf и named-checkzone проверяем синтаксис конфигурационных файлов, перезагружаем базу данные и по возможности перезагружаем сервис
rndc reload
systemctl restart bind9
+ в завершении скопируем файл /etc/bind/rndc.key с сервера deb-lan1-bind-prim.lan1.loc. на сервер deb-lan1-dhcp.lan1.loc. по пути /etc/dhcp/rndc.key
+ переходим на сервер deb-lan1-dhcp.lan1.loc. выставляем этому файлу такие разрешения:
chown root:root rndc.key
chmod 640 rndc.key
+ на сервере DHCP deb-lan1-dhcp.lan1.loc. выполним настройки файла /etc/dhcp/dhcpd.conf
здесь так же необходимо прописать путь к файлу rndc.key
include "/etc/dhcp/rndc.key";
+ (в файле /etc/dhcp/dhcpd.conf) прописываем несколько заклинаний, разрешающих динамическое обновление базы DNS
ddns-updates on;
ddns-update-style interim;
ignore client-updates;
update-static-leases on;
+ и в том же файле прописываем доменные зоны, которые предполагается динамически обновлять.
zone lan1.loc. {
primary 192.168.1.100;
key rndc-key;
}
zone 1.168.192.in-addr-arpa {
primary 192.168.1.100;
key rndc-key;
}
;
+ проверяем синтаксис файла dhcpd.conf командой dhcpd -t
+ перезапускаем сервис DHCP systemctl restar isc-dhcp-server
+ по сути это все настройки, перезапускаем и обновляем всё что только можно и проверяем работу динамического обновления.
По описанному пути у меня не возникло никаких затруднений и никаких приключений. Единственно что у меня вызвало замешательство это небольшая моя ошибка, допущенная после настройки DHCP сервера, и которая вылезла во время проверки работы динамического обновления DNS. Когда я настроил DHCP на тестовом хосте deb-lan1-host101.lan1.loc., забыл удалить запись об этом хосте из файла содержимого доменной зоны "lan1.loc." на DNS сервере deb-lan1-bind-prim.lan1.loc. В результате любые попытки поиска адреса тестового хоста через DNS сервер приводили к одному и тому же адресу. Собственно, который был прописан в домене. А реальный адрес тестового хоста был выдан DHCP сервером, и был совершенно другой. В результате я закомментировал запись о хосте deb-lan1-host101.la1.loc. в файле содержимого доменной зоны. И тогда сразу DNS сервер стал мне отвечать на запросы правильным адресом.
Проведём небольшое рабочее испытание динамического обновления базы DNS на примере хоста с WinXP. Для этого склонируем отдельный WinXP хост, назначим ему автоматическое получение адреса, и поместим в сегмент LAN1 (который мы и настраивали только что). Сразу после назначение имени хост получил адрес по DHCP, что сразу можно посмотреть в свойствах соединения.
Теперь просто пропингуем этот хост с тестового хоста того же сегмента.
Тестовые хосты пингуют друг друга, при этом адрес разрешается по имени. Т.е. адрес выдан, и разрешается DNS сервером в сегменте LAN1 deb-lan1-bind-prim.lan1.loc.
Попробуем пропинговать тестовый хост из другого сегмента, и соответственно получить адрес у другого DNS сервера deb-lan3-bind-prim.loc.И это тоже удачно получается.
Для полной уверенности, и очистки совести до прозрачности проверим всё более основательно. Для начала зайдём на наш любимый тестовый хост deb-lan2-host101.loc., на котором установлен dig и запросим адрес для тестового хоста win-lan1-test-dhcp.lan1.loc. Адрес при этом разрешается. Замечу что адрес разрешается сервером, который обслуживает deb-lan2-host101.loc., а это deb-lan3-bind-prim.loc. (192.168.3.100)
Теперь освободим адрес на хосте win-lan1-test-dhcp.lan1.loc.Обновим все DNS-сервера командой rndc reload. И ещё раз запросим адрес. Имя хоста при этом не разрешается. Что логично.
И теперь вновь назначим адрес хосту win-lan1-test-dhcp.lan1.loc.. Потом ещё раз обновим DNS сервер командой rndc reload. Правда на этот раз команды не хватило, и пришлось ещё перезапустить сервер
deb-lan3-bind-prim.loc. перезапустить командой systemctl restart bind9. И после всех манипуляций ещё раз запросим адрес хоста. И адрес разрешился.
Т.е. мы получили, что адрес хосту win-lan1-test-dhcp.lan1.loc. был выдан DHCP-сервером в одном сегменте сети и доменной зоне. А разрешился сервером-DNS в другом сегменте сети и другой доменной зоне. Т.е. адрес был передан DHCP сервером в систему серверов DNS, откуда и был извлечён утилитой dig. Т.е. получается, что динамическое обновление DNS данных уверенно работает. Что и было нашей конечной целью.
Ну для полной надёжности проверим, что именно этот адрес был выдан именно на этот хост на DHCP сервере
Ну т.е. теперь мы точно видим, что всё получилось.
Сервера настроены.
Связи налажены.
Цели достигнуты
Уже после написания основной части статьи обнаружил пару интересных моментов.
Во-первых в по пути /var/lib/bind/, там где у меня обычно лежали файлы содержимого доменной зоны обнаружил файлы с суффиксом jnl (db.lan1.jnl). Сначала думал, что это какой-то мусор, но задав вопрос жёлтому поисковику обнаружил, что это журнал действий. И такой журнал может быть прочитан коммандой named-journalprint. Выполнив эту команду как раз обнаружил команды удаления и добавления хоста по динамическому обновлению.
Во-вторых попробовал использовать свой любимый способ проверки содержимого доменной зоны командой rndc dumbdb -zones и изучением файла /var/cahce/bind/named-dump.db. Обнаружил, что если при динамическом обновлении хост, получивший адрес по DHCP, получает в базе данных запись в прямой зоне, но не получает запись в обратной зоне. В чём можно убедиться утилитой dig.
Эти наблюдения мне показались достаточно интересными для упоминания в конце статьи, и на этом считаю возможным закончить повествование.
Схему и конфы всех хостов выложу в канал MAX .
Благодарю всех Уважаемых Читателей, дочитавших до этого места.
Желаю всем удачи в начинаниях и продолжениях, до новых встреч!!!)
PS
Статья не является учебным пособием, и представляет личный опыт автора.
Статья может содержать ошибки и не точности.
Приведённые данные необходимо проверять самостоятельно.
Текст написан автором лично без использования ИИ.
Картинка для превью статьи сгенерирована сетью Шедеврум, возможно с небольшими правками автора.
Канал MAX для всего того, что не поместилось на канал ДЗЕН.