Две площадки, одна частная зона 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 сообщает, считает ли жёлтый распознаватель себя авторитетным, опрашивает вторичный или просто пересылает. Это разные проекты с разными режимами отказа, и ответ обычно показывает, какой именно вы развернули.

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