Приватный DNS для VPS-сетей: как это работает и когда он нужен

Вы поднимаете третий сервер, вам нужно, чтобы машины находили друг друга по имени, а не по IP, и вы ищете «private DNS VPS». Возвращаются три результата, и они не согласуются между собой. Один — настройка Android, которая шифрует запросы вашего телефона. Другой — руководство cPanel по брендированию серверов имён для домена. Третий — документ AWS о приватных hosted-зонах. 20 июля 2026 года Cloudflare выпустила Internal DNS в общую доступность и описала его как «иногда также называемый приватным DNS», так что теперь путаница приходит и от поставщиков инфраструктуры.

Термин перегружен. Эта статья разделяет разные значения, а затем сосредотачивается на сетевом значении для VPS: внутренней DNS-зоне для связи между серверами. К концу вы сможете определить, какая система вам нужна, решить, требуется ли вашему парку приватный DNS, и избежать типичных ошибок проектирования.

Кратко (TL;DR)

• «Приватный DNS» обозначает как минимум три не связанные между собой системы: внутреннюю DNS-зону для сети серверов, функцию шифрования DNS-over-TLS в Android и брендированные серверы имён cPanel. В этой статье термин используется в первом значении: внутренняя DNS-зона для VPS-сети.
• Приватная DNS-зона VPS — это внутреннее пространство имён, ограниченное сетью, которое сопоставляет имена хостов вроде db.internal.example.com с приватными IP-адресами. Её записи не публикуются в публичном DNS.
• Для нескольких серверов со стабильными IP-адресами /etc/hosts действительно достаточно. Внутренний DNS-сервер оправдывает себя, когда парк растёт, IP-адреса часто меняются или сервисам нужно надёжное разрешение имён.
• Для большинства продакшн-сетей VPS используйте собственный поддомен, например internal.example.com. Используйте пространство имён .internal только в изолированной установке, где допустимы коллизии имён между сетями, управление сертификатами через приватный центр сертификации и особая обработка DNSSEC. Избегайте .local, который зарезервирован mDNS.

Чего эта статья не охватывает

Эта статья ограничивается сетевым значением приватного DNS для VPS. Она не охватывает не связанные с ним потребительские и хостинговые применения:

• Настройка параметра приватного DNS или DNS-over-TLS в Android на телефоне.
• Настройка приватных серверов имён cPanel для хостинг-бренда.
• Полное пошаговое руководство по установке BIND 9, Unbound, dnsmasq или CoreDNS. Реализация здесь остаётся на справочном уровне, а не на уровне пошаговой настройки.
• Шифрованные потребительские резолверы вроде 1.1.1.1 или NextDNS, кроме их отличия от сетевого значения.

Что на самом деле означает «приватный DNS»?

«Приватный DNS» — это не одна система. Термин обозначает как минимум три не связанные между собой: ограниченную сетью DNS-зону, которая разрешает внутренние имена хостов внутри VPS- или VPC-сети, функцию шифрования DNS-over-TLS в Android и авторитативные серверы имён с собственным брендом в cPanel. Эта статья посвящена первой из них — внутренней зоне, которую ваши серверы запрашивают, чтобы найти друг друга. Есть и четвёртое, более вольное употребление: шифрованные публичные резолверы, которые продвигают как «приватные».

Эти четыре значения объединяет только название и ничего больше:

Объявление Cloudflare об общей доступности Internal DNS — это актуальный управляемый пример первого значения и одна из причин, почему путаница стала заметной: поставщик инфраструктуры теперь использует «приватный DNS» как синоним внутреннего DNS в своих анонсах. Описанная система, Gateway Resolver вместе с Internal Authoritative DNS для клиентов Enterprise, относится к той же категории, что и та, которую вы строите сами на парке VPS, только в управляемом виде.

Вывод раздела: основные системы, называемые «приватным DNS», объединяет ярлык, а не функция. Определите значение, прежде чем следовать инструкции по настройке.

Как приватный DNS работает в VPS-сети?

