У меня была установка с использованием более старой Bind, которая больше не работает, как только я начал использовать Bind9.9 ... named.conf все тот же, с активной рекурсией, а зона, которую я использую, не имеет пересылки. Однако я получаю сообщение об ошибке, что для NS отсутствует связующая запись, хотя она есть ... это то, чего не разрешает новый Bind; т.е. наличие NS в самом субдомене?
В старом Bind я использовал Red Hat, теперь использую CentOS7.
Вот файл зоны:
$TTL 86400
rd2t9g9.redes.intranet. IN SOA pc9-1-v1-9 root (
42 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
IN NS pc9-1-v1-9
pc9-1-v1-9 IN A 192.168.99.11
pc9-1-v2-9 IN A 192.168.99.12
area1 IN NS pc9-2-v2-9.area1
area1 IN NS duplicate
duplicate IN A 192.168.99.23
pc9-2-v2-9.area1 IN A 192.168.99.22
При запуске checkzone я получаю сообщение
zone rd2t9g9.redes.intranet/IN: area1.rd2t9g9.redes.intranet/NS 'pc9-2-v2-9.area1.rd2t9g9.redes.intranet' (out of zone) has no addresses records (A or AAAA)
zone rd2t9g9.redes.intranet/IN: loaded serial 42
OK
Файл точно такой же, как и при запуске старого Bind; он будет работать, если NS находится в домене (т.е. дублировать), но не позволит мне иметь NS в поддомене (но раньше!)
Любые идеи?
Также добавим файл named.conf:
options {
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; };
recursion yes;
dnssec-enable no;
dnssec-validation no;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
zone "rd2t9g9.redes.intranet" IN {
type master;
file "zone_A";
allow-update { none; };
forwarders { };
};
zone "99.168.192.in-addr.arpa" IN {
type master;
file "rev_zone";
allow-update { none; };
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
Вы пытаетесь использовать элементы area1.rd2t9g9.redes.intranet внутри rd2t9g9.redes.intranet.
Это ведет к named-checkzone жалуется, что есть элементы вне зоны, потому что сервер, на котором поддомен area1.rd2t9g9.redes.intranet, вероятно, еще не существует, и как таковой named-checkzone не может разрешить имена. Предупреждение исчезнет после правильной настройки поддоменов.
Конфигурация, которая у вас есть, должна работать, однако, поскольку известно, что более поздние версии BIND будут более строгими, я не могу поручиться за это. Один из способов избежать предупреждения - это удалить ".area1" и настроить таким образом для ваших целей.
$TTL 86400
@ IN SOA pc9-1-v1-9 root.localhost. (
42 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
IN NS pc9-1-v1-9
pc9-1-v1-9 IN A 192.168.99.11
pc9-1-v2-9 IN A 192.168.99.12
area1 IN NS pc9-2-v2-9
area1 IN NS duplicate
duplicate IN A 192.168.99.23
pc9-2-v2-9 IN A 192.168.99.22
Я также предпочитаю аббревиатуру @ вместо того, чтобы снова записывать зону, поскольку это сокращает количество ошибок при работе с несколькими зонами.
Я также изменил корень в SOA с root на root.localhost, поскольку RFC указывает, что это электронное письмо с "." собирается "@". Вы можете использовать свой собственный адрес электронной почты вместо root @ localhost.
Имейте в виду, что в BIND 9.9 есть несколько новых изменений, и одно, которое, вероятно, будет иметь значение в лабораторных условиях, состоит в том, что новые подчиненные файлы теперь находятся в необработанном / двоичном формате из соображений производительности. Если это необходимо в образовательных целях, BIND 9.9 можно настроить так, чтобы они оставались в текстовом формате.
Ничего не изменилось в том, что разрешено в этом отношении. Возможно named-checkzone имеет больше проверки, в зависимости от того, с какой более старой версией вы его сравниваете, или среда, в которой вы его запускаете, настроена по-другому.
Как название, что это NS точки записи находятся вне зоны, которую вы проверяете, named-checkzone ищет имя в DNS (используя настроенный в системе сервер распознавания).
Делает pc9-2-v2-9.area1.rd2t9g9.redes.intranet иметь адресную запись, если вы попытаетесь найти ее на том же хосте, где вы запускаете named-checkzone?
Т.е., делает dig pc9-2-v2-9.area1.rd2t9g9.redes.intranet A и / или dig pc9-2-v2-9.area1.rd2t9g9.redes.intranet AAAA дать положительный ответ?
Если нет, ожидается предупреждающее сообщение.
Если ты по какой-то причине не хочешь named-checkzone чтобы выполнить этот тип проверки (вы, вероятно, делаете, это настоящая проблема, если эти записи адреса отсутствуют на авторитетной стороне), существует -i вариант который можно использовать для указания другого режима проверки (например, -i local).