Приветствую вас, Уважаемые Читатели!
Пришло время заняться самым интересным что может быть в системе доменов - делегированием. У нас заблаговременно заготовлен для делегирования целый сегмент сети с виндовым хостом и отдельным bind-сервером - LAN4.
Предполагается, что сервер deb-lan3-bind-prim будет обслуживать зону "loc.", которая содержит все хосты в сегментах LAN1, LAN2, LAN3. И этот же сервер будет делегировать управление зоной "lan4", которая будет содержать хосты в сегменте LAN4. И зону "lan4" будет обслуживать сервер deb-lan4-bind-prim. Т.е. deb-lan3-bind-prim будет делегирующим, а сервер deb-lan4-bind-prim будет делегируемым. Получается какая-то такая схема
При создании делегируемой зоны выполняем стандартные шаги.
Сначала ставим сервер BIND на делегируемый сервер deb-lan4-bind-prim.
При этом нужно будет настроить архивные депозитарии apt.
После установки прописываем общие настройки по серверу в файл named.conf.option. Прописываем локальные настройки делегируемой зоны в файл named.conf.local.
Создаём файл содержимого зоны по пути указанном в локальных настройках.
Проверяем конфигурацию утилитой named-checkconf.
Проверяем файл зоны утилитой named-checkzone.
Загружаем новую конфигурацию rndc reload.
При возможности выполняем контрольную перезагрузку сервера systemctl restart bind9.
После этого прописываем делегирующие записи на делегирующем сервере deb-lan3-bind-prim.
Делегирующую зону или сервер тоже перезагружаем.
После всех настроек и перезагрузок проверяем разрешение имён хостами.
Для начала настроим новый DNS сервер на виндовом хосте win-lan4-host101
и пингуем какой-нибудь удалённый хост, указа в качестве цели доменное имя этого хоста.
Если это получается пингуем с хоста из зоны "loc" хост из зоны "lan4.loc" (он пока что один).
Ну и на всякий случай просто выполним запрос на определение имени от хоста зоны "loc" к серверу, который эту зону обслуживает (deb-lan3-bind-prim).
Т.е. сервер deb-lan3-bind-prim, который не содержит записей зоны "lan4.loc." (но делегирует их) отвечает запрашивающему хосту на запрос по адресу хоста из зоны "lan4.loc.". Т.е. можно предположить, что получает он этот адрес от сервера deb-lan4-bind-prim. И это в свою очередь означает, что делегирование зоны "lan4.loc." функционирует.
Не буду описывать все свои приключения на пути описанном выше. Скажу только что пришлось использовать утилиту tcpdump, для понимания того куда конкретный сервер отправляет запросы, для разрешения того или иного имени. И знание это меня изменило.
А знание состояло в открытии для себя особенностей поведения параметра forwarding, который прописывается в файле named.conf.options. Оказалось, что если этот параметр выставлен, сервер абсолютно игнорирует то, что у него в файле зоны прописан адрес сервера, который отвечает за делегируемую зону (glue-запись). И запрос на разрешение имёни делегируемого сервера (deb-lan4-bind-prim.lan4.loc.) отправляет по адресу, который прописан в параметре forwarding. В моём случае это был внешний сервер, и он конечно ничего не знал о хостах моей внутренней сети. О чём честно и отвечал, запрашивающему серверу deb-lan3-bind-prim. А запрашивающий и делегирующий сервер успокаивался на этом ответе, и радостно рапортовал, что сведений о сервере (deb-lan4-bind-prim) обслуживающем делегируемую зону он не имеет. Соответственно делегирование зоны не включалось, и ничего о делегируемой зоне делегирующий сервер не знал.
И мне так и не удалось понять как изменить такое поведение, кроме как просто удалить этот параметр у делегирующего сервера. Как только был удалён этот параметр на сервере deb-lan3-bind-prim всё делегирование заработало.
Т.е. теперь в построенной среде получается, что делегирующий сервер deb-lan3-bind-prim разрешает имена своей зоны домена ("loc") исходя из файлов зон, прописанных на нём самом. Имена делегируемой зоны ("lan4.loc") делегирующий сервер разрешает путём запросов к делегируемому серверу deb-lan4-bind-prim первого уровня. А имена, которые не содержат ни та ни другая зона делегирующий сервер разрешает рекурсивными запросам к корневым серверам, что является правильным, потому что такие имена как раз и должны быть внешними создаваемой среде.
Но делегируемый сервер deb-lan4-bind-prim имеет параметр forwarding. Потому что если ему требуется разрешить имя, которое не содержит его зона, делегируемый сервер должен куда-то отправить запрос на это имя. И если это имя будет в области создаваемой среды, то корневые сервера не смогут ответить на этот запрос. А ответить на такой запрос сможет только сервер верхнего уровня в создаваемой среде, т.е. deb-lan3-bind-prim. Получается, что если придётся делегировать зону 2го уровня, то опять возникнут проблемы с делегированием, как и с сервером deb-lan3-bind-prim возникали, пока не был удалён параметр forwarding. Получается что могут возникнуть потенциальные проблемы при построении доменного дерева, произвольной вложенности.
Пока я не знаю как решить эту задачу. Возможно хорошим решением будет создание собственной корневой зоны для внутренних серверов среды. Но на данном этапе я не планирую создавать зоны глубже 1го уровня вложения, и представленное поведение меня вполне устраивает.
Наверное более глубокое погружение в тему построения DNS структуры могло бы мне помочь решить такую задачу, но впереди ещё много разных сетевых сервисов, и не хотелось бы тратить слишком много времени на чтение фолиантов (по 500 стр минимум)) по теме. Возможно вернусь к теме DNS и BIND позже более подробно. Буду очень благодарен, если кто-то из Уважаемых Читателей прояснит этот вопрос в комментариях.
Объёмы конфигурационных файлов хостов, о которых идёт обсуждение в статье стали достаточно большими. И мне показалось удобным выделить для эти текстов отдельную публикацию. Поэтому начиная с этой статьи попробую значимые конфигурационные файлы хостов, которые обсуждались, выкладывать в отдельной статье. Такие статьи предполагаю выкладывать сразу после тематической статьи, может быть с интервалом 1-2 дня.
Благодарю всех Уважаемых Читателей, дочитавших до этого места.
Желаю всем удачи в начинаниях и продолжениях, до новых встреч!!!)
PS
Статья не является учебным пособием, и представляет личный опыт автора.
Статья может содержать ошибки и не точности.
Приведённые данные необходимо проверять самостоятельно.
Картинка для превью статьи сгенерирована сетью Шедеврум, возможно с небольшими моими правками.