Приватная DNS-зона VPS — это ограниченное сетью пространство имён, которое обслуживает резолвер, настроенный на ваших серверах. Она сопоставляет внутренние имена хостов, такие как db.internal.example.com с приватными IP-адресами в диапазоне, который вы контролируете. Записи не публикуются в публичном DNS, хотя запросы могут проходить через приватный туннель или управляемую панель управления DNS, прежде чем достичь резолвера. Именно это разделение и составляет суть различия между приватным и публичным DNS: протокол тот же, но видимость зоны и область доступа к ней разные.

Работу выполняют три части. Авторитативный сервер или источник зоны хранит внутреннюю зону и её записи. Резолвер отвечает на запросы, которые отправляют ваши серверы. А записи A и AAAA этой зоны сопоставляют внутренние имена хостов с приватными адресами, так что app.internal.example.com разрешается в уровень приложения, а db.internal.example.com разрешается в базу данных. Другие типы записей могут давать псевдонимы или сведения о службах. Когда зона и путь до резолвера настроены правильно, резолвер отвечает на внутренний запрос локально, а не отправляет его к корню публичного DNS.

Облачные платформы привязывают это к сети, а не к машине, и это полезная эталонная модель. Приватные hosted-зоны AWS Route 53 работают только тогда, когда у VPC оба параметра enableDnsHostnames и enableDnsSupport выставлены в true, и резолвер отвечает из приватной зоны для любой VPC, которую вы с ней свяжете. Приватные зоны Google Cloud ограничены авторизованными VPC-сетями, и в стандартном порядке разрешения имён в VPC они проверяются раньше публичного DNS, если только политика исходящего сервера не меняет маршрут. Воспринимайте это как иллюстрации подхода, а не как руководства по платформам: самостоятельно управляемый внутренний DNS-сервер работает по той же идее, только на вашем собственном VPS.

Держать зону вне публичного DNS — это лишь половина дела. Привяжите службу DNS к приватному интерфейсу или ограничьте UDP- и TCP-порт 53 вашей приватной сетью либо VPN. Не открывайте рекурсивную службу в публичный интернет: ведь открытый резолвер может быть использован в атаках с усилением DNS.

Приватные и публичные зоны используют одну и ту же модель DNS-записей и кеширования. У записей есть TTL, и кеширующие резолверы обычно переиспользуют ответ, пока этот TTL не истечёт, хотя отдельные настройки резолвера могут изменить фактическое время кеширования. Это поведение разобрано в нашем руководстве по направлению домена на VPS, включая основы распространения DNS и TTL, поэтому здесь это не объясняется заново.

Когда вашей VPS-сети действительно нужен приватный DNS?

Для двух-трёх статичных серверов /etc/hosts действительно достаточно. Внутренний DNS-сервер оправдывает себя, когда парк растёт, IP-адреса регулярно меняются или приложениям нужно надёжное обнаружение сервисов. Настоящий триггер — операционная сложность, а не фиксированное число серверов.

/etc/hosts — это статическая таблица соответствия имён хостов и IP-адресов, которая уже есть на каждой Linux-машине. Ей не нужен ни демон, ни файл зоны, но устаревшие или несогласованные копии — это вполне реальные сценарии отказа. Добавьте приватный IP каждого сервера в файл, держите копии синхронизированными, и машины смогут находить друг друга по имени. Для небольшого стабильного парка это правильный ответ, а разворачивать вместо этого BIND 9 значит просто добавить себе демон для обслуживания без всякой пользы.

Этот подход перестаёт работать в трёх ситуациях. Когда вы часто добавляете и убираете серверы, поддержание статического файла в согласованном виде на каждом хосте превращается в ручную рутину. Когда IP-адреса меняются из-за автомасштабирования, пересборок или переназначений у провайдера, файл незаметно устаревает. И когда контейнеры или изолированные среды выполнения не наследуют записи хоста, соответствие перестаёт быть универсальным. Любая из этих ситуаций и есть настоящий триггер. Одно лишь количество серверов — грубое приближение, а не реальный сигнал.

Вывод раздела: триггер — это операционная текучка, а не количество серверов. Замороженный парк из десяти машин вполне может жить на /etc/hosts; а парк из трёх машин, который пересобирается каждую ночь, скорее всего нет.

Разрабатывайте на Linux VPS с root-доступом, NVMe и мощью AMD EPYC.

Посмотреть тарифы Linux

Какой DNS-сервер выбрать: BIND 9, Unbound, dnsmasq или CoreDNS?

