BIND не отвечает авторитетно

Oct 01 2020

Я хочу использовать 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. У меня никогда раньше не было этой проблемы. Что еще я могу попробовать решить эту проблему?

Ответы

1 user1686 Oct 01 2020 at 23:00

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 (которые вы не запрашивали для , но сервер включил их, чтобы ускорить работу).