Internal DNS (внутренний DNS) — DNS-сервер, разрешающий имена ресурсов внутри закрытой сети: корпоративной, локальной или облачной. При помощи него удается обращаться к серверам и сервисам по понятным именам вместо IP-адресов. Внутренние имена не обязательно публикуются в интернете. Вместо обращения к серверу по адресу 10.0.0.15 сотрудники могут использовать files.corp или git.internal. Для небольшой сети это может быть просто удобством, а для крупной инфраструктуры — необходимой частью архитектуры.
Чем internal DNS отличается от публичного DNS
Публичный DNS обслуживает доменные имена, доступные из интернета. Когда пользователь вводит адрес сайта, его DNS-резолвер получает информацию о соответствующих публичных записях. Internal DNS работает внутри определённой сети. Его зона и записи предназначены для внутренних клиентов, а сам сервер не должен быть доступен для произвольных запросов из интернета.
Характеристика | Публичный DNS | Internal DNS |
Назначение | Разрешение публичных доменных имён | Разрешение внутренних имён и сервисов |
Доступность | Обычно доступен из интернета | Доступен только из доверенной сети |
Кто использует | Пользователи и устройства из интернета | Клиенты конкретной сети |
Пример | example.com - 203.0.113.10 | git.corp - 10.0.0.15 |
У internal DNS записи описывают серверы, базы данных, внутренние панели, файловые хранилища, принтеры и другие ресурсы, которым вообще не требуется публичное доменное имя. Но это не говорит о том, что внутренние имена автоматически защищены от любого обнаружения. Безопасность зависит от настройки DNS-сервера, сетевого доступа, ACL, firewall и других механизмов. Сам факт использования internal DNS не является полноценной защитой сети.
Что такое split-horizon DNS
Отдельный распространённый сценарий — split-horizon DNS, также называемый split DNS. Один и тот же домен при этом может разрешаться по-разному в зависимости от того, откуда пришел DNS-запрос.
Внутри сети: app.example.com - 10.0.0.20
Из интернета: app.example.com - 203.0.113.20
Сотрудник компании внутри сети попадает непосредственно на внутренний сервер, а внешний пользователь получает публичный адрес. Это позволяет использовать одно доменное имя для внутреннего и внешнего доступа, не публикуя внутренний IP-адрес в публичной DNS-зоне.
Как работает internal DNS-сервер
В простейшем варианте internal DNS — это обычный DNS-сервер с собственной зоной для внутренних имен.
В локальной сети могут существовать:
router.home
nas.home
server.home
git.corp
monitoring.corp
DNS-сервер хранит соответствующие записи и отвечает на запросы устройств, которым разрешено им пользоваться. Например, компьютер запрашивает: git.corp. Internal DNS находит эту запись в своей локальной зоне: git.corp - 10.0.0.15 и возвращает IP-адрес. Если же пользователь запрашивает внешний сайт: example.com внутренний сервер может передать запрос дальше — публичному DNS-резолверу. Такая схема называется DNS forwarding.
Получается, один internal DNS становится первой точкой обращения для клиентов сети:
Клиент отправляет DNS-запрос внутреннему серверу.
Internal DNS проверяет собственные зоны.
Если запись относится к внутреннему ресурсу, он отвечает самостоятельно.
Если имя внешнее, сервер при настроенном forwarding передает запрос другому DNS-резолверу.
Полученный ответ возвращается клиенту.
Это удобно: компьютерам и серверам не нужно самостоятельно решать, куда отправлять разные типы DNS-запросов.
Когда internal DNS действительно нужен
Корпоративная сеть с Active Directory
Для инфраструктуры Active Directory internal DNS — не просто дополнительное удобство. Windows-домен активно использует DNS для обнаружения контроллеров домена и других служб. Поэтому в корпоративной Windows-инфраструктуре DNS обычно является частью базовой архитектуры Active Directory. Внутренние компьютеры должны уметь находить контроллеры домена и необходимые сервисы по DNS-именам.
Именно здесь идея «можно везде прописать IP-адреса» быстро перестаёт работать: инфраструктура становится слишком большой, а адреса могут меняться.
Микросервисы, Docker и Kubernetes
В микросервисной инфраструктуре десятки или сотни компонентов постоянно взаимодействуют друг с другом. Представим приложение из нескольких сервисов: frontend - api - database - redis
Если каждый сервис будет обращаться к другому по IP-адресу, изменение адреса потребует обновлять конфигурацию зависимых компонентов.
Гораздо удобнее использовать имена: api - database - redis
Docker предоставляет собственные механизмы DNS для обнаружения контейнеров и сервисов, а Kubernetes имеет встроенное DNS-обнаружение сервисов. Поэтому здесь internal DNS может быть частью более широкой системы service discovery, а не обязательно отдельным сервером BIND9. Главная идея остаётся прежней: сервису важнее знать стабильное имя зависимости, чем её текущий IP-адрес.
Домашняя лаборатория и self-hosted-инфраструктура
Internal DNS особенно удобен в домашней лаборатории, где несколько серверов, виртуальных машин и сетевых устройств.
Например:
nas.home;
pve.home;
grafana.home;
git.home;
docker.home.
Вместо запоминания нескольких IP-адресов пользователь обращается к сервисам по именам. Это полезно и для self-hosted-проектов. Собственный DNS-сервер можно развернуть, например, на базе BIND9, dnsmasq или Pi-hole. В облачной инфраструктуре для этого также можно использовать VPS с приватной сетью между инстансами, если выбранная платформа предоставляет соответствующую сетевую возможность.
Например, internal DNS может находиться на одном VPS, а несколько приложений — на других серверах в той же приватной сети. В таком случае внутренние имена позволяют связать компоненты инфраструктуры без необходимости делать их доступными через публичный интернет.
Изоляция внутренних сервисов от публичного DNS
Иногда сервис должен быть доступен сотрудникам или другим компонентам инфраструктуры, но публиковать его наружу не требуется.
Например:
grafana.corp
git.corp
database.corp
registry.corp
Если эти имена обслуживаются только внутренним DNS, их не нужно добавлять в публичную DNS-зону. Это уменьшает количество информации, публикуемой наружу, но не заменяет firewall, аутентификацию и контроль доступа. Если внутренний сервис доступен из недоверенной сети, одного internal DNS недостаточно для его защиты.
Когда internal DNS не нужен
Internal DNS не стоит устанавливать просто потому, что это считается «правильной» серверной практикой. Если у вас один VPS, один сайт и один домен, достаточно обычного публичного DNS. Домен можно направить на сервер через A-запись, а отдельный внутренний DNS-сервер в такой конфигурации добавит скорее лишний компонент, чем пользу.
То же самое относится к простой домашней сети с несколькими устройствами, если их вполне устраивает DNS от роутера или интернет-провайдера. Хороший критерий простой: если внутренних ресурсов мало и они не требуют централизованного разрешения имён, internal DNS может быть избыточным.
Какие программы чаще всего используют для internal DNS?
В зависимости от инфраструктуры применяются BIND9, dnsmasq, Windows DNS Server, Pi-hole и Unbound. У них разные задачи и возможности, поэтому выбор зависит от конкретной сети; для понимания самого internal DNS знать различия между ними необязательно.
Безопасен ли internal DNS сам по себе?
Нет. Internal DNS ограничивает область распространения DNS-записей, но не защищает сеть автоматически. Для безопасности нужны дополнительные механизмы: сегментация сети, firewall, ACL, аутентификация и контроль доступа.
Заключение
Internal DNS становится полезным, когда в сети появляется собственная инфраструктура, которую нужно связать понятными именами. Несколько серверов, внутренние сервисы, Active Directory, контейнеры, виртуальные машины и self-hosted-приложения — всё это типичные ситуации, где DNS-имена удобнее и устойчивее постоянной работы с IP-адресами.
Но усложнять инфраструктуру без необходимости не стоит. Один сайт или один домашний сервер не требуют отдельного internal DNS. Когда же количество внутренних ресурсов растёт, собственная DNS-зона превращается из удобной опции в важный архитектурный компонент.
Для self-hosted-инфраструктуры internal DNS можно вынести на отдельный VPS и связать его с другими серверами через приватную сеть. Такой подход особенно интересен, когда внутренние сервисы должны взаимодействовать друг с другом, но не должны публиковаться в интернете.
