Приватний 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 для імені, яке ззовні чудово розв'язується, — це підпис саме цієї пастки.

Ще три пастки легко проґавити. Альтернативний резолвер, налаштований на хості чи в контейнері, може обійти цей поділ; залежно від реалізації резолвера його можуть опитувати після тайм-ауту або паралельно, тож відповіді різнитимуться. Контейнери на типовому мості 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 і колізій.

Часті запитання