Установка - это два сервера 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, но похоже, что это не реплицируется между моими контроллерами домена, так что все в порядке.