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, повністю обходить цю схему, а вимкнення перевірки, щоб неочікувана відповідь виглядала правильною, міняє видимий збій на невидимий.

Запишіть, який із трьох типів ви обрали і чому. Наступній людині, яка побачить збій зони, ця фраза знадобиться більше, ніж файл конфігурації.

Схожі статті