Приветствую вас, Уважаемые Читатели!
Вот спросите меня - Чем хорош первичный сервер. Ии... хотя меня никто так и не спросил, всё равно отвечу - первичный сервер хорош своим вторичным сервером. Нууу... если совсем правильно - DNS сервера хороши своей взаимозаменяемостью, которая достигается наличием первичных и вторичным серверов.
В этой статье займёмся добавлением в систему вторичных серверов. Что бы не бороться с проблемами репликации. я решил отложить это важное дело на потом, и вот наконец пришёл подходящий момент. Первичный DNS сервер хранит файл определения доменной зоны и он может быть только один (во всяком случае я сейчас так думаю)). Вторичных серверов может быть много, не уверен что бесконечно много, но 2-3 штуки точно можно таких серверов добавить. Вторичные сервера содержат копию данных описанных в файлах определения доменных зон первичного сервера. Но на всякий случай замечу, что файлы данных вторичных серверов двоичные, и просто так человеком прочитаны быть не могут.
Вообще обычно при выполнении делегирования делегирующий и делегируемый сервера друг для друга заодно делают и вторичными для экономии ресурсов... наверное. Но в данном случае для создания более понятной структуры сети для двух вторичных серверов (двух доменных зон) мы создадим два отдельных хоста: deb-lan3-bind-scnd и deb-lan4-bind-scnd. Т.е. теперь получаем такую схему
Далее выполняем примерно такую последовательность действий:
- устанавливаем BIND9 на оба сервера;
- прописываем файл общей конфигурации named.conf.options, при этом выставляем параметр forwarding, указывающий на первичные сервера, соответствующие создаваемым вторичным; (хотя в работе это почему-то не помогло(()
- прописываем файл конфигураций для зон named.conf.local, при этом:
- параметр type=slave;
- параметр file содержит путь куда будут положены копии файлов зоны;
- параметр masters содержит список IP адресов файлов мастеров через точку с запятой.
- переходим на первичные сервера и в файлах описания прямых и обратных доменных зон добавляем записи NS, A и PTR для вновь созданных вторичных серверов.
- проверяем все файлы от перефирии делегирования к центральной доменной зоне;
- перезагружаем доменные зоны rndc reload, при возможности перезагружаем службы серверов systemctl restart bind9, тоже от перефирии к центральной доменной зоне:
- прописываем дополнительные сервера на DNS клиентах сети, и проверяем разрешение имён, при отключённых первичных серверах.
Вот по сути и все настройки.
Отдельно встаёт вопрос проверки синтаксиса файлов описания доменных зон. Если файлы конфигурации сервера являются текстовыми, и доступны для проверки утилитой named-checkconf. То загруженные копии файлов описания зон представляют собой двоичные файлы, и утилита named-checkzone проверить эти файлы не сможет, т.е. она выдаёт одну сплошную ошибку
В этой ситуации мне показалось удобным использовать утилиту rndc dumpdb -all, которая выгружает в файл всю базу данных сервера, к которому она привязана. Файл обычно я находил по этому пути /var/cache/bind (именно этот путь прописан в параметре directory в файле конфигурации named.conf.options, интересное совпадение)). Открываем файл и просматриваем всё что там есть, и если находим описание доменной зоны с соответствующего первичного сервера, значит вторичный сервер загрузил этот файл удачно. Если не находим описание нужной зоны, значит смотрим логи, читаем доки, и другими способами пытаемся выяснить почему наш вторичный сервер не загружает данные с нашего первичного сервера. Аналогичным образом проверяем как удачно изменения сделанные на первичном сервере реплицируются на вторичный сервер.
Теперь проведём небольшой эксперимент - проверим как обычный хост будет разрешать имя из удалённой от него доменной зоны.
Для начала погасим центральные доменные сервера deb-lan3-bind-prim.loc. и deb-lan3-bind-scnd.loc. (командой poweroff). Для того, чтобы они случайно не зареплицировали наш эксперимент. Потом на сервере deb-lan4-bind-prim.lan4.loc. добавим ложный хост empty-host108.lan4.loc. c адресом 192.168.4.108. Т.е. такой хост, который прописан в DNS системе, но которого реально не существует. При этом вспомним изменить серийный номер в записи SOA прямой и обратной зон.
На всякий случай попробуем запросить добавленное имя у сервера deb-lan4-bind-prim.lan4.loc. c тестового хоста deb-lan2-host101.loc., и ожидаемо получаем отчёт об отсутствии такого хоста. Что не удивительно - мы же ещё базу данных не обновили.
Теперь обновим базу данных имён сервера deb-lan4-bind-prim.lan4.loc. (rndc reload)
И сразу повторим запрос с хоста deb-lan2-host101.loc.
И видим что сервер deb-lan4-bind-prim.lan4.loc. разрешил новое имя.
И вторичный сервер deb-lan4-bind-scnd.lan4.loc. доменной зоны "lan4.loc." тоже разрешил это имя, хотя мы на нём никаких действий не выполняли.
Теперь погасим первичный deb-lan4-bind-prim.lan4.loc. сервер зоны "lan1.loc." , для пущей чистоты эксперимента (тоже poweroff). И для проверки попробуем разрешить новое имя на хосте deb-lan2-host101.loc. при выключенных его DNS серверах (а они пока и не включались). Ожидаемо получим отчёт об отсутствии серверов для этого хоста.
Теперь включим сервер deb-lan3-bind-scnd.loc. вторичный для доменной зоны "loc.". Доменной зоны, в которой находится тестовый хост deb-lan2-host101.loc. И ещё раз выполним запросы нового имени. Сервер пока об этих именах ничего не знает. Но признаюсь, что в некоторых предыдущих версиях этого эксперимента вторичный сервер каким-то образом всё-таки разрешал прямой запрос на новое имя, и не разрешал обратный запрос по адресу этого имени. Какие тут зависимости пока не разобрался.
Теперь включаем сервер deb-lan4-bind-prim.lan4.loc. первичный для зоны "lan4.loc." , и опять повторяем запросы.
Видим, что запросы имён разрешаются разрешаются вторичным сервером deb-lan3-bind-scnd.loc. доменной зоны "loc.".
Т.е. на основании эксперимента можно заключить, что тестовый хост deb-lan2-host101.loc. передал запрос на разрешение имени вторичному серверу своей доменной зоны deb-lan3-bind-scnd.loc., который самостоятельно не смог запросить новое имя у вторичного сервера. Хотя вроде бы сервер deb-lan4-bind-scnd.lan4.loc. вторичный для доменной зоны "lan4.loc." это имя содержал (ну или реже тоже относилось только к запросам в обратные зоны). И запрос на новое имя не был разрешён до тех пор, пока не был включен сервер deb-lan4-bind-prim.lan4.loc. первичный для зоны "lan4.loc.", который ответил на запрос нового имени. И эти данные были переданы тестовому хосту deb-lan2-host101.loc.
На самом деле достаточно спорный вывод, возможно вопрос в правильности настройки серверов. Но на данный момент такое поведение сервиса DNS меня вполне устраивает.
Отдельной в канал MAX выложу значимые конфы обсуждаемых DNS серверов.
И буду считать возможным перейти к изучению других сетевых сервисов.
И на этом закончить данную статью.
Благодарю всех Уважаемых Читателей, дочитавших до этого места.
Желаю всем удачи в начинаниях и продолжениях, до новых встреч!!!)
PS
Статья не является учебным пособием, и представляет личный опыт автора.
Статья может содержать ошибки и не точности.
Приведённые данные необходимо проверять самостоятельно.
Текст написан автором лично без использования ИИ.
Картинка для превью статьи сгенерирована сетью Шедеврум, возможно с небольшими правками автора.
Канал MAX для всего того, что не поместилось на канал ДЗЕН.