нужен совет по архитектуре Bind9

Мне нужны ваши советы по архитектуре DNS.

Эта схема описывает архитектуру DNS, которую я думаю построить:

DNS-архитектура

В моей компании все настольные компьютеры/ноутбуки настроены на DNS локальной сети (10.1.1.1), который является Microsoft AD/DNS, и я не имею к этому никакого отношения. Другие DNS — это Bind9, где я являюсь администратором.Моя цель - добавить другие DNS-серверы для новых проектов (в отдельной сети) без каких-либо изменений на ноутбуках и в DNS в локальной сети, и, конечно же, я хочу, чтобы ноутбуки разработчиков (в локальной сети) могли запрашивать и получать ответ для fqdn этих новых проектов .

С точки зрения DNS (fqdn) существует ОДИН домен (project.com) и МНОЖЕСТВО поддоменов (subX.project.com). И каждый поддомен находится в отдельной сети.

Пример: в каждом vlan у меня будет веб-сервер, и я хочу, чтобы он отвечал на свой субдомен DNS:

web.project.com --> для веб-сервера зоны проекта.
web.sub1.project.com --> для веб-сервера зоны подпроекта
web.sub2.project.com ....

Итак, мое понимание Bind9 позволяет мне думать, что DNS-сервер локальной сети (10.1.1.1) может перенаправлять запросы на DNS-сервер проекта (10.100.1.1). А DNS проекта может перенаправлять запросы на DNS-серверы подпроекта (10.200.1.1/10.250.1.1).

Наконец, все виртуальные машины сети могут разрешать общедоступное полное доменное имя, если DNS зоны перенаправляет свои запросы в DNS верхнего уровня. Я просто хочу повторить, что у меня нет доступа к основному DNS (в локальной сети).

Ниже вы найдете named.conf.options файл, который представляет архитектуру, описанную в схеме:

• DNS-проект.com (10.100.1.1/10.100.1.2)

{
    разрешить-запрос { 127.0.0.1; 10.1.1.1; 10.1.1.2; 10.200.1.1; 10.200.1.2; 10.250.1.1; 10.250.1.2; 10.100.1.0/24; };
    рекурсия да;
    уведомлять да;
    разрешить передачу { 10.100.1.2; }; # раб
    экспедиторы {
        10.1.1.1;
        10.1.1.2;
    };
}

• DNS sub1.project.com (10.200.1.1/10.200.1.2)

{
    разрешить-запрос { 127.0.0.1; 10.100.1.1; 10.100.1.2; 10.200.1.0/24; }; запросы от ВМ в этой сети и DNS из верхней зоны
    рекурсия да;
    уведомлять да;
    разрешить передачу { 10.200.1.2; };
    экспедиторы {
        10.100.1.1;
        10.100.1.2;
    };
}

• DNS sub2.project.com (10.250.1.1/10.250.1.2)

{
    разрешить-запрос { 127.0.0.1; 10.100.1.1; 10.100.1.2; 10.250.1.0/24; }; запросы от ВМ в этой сети и DNS из верхней зоны
    рекурсия да;
    уведомлять да;
    разрешить передачу { 10.250.1.2; };
    экспедиторы {
        10.100.1.1;
        10.100.1.2;
    };
}

Что вы думаете об этой архитектуре? Видите ли вы какие-либо недостатки, ошибки или непонимание?

С уважением.

Моя цель - добавить другие DNS-серверы для новых проектов (в отдельной сети) без каких-либо изменений на ноутбуках и в DNS в локальной сети, и, конечно же, я хочу, чтобы ноутбуки разработчиков (в локальной сети) могли запрашивать и получать ответ для fqdn этих новых проектов .

Просто сделайте так, чтобы ваши основные DNS-серверы делегировали через NS записи, субдомен вроде project1.example.com на ваши серверы имён, после чего вы управляете этой зоной (отсюда и всё ниже). И обычное рекурсивное поведение во время разрешения имен срабатывает без какой-либо специальной настройки.

Кажется, вы путаете рекурсивную и авторитарную роли серверов имен. Эти не смешиваются. Вам следует избегать (хотя технически вы можете, с помощью программного обеспечения, такого как dnsmasq или даже несвязанный) сервер, действующий как рекурсивный в целом, но авторитетный для некоторых имен. Делайте правильные делегирования и получайте осмысленное дерево, и у вас не будет никаких странных проблем. Вы должны избегать запросов «вперед» насколько это возможно.

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