☰

bind9: переадресация на локальный сервер имен не работает при отсутствии интернет-соединения

tag-icon • tag-icon domain-name-system bind dns-zone forwarding
bind9: переадресация на локальный сервер имен не работает при отсутствии интернет-соединения

У меня следующая настройка:

Экземпляр bind9 (далее именуемый L) на очень ограниченном оборудовании для разрешения имен в моих локальных сетях. Это авторитетный мастер для зоны home.mydomain.com. Запросы к этому серверу работают и возвращают homedns.home.mydomian.com как NS и его IP 192.168.1.77 как дополнительную запись.

Экземпляр bind9 (ниже именуемый M) для разрешения интернет- и локальных имен. Здесь не используется глобальная опция пересылки. Настроена зона пересылки:

zone "home.mydomain.com" in {
        type forward;
        forward only;
        forwarders { 192.168.1.77; };
};

Примечание 1: mydomain.com — существующий зарегистрированный домен, но для home.mydomain.com нет записи.

Примечание 2: Версия M для bind9 очень старая: 9.8.1-P1

Эта настройка работает, пока есть подключение к Интернету, но запросы локального имени не отвечают, когда соединение отсутствует. Журнал syslog

Aug 30 09:05:42 M named[1611]: error (no valid DS) resolving 'xxx.home.mydomain.com/A/IN': 192.168.1.77#53

Захват сети для успешного разрешения при установленном соединении показывает, что M запрашивает mydomain.com в Интернете после получения ответа от L. В ответе от M клиенту РАЗДЕЛ AUTHORITY изменяется:

копать до L:

;; ANSWER SECTION:
syslog.home.mydomain.com. 3600  IN      A       192.168.1.99

;; AUTHORITY SECTION:
home.mydomain.com.        3600  IN      NS      homedns.home.mydomain.com.

;; ADDITIONAL SECTION:
homedns.home.mydomain.com. 3600 IN      A       192.168.1.77

копать до M:

;; ANSWER SECTION:
syslog.home.mydomain.com. 2134  IN      A       192.168.1.99

;; AUTHORITY SECTION:
net.                    171334  IN      NS      j.gtld-servers.net.
net.                    171334  IN      NS      m.gtld-servers.net.
net.                    171334  IN      NS      i.gtld-servers.net.
net.                    171334  IN      NS      k.gtld-servers.net.
net.                    171334  IN      NS      g.gtld-servers.net.
net.                    171334  IN      NS      e.gtld-servers.net.
net.                    171334  IN      NS      h.gtld-servers.net.
net.                    171334  IN      NS      a.gtld-servers.net.
net.                    171334  IN      NS      d.gtld-servers.net.
net.                    171334  IN      NS      f.gtld-servers.net.
net.                    171334  IN      NS      b.gtld-servers.net.
net.                    171334  IN      NS      c.gtld-servers.net.
net.                    171334  IN      NS      l.gtld-servers.net.

Я не понимаю, почему M просто не возвращает ответ от L клиенту, и у меня не осталось никаких идей, как я мог бы попытаться избежать запроса в Интернет для переадресованной зоны.

решение1

Запись журнала, указанная в вопросе, предполагает, что ошибка связана с неудачной проверкой DNSSEC при отсутствии подключения к Интернету.

Обратите внимание на часть сообщения об ошибке «нет допустимого DS»:

Aug 30 09:05:42 M named[1611]: error (no valid DS) resolving 'xxx.home.example.com/A/IN': 192.168.1.77#53

Предположительно, ответы на запросы, попадающие в эту зону прямого доступа, обычно принимаются только потому, что публичная example.comзона существует как неподписанная зона (т. е. есть доказательство «нет» DSкак часть делегирования соответствующей example.comзоны), но когда это доказательство больше не может быть получено из-за отсутствия подключения к Интернету, ответы больше не могут быть приняты, поскольку больше невозможно проверить, должны ли они быть подписаны и как именно.

Одним из вариантов было бы подписать home.example.comзону и добавить статичныйякорь доверияспециально для этой зоны.

Другой вариант — выборочно отключить проверку; в текущем BIND естьvalidate-exceptопция, позволяющая указать список доменных имен, для которых не должна выполняться проверка, согласно:

validate-except

Это определяет список доменных имен, на которых и ниже которых не должна выполняться проверка DNSSEC, независимо от наличия якоря доверия на этих именах или выше. Это может быть использовано, например, при настройке домена верхнего уровня, предназначенного только для локального использования, чтобы отсутствие безопасного делегирования для этого домена в корневой зоне не приводило к сбоям проверки. (Это похоже на установку отрицательного якоря доверия, за исключением того, что это постоянная конфигурация, тогда как отрицательные якоря доверия истекают и удаляются по истечении заданного периода времени.)

Также существует возможность полного отключения проверки с помощьюdnssec-validationвариант, который я бы не рекомендовал, если этот экземпляр BIND имеет более широкое применение, чем этот конкретный переадресатор.

(Обратите внимание, я заменил доменное имя, использованное в вопросе, на , example.comпоскольку маловероятно, что вопрос имеет какое-либо отношение к доменному имени, на которое он ссылается, или к компании, которой оно принадлежит.)

Связанный контент