Выбирайте по форме вашего парка. dnsmasq подходит небольшим сетям, которым нужен лёгкий DNS и, где это уместно, DHCP из того же демона. Unbound — компактный проверяющий рекурсивный резолвер, который также может отвечать за скромную локальную зону. BIND 9 даёт широкие авторитативные и рекурсивные возможности при самой обширной поверхности настройки. CoreDNS подходит контейнерным и Kubernetes-парикам, где DNS является частью обнаружения сервисов.

Логика выбора короткая. Если вам нужен небольшой резолвер, опирающийся на файл в стиле hosts, или вы уже раздаёте DHCP-аренды, dnsmasq убирает одну движущуюся часть. Если вам в основном нужен проверяющий резолвер, который пересылает запросы наружу и отвечает за скромную внутреннюю зону, Unbound даёт этот более узкий набор функций без полного развёртывания BIND 9. Если нужны полный авторитативный контроль, делегирование и самый большой массив документации, на который можно опереться в три часа ночи, BIND 9 остаётся консервативным выбором, несмотря на более широкую поверхность настройки. Если DNS уже часть контейнерного или Kubernetes-стека обнаружения сервисов, CoreDNS встраивается туда естественно. Правило простое: запускайте самое малое, что покрывает форму вашего парка.

Для продакшн-парка не делайте один экземпляр DNS единственным путём к каждому внутреннему имени. Запустите как минимум два экземпляра DNS которые могут отвечать за зону, разместите их в разных доменах отказа, где это практично, и настройте клиентов на обращение к обоим. Иначе один сбой DNS способен выставить здоровые сервисы мёртвыми.

Как назвать внутренний домен: .internal, .local или поддомен?

Для большинства продакшн-сетей VPS используйте собственный поддомен, например internal.example.com. Используйте пространство имён .internal только в изолированной установке, где допустимы коллизии имён между сетями, управление сертификатами через приватный центр сертификации и особая обработка DNSSEC. Избегайте .local, который зарезервирован mDNS.

Проблема с .local вполне конкретна. RFC 6762 предусматривает особую обработку имён, оканчивающихся на .local, для Multicast DNS, поэтому unicast-зона BIND 9 или Unbound с тем же суффиксом может конфликтовать с поведением mDNS на устройствах Apple и других системах с mDNS. Используйте другое пространство имён, а не полагайтесь на обходные приёмы для конкретных клиентов.

Совет профессионала: если вам досталась внутренняя зона на .local, относитесь к ней как к техническому долгу. Некоторые клиенты отправляют запросы .local в mDNS, а не на ваш unicast DNS-сервер, из-за чего сбои выглядят зависящими от клиента или перемежающимися.

Совет директоров ICANN окончательно зарезервировал .internal , исключив его из делегирования в корне публичного DNS в июле 2024 года, вслед за более ранней рекомендацией SSAC. Имена под ним по замыслу не будут разрешаться через глобальный DNS. Это влечёт компромиссы: имена .internal не являются глобально уникальными, публичные удостоверяющие центры не предполагают выпуск сертификатов для них, а резолверы, проверяющие DNSSEC по глобальному якорю доверия, не смогут их разрешить. Если вам нужен HTTPS на .internal, планируйте собственный приватный центр сертификации.

Здесь стоит различать две вещи. Резервирование ICANN окончательно. Отдельно существует активный Internet-Draft, draft-davies-internal-tld-06, опубликованный 6 мая 2026 года, чтобы задокументировать это пространство имён и сравнить его с приватной адресацией по RFC 1918. Это по-прежнему рабочий Internet-Draft, а не опубликованный RFC, поэтому описывайте .internal как зарезервированный ICANN домен верхнего уровня для приватного использования, а не как стандарт IETF.

Для большинства парков VPS более безопасный вариант по умолчанию — поддомен домена, которым вы управляете. ISC рекомендует иерархию поддоменов, например внутренний поддомен вашего собственного домена, вместо того чтобы поддерживать раздельные и неполные внутренние и публичные версии одной родительской зоны. Это предпочтение не вопрос стиля: оно предотвращает сбой, описанный в следующем разделе.

