Надеюсь, это возможно.
Можно ли настроить DNS-сервер, который является авторитетным для данного домена, на «откат» и рекурсию через пересылку / корневые подсказки, когда он не может найти запись локально?
Чтобы дать конкретный сценарий, представьте частную (внутреннюю) сеть, которая обслуживается внутренним DNS-сервером с поддержкой Active Directory (10.10.10.10) для домена. poorlyplanned.com
Внутренние клиенты, которые запрашивают такие записи, как hostgroupA.poorlyplanned.com получить ответ от локального внутреннего DNS-сервера (10.10.10.10). Запросы от внутренних клиентов для других доменов рекурсивно разрешаются через внутренний DNS-сервер (10.10.10.10) с использованием серверов пересылки / корневых ссылок.
Кроме того, существует общедоступный DNS-сервер (на самом деле большие серверы с высокой степенью доступности с балансировкой нагрузки), скажем, на IP 1.2.3.4, и он является авторизованным для того же доменного имени poorlyplanned.com.
Внешние клиенты, которые запрашивают записи, отправляются напрямую на общедоступный DNS-сервер в 1.2.3.4 для разрешения. Например, публичный запрос для webserverX.poorlyplanned.com разрешается напрямую с общедоступного DNS-сервера 1.2.3.4 и возвращает, скажем, 50.51.52.53 клиенту. Когда я говорю решено напрямую, я имею в виду, что записи NS указывают на общедоступный DNS-сервер, и запрос не проходит через внутренний сервер (в любом случае он недоступен для всех).
Внутренний DNS заполняется частными записями DNS для poorlyplanned.com которые не предназначены для публичного разрешения, тогда как внешний DNS заполняется общедоступными записями DNS (для того же домена), которые должны быть разрешены публично.
Пока что довольно стандартный DNS, хотя, возможно, не идеальный.
Внутренние клиенты не могут разрешать общедоступные записи DNS, например webserverx.poorlyplanned.com потому что эти записи не определены на внутреннем DNS-сервере. Поскольку внутренний DNS-сервер является авторизованным для того же poorlyplanned.com домен, он просто возвращает результат «DNS-запись не найдена» после просмотра только внутренних записей - как обычно это делает авторизационный DNS-сервер.
Ограничение, которое у нас есть, состоит в том, что общедоступный DNS-сервер администрируется третьей стороной и имеет частый отток, что делает очень сложной задачей вручную поддерживать дублирующийся набор записей на внутреннем DNS-сервере, не теряя при этом мяч.
В качестве обходного пути мы попытались добавить дополнительные записи сервера поиска DNS на стороне клиента, указывающие на внешние DNS-серверы (в попытке дополнить внутренние DNS-серверы), но это не сработало, потому что оба являются авторитетными, и клиент не пытается последующие серверы в списке после возврата с результатом.
Раздельные или горизонтальные конфигурации невозможны либо потому, что оба сервера содержат одинаковые записи DNS, только с разными IP-адресами, либо могут совместно использовать файлы зон.
Однако, если бы было возможно рекурсивно разрешить внутренний DNS-сервер с помощью перенаправителя / корневых подсказок, когда он не может найти запись локально, это сработало бы. Но как?
Я понимаю, что если внутренний домен изначально был настроен с некоторым смещением поддомена, например int.poorlyplanned.com тогда у нас нет проблем. К сожалению, масштаб уже развернутых ресурсов и задействованных сайтов недопустимо для такого изменения.
Неужели это не уникальная проблема?
Надеюсь, я выразился достаточно ясно - пожалуйста, дайте мне знать, если я могу помочь уточнить.
Спасибо за чтение / помощь!
Это действительно не уникальная проблема. Наверное, есть два обычно используемых "решения":
app.example.com для внутреннего размещения потребуется внешний общедоступный IP-адрес, но, возможно, внутренний IP-адрес. Теперь, когда автоматизация - это ажиотаж, вы захотите изучить ее автоматизацию, если вам часто придется изменять эти общедоступные IP-адреса в обоих местах. Если ваш текущий провайдер хостинга DNS плохой (плохое качество или отсутствие API для автоматизации), вы можете просто переключиться на другого провайдера.example.com и ваши общедоступные серверы используют этот домен, например www.example.com и mail.example.com тогда ваша внутренняя сеть может использовать ad.example.com если вы используете Windows Active Directory, или comp.example.com или что угодно. Внутренние ресурсы будут жить в этом пространстве имен и общедоступные (например, www.example.com) будет перенаправлен вашему провайдеру общедоступного DNS. Таким образом, вам не нужно реплицировать записи DNS.У обоих решений есть свои плюсы и минусы. Могут существовать и другие решения.
Невозможно настроить полномочный DNS-сервер для пересылки запроса, если он не находит ответа в своей базе данных. «Авторитетный» означает, что он знает о зоне все. Вы можете настроить определенные пересылки, например:
zone "example.com" {
type master;
file "...";
};
zone "www.example.com" {
type forward;
forwarders { 203.0.113.53; };
};
zone "mail.example.com" {
type forward;
forwarders { 203.0.113.53; };
};
Если внешний DNS использует BIND Следующий файл конфигурации является лишь примером того, как решить проблему.
acl localnet { 1.2.3.4/24; }; <---- this is the range of your public ip addresses
view internal {
match-clients { localnet; };
allow-recursion { any; };
zone "myzone.example" {
type master;
file "external.db.myzone.example"; <--- in this file put all your internal and external records
even if they have local ip addresses
};
};
};
view external {
match-clients { any; };
allow-recursion { any; };
zone "myzone.example" {
type master;
file "internal.db.myzone.example"; <--- in this file put all just your external records
};
};
};
};