BIND через VPN: условная пересылка или stub-зона?

Три способа разрешить одну частную зону через VPN и когда подходит каждый: forward, stub или secondary, плюс проверка адреса источника, которая всё решает.

Ваш офисный resolver отвечает на всё, кроме одного корпоративного пространства имён, а корпоративный DNS-сервер, который его знает, находится за VPN. BIND может передать эту единственную зону upstream тремя разными способами, и отказывают они по-разному. Условная пересылка — наименьшее обязательство, stub-зона хранит данные делегирования, а secondary хранит полную копию. Выбирайте по тому, что разрешит upstream и что вы хотите, чтобы resolver держал, а не по тому, какой фрагмент вы нашли первым.

Три схемы для одного пространства имён

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

Условная пересылка: наименьшее обязательство

Предположим, офисный resolver на 192.168.10.53 и корпоративный сервер на 10.40.0.53, доступный через одобренный туннель. Объявление — три строки, и интересна forward only, потому что она меняет поведение при отказе, а не путь.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

С forward only недоступный upstream выдаёт SERVFAIL для этой зоны вместо возврата к итеративному разрешению. Для частного пространства имён обычно нужно именно это, ведь возврат отправил бы частные имена публичному resolver и вернул бы бесполезный ответ из интернета. Документация BIND описывает обе политики, и разница важнее, чем подсказывает фрагмент. Включите зону в существующую конфигурацию, а не заменяйте зону, которая уже существует для того же имени.

Stub или secondary: когда делегирование важно

Stub-зона запрашивает у корпоративного сервера NS-записи зоны, а затем напрямую опрашивает авторитетные серверы. Выбирайте её, когда регион upstream большой или разделён и вы хотите, чтобы resolver следовал делегированию, а не прибивал всё к одному адресу. Цена — зависимость от актуальности NS-данных и от доступности каждого перечисленного сервера имён с адреса источника вашего resolver.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

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

Проверка, которая решает между ними

BIND сам формирует свой исходящий запрос, поэтому вопрос не в том, дотянется ли ноутбук до 10.40.0.53, а в том, дотянется ли хост resolver с адреса источника, который увидит корпоративный сервер. Спросите ядро, затем спросите сервер, именно в таком порядке.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Разрешите UDP и TCP на пути: усечённый ответ вынуждает TCP, а политика, разрешающая только UDP, даёт периодические сбои, похожие на потерю пакетов. Корпоративной стороне нужны и правило приёма для источника вашего resolver, и обратный маршрут к нему; этим источником может быть маршрутизируемый адрес resolver или явно транслируемый адрес, и это редко адрес клиентского пула. Если NS-запрос не проходит, stub-зона не работает, как бы ни вела себя forward-зона.

Проверяйте ответ, а не туннель

Спросите через офисный resolver имя, которое вы никогда не запрашивали, и посмотрите на раздел authority ответа, чтобы понять, пришёл ли он из корпоративной зоны. Ответ из кэша ничего не доказывает про текущий путь, а успешный прямой запрос к upstream не доказывает, что resolver выбрал именно эту зону. Повторите тот же запрос по TCP, чтобы убедиться, что путь переживает усечение.

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

Запишите, какой из трёх типов вы выбрали и почему. Следующему человеку, который увидит отказ зоны, эта фраза понадобится больше, чем файл конфигурации.

Похожие статьи