Вывод раздела: решение о пространстве имён живёт долго. Поддомен, которым вы управляете, — вариант по умолчанию для большинства продакшн-сред, поскольку он сохраняет глобальную уникальность и работает с публичной PKI. Используйте .internal, когда изолированное приватное пространство имён подходит лучше и вы принимаете его компромиссы по DNSSEC, сертификатам и коллизиям.

Split-horizon DNS и ошибки, которые его ломают

Split-horizon DNS выдаёт для одного и того же имени хоста разный ответ в зависимости от того, кто спрашивает: приватный IP изнутри, публичный снаружи. Чаще всего он ломается из-за ловушки NXDOMAIN в пределах того же домена, из-за альтернативных резолверов, обходящих задуманное представление, и из-за DNS-путей в контейнерах, которые не доходят до ожидаемого вышестоящего сервера. Правильная работа зависит сразу от трёх вещей, а не от одной.

Ловушка NXDOMAIN — это именно тот сбой, о котором напрямую предупреждает ISC. Если ваши внутренние серверы авторитативны для родительского домена, но их версия зоны не содержит публичной записи вроде хоста www, внутренний клиент, запросивший это имя, получит NXDOMAIN, хотя в публичной зоне запись есть. Внутренняя зона авторитативна и не обращается к публичному DNS для родительского домена. Именно поэтому подход с иерархией поддоменов из раздела об именовании и является предпочтительным для ISC.

Совет профессионала: прежде чем направлять серверы на split-horizon-схему в пределах одного домена, проверьте изнутри сети разрешение известного публичного имени в этом домене. Ответ NXDOMAIN для имени, которое снаружи прекрасно резолвится, — верный признак этой ловушки.

Ещё три подводных камня легко упустить. Альтернативный резолвер, настроенный на хосте или в контейнере, может обойти разделение; в зависимости от реализации резолвера его могут опрашивать после тайм-аута или параллельно, поэтому ответы бывают разными. Контейнеры на стандартном bridge Docker при запуске получают копию DNS-конфигурации хоста, а контейнеры в пользовательских сетях обращаются к встроенному резолверу Docker по адресу 127.0.0.11. Этот резолвер пересылает внешние запросы на DNS-серверы, настроенные для хоста или контейнера, поэтому поведение split-DNS зависит от конфигурации Docker и хоста, а не только от собственного файла резолвера в контейнере. Если внутренняя служба стоит за обратным прокси вроде Менеджер прокси Nginx, проверка сертификата может не пройти, если сертификат не покрывает запрошенное имя хоста или выпустивший его центр сертификации не является доверенным для клиента. Само по себе использование другого сертификата внутри сети ошибкой не является. Это пробелы в конфигурации, а не баги инструментов.

Удалённые клиенты могут столкнуться с тем же сбоем, когда самостоятельно размещённый VPN не передаёт и не маршрутизирует DNS-запросы к нужному внутреннему резолверу.

Есть и аспект безопасности. Если внутренние имена хостов и приватные IP-адреса утекают в публичные DNS-записи, вы раскрываете часть своей внутренней схемы именования и адресации любому, кто сделает запрос. Split-horizon отчасти и существует для того, чтобы эта карта оставалась внутри, а неверно настроенная публичная зона тихо сводит это на нет.

Вывод раздела: сбои split-horizon — это ловушки конфигурации, а не дефекты инструментов. Корректность зависит от дисциплины именования, от понимания, к какому резолверу на самом деле обращается каждый клиент, и от правильного охвата зоны, а не от какой-то одной настройки.

ЧИТАТЬ

Как привязать домен к VPS: краткое руководство

Заключение: как выбрать правильную схему приватного DNS

Теперь вы можете определить, какую именно систему «приватного DNS» имеете в виду. Для сетей VPS это внутренняя DNS-зона, а не настройка DNS-over-TLS в Android и не брендированные авторитативные серверы имён. Если ваш парк небольшой и стабильный, /etc/hosts остаётся вполне оправданным выбором. Если нет, возьмите за пространство имён по умолчанию поддомен, которым владеете, выберите самый небольшой DNS-сервер, подходящий вашему парку, и держите явными доступ, резервирование и границу между внутренней и публичной зоной. Используйте .internal только тогда, когда изолированное пространство имён подходит лучше и вы принимаете его компромиссы по сертификатам, DNSSEC и коллизиям.

Часто задаваемые вопросы