У меня есть экземпляр BIND 9.6, который действует как кэширующий NS для всего здания, а также является авторитетным для внутренней зоны ("пример"ниже):
zone "example" {
type master;
file "example";
update-policy { grant dhcp-update subdomain example. A TXT; };
};
Из-за мошеннического коммутатора мы потеряли связь с остальным миром, и NS начал отвечать на SERVFAIL; что меня удивило, так это то, что сервер также не мог отвечать на запросы для пример домен.
В чем причина такого поведения? Разве NS не может ответить, поскольку у него есть достоверные данные?
edit: остальная часть конфигурации является стандартной, поставляемой с Debian: подсказки для корневых серверов и зон для localhost и широковещательной рассылки.
Вы можете включить отладку, чтобы убедиться, что это не дает прямого ответа на ваш вопрос. Однако я подозреваю, что разрешения для вашего файла зоны не позволяют пользователю привязки читать файл.
Я определяю все свои параметры ведения журнала в named.logging.conf, а затем использую включение в основной файл:
logging {
channel default_syslog {
// Send most of the named messages to syslog.
syslog local2;
severity debug;
};
channel audit_log {
// Send the security related messages to a separate file.
file "/var/named/system/named.log";
severity debug;
print-time yes;
};
channel null {
null;
};
category default { default_syslog; };
category general { default_syslog; };
category security { audit_log; default_syslog; };
category config { default_syslog; };
category resolver { audit_log; };
category xfer-in { audit_log; };
category xfer-out { audit_log; };
category notify { audit_log; };
category client { audit_log; };
category network { audit_log; };
category update { audit_log; };
category queries { audit_log; };
category lame-servers { null; };
};
а затем в named.conf:
root@dnsm02:/etc/bind# grep logging named.conf
include "/etc/bind/named.logging.conf";
Кроме того, вы не упоминаете представления, но если у вас есть определенные представления, тогда все ваши зоны должны быть в определенных представлениях.