Я работаю над проектом по настройке DNS-сервера Bind9 в сети с подсетью 255.255.252.0.
В настоящее время способ его настройки делает невозможным запуск nslookup с 192.168.1.101/22 через ns1 @ 192.168.1.61/22 в сети 192.168.0.0/22 со шлюзом 192.168.1.1/22. Не спрашивайте, почему я начал использовать адрес 192.168.1.1, а не 192.168.0.1. Я только что сделал. Легче ввести две единицы подряд, но требуется дополнительное адресное пространство. Я помещаю свои клиенты dhcp wifi в диапазон .2.1-255 и запускаю vms в диапазоне .3.1-255. Дело в том, что кажется, что Bind думает, что все адреса @ 192.168.1.0-255 находятся в отдельной зоне / 24.
Это вызывает вопрос, неужели 0.168.192. обратная зона выглядит как подсеть / 24 по умолчанию в Bind? А как насчет 168.192. обратная зона? Все ли / 16 зон нужно привязать?
Это возвращает меня к моему первоначальному вопросу.
Несмотря на все ошибки в моей конфигурации Bind, было бы неплохо знать, что я должен делать, чтобы исправить их, как мне достичь того, что я хочу сделать?
Как вы запрограммируете Bind для размещения / 22, / 21 или любой нестандартной битовой зоны?
Вот мой файл обратной зоны в исходном виде.
$ttl 38400
0/22.0.168.192.in-addr.arpa. IN SOA ns.fqdn.com. user.emai.com. (
1489024990
10800
3600
604800
38400 )
61.1.168.192.in-addr.arpa. IN NS ns.fqdn.com.
61.1.168.192.in-addr.arpa. IN PTR ns.fqdn.com.
1.1.168.192.in-addr.arpa. IN PTR fw.fqdn.com.
62.1.168.192.in-addr.arpa. IN PTR ws.fqdn.com.
63.1.168.192.in-addr.arpa. IN PTR multi.fqdn.com.
25.1.168.192.in-addr.arpa. IN PTR fs.fqdn.com.
110.1.168.192.in-addr.arpa. IN PTR thncl.fqdn.com.
Следующие ошибки были обнаружены в файле конфигурации BIND /etc/bind/ named.conf или файлах зон, на которые имеется ссылка.
zone fqdn.com/IN: NS 'fqdn.com' has no address records (A or AAAA)
zone fqdn.com/IN: not loaded due to errors.
_default/fqdn.com/IN: bad zone
/var/lib/bind/192.168.0.rev:2: SOA record not at top of zone (0/22.0.168.192.in-addr.arpa)
/var/lib/bind/192.168.0.rev:9: ignoring out-of-zone data (61.1.168.192.in-addr.arpa)
/var/lib/bind/192.168.0.rev:10: ignoring out-of-zone data (1.1.168.192.in-addr.arpa)
/var/lib/bind/192.168.0.rev:11: ignoring out-of-zone data (62.168.192.in-addr.arpa)
/var/lib/bind/192.168.0.rev:12: ignoring out-of-zone data (63.1.168.192.in-addr.arpa)
/var/lib/bind/192.168.0.rev:13: ignoring out-of-zone data (25.1.168.192.in-addr.arpa)
/var/lib/bind/192.168.0.rev:14: ignoring out-of-zone data (110.1.168.192.in-addr.arpa)
zone 0.168.192.in-addr.arpa/IN: loading from master file /var/lib/bind/192.168.0.rev failed: not at top of zone
zone 0.168.192.in-addr.arpa/IN: not loaded due to errors.
_default/0.168.192.in-addr.arpa/IN: not at top of zone
При этом единственное, что я могу придумать, - это расширить зону до 168,192. zone и поместите ACL, который ограничивает поиск подсети / 22, оставляя файл зоны развернутым и открытым.
Любая помощь приветствуется, друзья сервера!
Со схемой, определенной для сопоставления адресов IPv4 с обратными именами DNS, а именно 192.0.2.17 становится 17.0.2.192.in-addr.arpa, невозможно делать делегации, которые не на /8, /16 или /24 границы (или для одного адреса, /32 если вы будете).
Для более чем /24 сетей, вы просто делегируете несколько зон ближайшего меньшего размера.
Например, /22 сеть будет четыре последовательных /24 зоны.
Например 10.7.56.0/22 было бы 56.7.10.in-addr.arpa + 57.7.10.in-addr.arpa + 58.7.10.in-addr.arpa + 59.7.10.in-addr.arpa.
Для менее чем /24 сетей, что-то вроде умного взлома (определено в rfc2317), где в родительской зоне CNAME записи добавляются для имен, принадлежащих каждому индивидуальному IP-адресу меньшей сети, указывая все это на новое пространство имен, а затем вместо этого делегируя это пространство имен.