BIND не отвечает авторитетно
Я хочу использовать BIND в качестве общедоступного сервера имен для доменов компаний. Я использую новую установку сервера ubuntu 20.04.1 и BIND 9.16.1. Проблема в том, что BIND никогда не отвечает авторитетно. Я могу увидеть это с помощью dig. Чтобы определить местонахождение проблемы, я попробовал это с единственной минимальной зоной «example.com», но безуспешно. Файл зоны - db.example.com:
example.com. 86400 IN SOA ns1.example.com. hostmaster.example.com. (
1 ; Serial
900 ; Refresh
300 ; Retry
86400 ; Expire
600 ) ; Negative Cache TTL
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN MX 10 mail.example.com.
ns1.example.com. 86400 IN A 123.123.123.123
mail.example.com. 86400 IN A 125.125.125.125
Конечно, приведенные выше IP-адреса не являются настоящими IP-адресами, но IP-адрес для ns1.example.com является общедоступным IP-адресом системы, на которой работает BIND. named-checkzone им доволен. В named.conf.local добавляются только следующие строки:
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
};
named.conf.options:
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no;
listen-on { any; };
listen-on-v6 { any; };
recursion no;
};
Используя dig с ANY, я могу видеть все записи в файле зоны, но BIND всегда отвечает AUTHORITY: 0 . Также записи A отображаются не в разделе ответов, а в дополнительном разделе. К сожалению, мне не разрешено публиковать исходный результат dig, потому что он выглядит как спам. Зона настроена как главная, и запись NS указывает на IP-адрес сервера, на котором работает BIND. Другая мысль заключалась в том, что BIND может попытаться запросить example.com от root и знает, что на самом деле это не авторитетный сервер имен. Я также попробовал то же самое с доменом example.invalid, который на самом деле нигде не должен существовать. Результат был таким же, как и для example.com. У меня никогда раньше не было этой проблемы. Что еще я могу попробовать решить эту проблему?
Ответы
BIND всегда отвечает АВТОРИТЕТ: 0.
Это нормально, и это не значит, что ответ не был авторитетным. Напротив, этот раздел предназначен для хранения записей, которые сообщают клиенту, что полномочия находятся в другом месте - например, если вы запросили сервер имен, на котором размещена родительская comзона или даже корневая зона, вы получите ответ «реферал», содержащий Записи NS в этом разделе.
Насколько мне известно, настоящий авторитетный ответ никогда не должен содержать никаких записей в этом разделе.
Другими словами, вы смотрите не на ту часть вывода dig. Чтобы узнать, был ли ответ авторитетным или нет, посмотрите раздел «флаги» - aaфлаг ( авторитетный ответ ) является индикатором.
Также записи A отображаются не в разделе ответов, а в дополнительном разделе.
Это тоже нормально. Они не будут отображаться в разделе ответов, потому что в вашем example.comдомене нет записей A.
Однако у него есть некоторые типы записей (NS и MX), которые ссылаются на другое доменное имя, имеющее записи A. Обычно для их разрешения на фактические адреса требуется второй запрос, но DNS-сервер может дополнительно включить эти записи A / AAAA в раздел «Дополнительно».
Поэтому, когда вы запрашиваете dig example.com MX, в разделе ответов будут записи MX для example.com (т.е. именно то, что вы запросили), а в разделе Additional будут записи A / AAAA для mail.example.com (которые вы не запрашивали для , но сервер включил их, чтобы ускорить работу).