Два майданчики, одна приватна зона DNS: кому належать записи?

Ви додаєте хост на зеленому майданчику, він розв'язується для зелених користувачів, а жовтий офіс досі отримує NXDOMAIN. Це не збій VPN і не зламаний розв'язувач; це прогалина у власності всередині приватної зони. Два незалежно редаговані списки записів не стають однією зоною лише тому, що майданчики можуть дістатися один одного. Рішення — план публікації, а не ще одне правило брандмауера.

Симптом називає відсутнього власника

Ймовірно, на кожному майданчику є локальне перевизначення, запис Pi-hole або рядок dnsmasq, який хтось додав, коли знадобилося ім'я. Зелений запис існує лише на зеленому розв'язувачі, тому клієнт на жовтому питає свій розв'язувач і отримує правдиве «такого імені немає». Застаріла відповідь виглядає інакше: хост переїхав, один майданчик оновив свою копію, а інший досі повертає стару адресу.

Жоден із шаблонів не виправляється надовго очищенням кешу. Кеш пересильного розв'язувача — це копія відповіді, отриманої колись, а не авторитет, що публікує нові імена, тому кеш, який працює сьогодні, нічого не каже про хост завтра. Документація BIND описує ролі первинного, вторинного, рекурсивного та пересильного сервера окремо саме з цієї причини.

Отже, питання проєктування вузьке й має відповідь: хто може створити запис і як цей запис доходить до кожного розв'язувача, який має за нього відповідати?

Варіант A: одна авторитетна зона з вторинними серверами

Запустіть первинний сервер для internal.example.com і дозвольте підтримуваним вторинним отримувати зону на кожному майданчику. Рекурсивний розв'язувач кожного майданчика питає свій локальний вторинний, тож відповіді надходять з авторитетного джерела, а не з кешу, і зміна, зроблена один раз, передається, а не вводиться заново.

Така схема потребує явних рішень, які легко відкласти й дорого пропустити. Хто може редагувати зону? Яким серверам дозволено її передавати і через які адреси? Що мають бачити клієнти, поки тунель між майданчиками недоступний? Вторинний продовжує відповідати зі своєї останньої копії, що зазвичай і потрібно, але це має бути оголошений вибір, а не сюрприз під час збою.

Обмежте передачі зони відомими вторинними серверами за адресою та використовуйте підписи транзакцій там, де реалізація їх підтримує. Відкрита передача — це копія вашого внутрішнього простору імен для будь-кого, хто дістанеться до порту.

Ціна — координація: один шлях редагування, один огляд змін і спільне розуміння того, хто на чергуванні, коли запис неправильний.

Варіант B: піддомен для кожного майданчика

Делегуйте green.internal.example.com зеленому майданчику, а yellow.internal.example.com — жовтому. Кожен майданчик стає авторитетним для своїх імен, а батьківська зона несе лише записи делегування. Суперечка за один файл зникає, і місцева команда може додати хост, не чекаючи центральної зміни.

Делегування має існувати в батьківській зоні, із записами NS, що вказують на авторитетні сервери майданчика. Умовна пересилка для піддомену — слушна альтернатива, коли повне делегування непрактичне, але це налаштування розв'язувача, а не опублікований факт, тож кожному розв'язувачу потрібне те саме правило.

Ціна переміщується, а не зникає: батьківській зоні все ще потрібен власник, а створення нового майданчика тепер зміна у двох місцях замість одного.

Нехай кожен розв'язувач дотримується вибору

Дайте клієнтам затверджений розв'язувач і домен пошуку через їхню підтримувану конфігурацію і переконайтеся, що розв'язувач має дозволений маршрут VPN до будь-якого віддаленого DNS-сервера, який йому треба опитати. Застосункам також потрібні маршрути до приватних адрес, які повертають ці відповіді, бо правильне ім'я без шляху — це все ще обірване з'єднання.

Якщо Pi-hole забезпечує локальне розв'язання, запишіть, якими записами він володіє і які запити пересилає. Два незалежно редаговані списки Pi-hole досі не реплікуються. У Pi-hole v6 власні рядки dnsmasq задаються опціями на боці хоста, як-от TOML, CLI або змінні середовища, і не розкриваються через API; завантаження файлів із /etc/dnsmasq.d/ — окрема опція, вимкнена за замовчуванням.

Потім перевірте з обох боків іменем, яке має бути видно всюди:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

Відповідь SOA каже, чи вважає жовтий розв'язувач себе авторитетним, чи опитує вторинний, чи просто пересилає. Це різні проєкти з різними режимами відмови, і відповідь зазвичай показує, який саме ви розгорнули.

Завершіть трьома випадками приймання: ім'я з кожного майданчика, запис, змінений протягом години, і недоступний зв'язок між майданчиками. Проєкт, що проходить лише перший, має план публікації на папері та локальне перевизначення у виробництві.