Назад | Перейти на главную страницу

Файл зоны Bind9 для одной машины?

Установка - это два сервера Active Directory с репликацией DNS на двух сайтах. Для «устаревших» целей мне нужно перенаправить запросы для ранее единственного файлового сервера на соответствующую копию каждого сайта. Например, 'BIGBOX' -> 192.168.100.2 для сайта A; 'BIGBOX' -> 192.168.200.2 для сайта B. Установка записи CNAME работает, но только до тех пор, пока не начнется репликация DNS ...

Оба AD DC используют установку bind9 для конкретного сайта либо в качестве сервера пересылки (Windows Server 2008r2 @ site A), либо компонента bind_dlz (Samba4 @ site B).

Я считаю, что должна быть возможность настроить зону BIGBOX.subnet.domain.com на любом компьютере BIND9, указывающем на соответствующую копию файлового сервера. Что-то вроде сценария с разделением горизонта, но без просмотров и только для одного адреса.

Если это имеет смысл, как бы выглядел такой файл зоны (NS, A-запись)?

Любые указатели [sic] приветствуются!

Я не уверен, правильно ли я понял вашу настройку. Если я вас правильно понял, у вас есть основной DNS в AD, и вы просто хотите обслуживать одну запись (bigbox) по-разному в зависимости от подсети.

Вы можете решить это следующим образом. В активном каталоге создайте делегацию (т.е. запись NS), указывающую на ваш сервер привязки для bigbox.domain.com.

На сервере привязки вы должны создать настройку на основе представления. Видеть https://kb.isc.org/article/AA-00851/0/Understanding-views-in-BIND-9-by-example.html для подробностей. Думаю, этот слегка измененный пример должен вас заинтересовать:

# named.example02.conf

acl subnetA { 192.168.7.0/24; localhost; };
acl subnetB   { 192.168.8.0/24; };

view subnetA {
    match-clients { subnetA; };

    allow-recursion { any; };

    zone "bigbox.example.com" {
        type master;
        file "subnetA/db.bigbox.example.com";
    };
};

view subnetB {
    match-clients { subnetB; };

    allow-recursion { any; };

    zone "bigbox.example.com" {
        type master;
        file "subnetB/db.bigbox.example.com";
    };
};

Затем просто создайте две зоны, состоящие только из SOA, NS и одной записи A. Единственная разница между ними должна заключаться в записи А! Сохраните как subnetA / db.bigbox.example.com и subnetB / db.bigbox.example.com.

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     bind.example.com. root.bigbox.example.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      bind.example.com.

;change this IP depending on view
bigbox     IN      A       192.168.1.21

Хорошо. У меня было время поиграть с этим в производственной среде, и вот что работает: авторитетный файл зоны bind9 для 'BIGBOX.ad-Domain.domain.com' в любой подсети с пустой записью A для соответствующего файла адрес сервера.

С сервером NS1 по адресу 192.168.100.0/24 это будет указывать на файловый сервер FS1 @ 192.168.100.2; сервер NS2 по адресу 192.168.200.0/24 указывает на FS2 @ 192.168.200.2. По сути, дополнительная запись A для воображаемого сервера к тем, которые уже существуют для моих реальных файловых серверов.

Один из моих контроллеров домена - это ящик Windows Server, который делегирует полномочия для BIGBOX NS1 (bind9 в Debian); другой работает под управлением Debian 9, а серверная часть bind9_dlz обрабатывает DNS. Опять же, среде Windows Server / bind9 требуется делегирование в Windows DNS, но похоже, что это не реплицируется между моими контроллерами домена, так что все в порядке.