Prywatny DNS dla sieci VPS: jak działa i kiedy jest potrzebny

Uruchamiasz trzeci serwer, chcesz, aby maszyny odnajdywały się po nazwie zamiast po IP, i wyszukujesz „private DNS VPS”. Wracają trzy wyniki i nie są ze sobą zgodne. Jeden to ustawienie Androida, które szyfruje zapytania twojego telefonu. Drugi to poradnik cPanel dotyczący brandowania serwerów nazw domeny. Trzeci to dokument AWS o prywatnych strefach hostowanych. 20 lipca 2026 roku Cloudflare udostępniła Internal DNS w wersji ogólnodostępnej i opisała go jako „czasem nazywany także prywatnym DNS”, więc teraz zamieszanie pochodzi również od dostawców infrastruktury.

Termin jest przeciążony. Ten artykuł rozdziela poszczególne znaczenia, a następnie skupia się na znaczeniu sieciowym dla VPS: wewnętrznej strefie DNS do komunikacji między serwerami. Na koniec rozpoznasz, którego systemu potrzebujesz, ocenisz, czy twoja flota wymaga prywatnego DNS, i unikniesz typowych błędów projektowych.

TL;DR

• „Prywatny DNS” określa co najmniej trzy niepowiązane systemy: wewnętrzną strefę DNS dla sieci serwerów, funkcję szyfrowania DNS-over-TLS w Androidzie oraz brandowane serwery nazw w cPanelu. Ten artykuł używa terminu w pierwszym znaczeniu: wewnętrzna strefa DNS dla sieci VPS.
• Prywatna strefa DNS dla VPS to wewnętrzna przestrzeń nazw ograniczona do sieci, która mapuje nazwy hostów takie jak db.internal.example.com na prywatne adresy IP. Jej rekordy nie są publikowane w publicznym DNS.
• Dla kilku serwerów ze stałymi adresami IP /etc/hosts naprawdę wystarcza. Wewnętrzny serwer DNS zaczyna się opłacać, gdy flota rośnie, adresy IP często się zmieniają lub usługi potrzebują niezawodnego rozwiązywania nazw.
• W większości produkcyjnych sieci VPS użyj własnej subdomeny, na przykład internal.example.com. Przestrzeni nazw .internal używaj tylko w odizolowanej instalacji, w której akceptowalne są kolizje nazw między sieciami, zarządzanie certyfikatami przez prywatne CA i szczególna obsługa DNSSEC. Unikaj .local, które rezerwuje mDNS.

Czego ten artykuł nie obejmuje

Ten tekst ogranicza się do sieciowego znaczenia prywatnego DNS w kontekście VPS. Nie obejmuje niepowiązanych zastosowań konsumenckich i hostingowych:

• Konfigurowanie ustawienia prywatnego DNS lub DNS-over-TLS w Androidzie na telefonie.
• Konfigurowanie prywatnych serwerów nazw w cPanelu dla marki hostingowej.
• Pełny przewodnik instalacji BIND 9, Unbound, dnsmasq lub CoreDNS. Wdrożenie pozostaje tu na poziomie referencyjnym, a nie konfiguracji krok po kroku.
• Szyfrowane resolwery konsumenckie, takie jak 1.1.1.1 czy NextDNS, poza odróżnieniem ich od znaczenia sieciowego.

Co właściwie znaczy „prywatny DNS”?

„Prywatny DNS” to nie jeden system. Termin określa co najmniej trzy niepowiązane: ograniczoną do sieci strefę DNS, która rozwiązuje wewnętrzne nazwy hostów w sieci VPS lub VPC, funkcję szyfrowania DNS-over-TLS w Androidzie oraz autorytatywne serwery nazw z własnym brandingiem w cPanelu. Ten artykuł omawia pierwszy z nich, czyli strefę wewnętrzną, o którą pytają twoje serwery, by się wzajemnie odnaleźć. Istnieje też czwarte, luźniejsze użycie: szyfrowane publiczne resolwery reklamowane jako „prywatne”.

Te cztery znaczenia łączy tylko nazwa, nic poza tym:

Ogłoszenie ogólnej dostępności Internal DNS przez Cloudflare to aktualny zarządzany przykład pierwszego znaczenia i jeden z powodów, dla których zamieszanie stało się widoczne: dostawca infrastruktury używa teraz w materiałach premierowych określenia „prywatny DNS” jako synonimu wewnętrznego DNS. Opisany system, czyli Gateway Resolver wraz z Internal Authoritative DNS dla klientów Enterprise, należy do tej samej kategorii co to, co budujesz samodzielnie na flocie VPS, tylko w wersji zarządzanej.

Wniosek z sekcji: główne systemy nazywane „prywatnym DNS” łączy etykieta, a nie funkcja. Ustal, o które znaczenie chodzi, zanim zaczniesz realizować jakikolwiek poradnik konfiguracji.

Jak prywatny DNS działa w sieci VPS?

Prywatna strefa DNS dla VPS to przestrzeń nazw ograniczona do sieci, obsługiwana przez resolwer, którego mają używać twoje serwery. Mapuje wewnętrzne nazwy hostów takie jak db.internal.example.com na prywatne adresy IP z zakresu, który kontrolujesz. Rekordy nie są publikowane w publicznym DNS, choć zapytania mogą przechodzić przez prywatny tunel lub zarządzaną warstwę sterowania DNS, zanim dotrą do resolwera. To rozdzielenie stanowi sedno różnicy między prywatnym a publicznym DNS: protokół jest ten sam, ale widoczność strefy i zakres dostępu do niej są inne.

Pracę wykonują trzy elementy. Serwer autorytatywny albo źródło strefy przechowuje wewnętrzną strefę i jej rekordy. Resolwer odpowiada na zapytania wysyłane przez twoje serwery. A rekordy A i AAAA tej strefy mapują wewnętrzne nazwy hostów na adresy prywatne, dzięki czemu app.internal.example.com wskazuje na warstwę aplikacji, a db.internal.example.com wskazuje na bazę danych. Inne typy rekordów mogą dostarczać aliasy lub informacje o usługach. Gdy strefa i ścieżka do resolwera są poprawnie skonfigurowane, resolwer odpowiada na zapytanie wewnętrzne lokalnie, zamiast kierować je do korzenia publicznego DNS.

Platformy chmurowe wiążą to z siecią, a nie z maszyną, co stanowi przydatny model odniesienia. Prywatne strefy hostowane AWS Route 53 działają tylko wtedy, gdy VPC ma ustawione enableDnsHostnames oraz enableDnsSupport na true, a resolwer odpowiada ze strefy prywatnej dla każdej VPC, którą z nią powiążesz. Prywatne strefy Google Cloud są ograniczone do autoryzowanych sieci VPC, a w standardowej kolejności rozwiązywania nazw w VPC są sprawdzane przed publicznym DNS, o ile polityka serwerów wychodzących nie zmieni tej ścieżki. Traktuj to jako ilustrację wzorca, a nie samouczek platformy: samodzielnie zarządzany wewnętrzny serwer DNS to ta sama idea, tyle że uruchomiona na twoim własnym VPS.

Trzymanie strefy poza publicznym DNS to dopiero połowa roboty. Powiąż usługę DNS z prywatnym interfejsem albo ogranicz port 53 UDP i TCP do swojej sieci prywatnej lub VPN. Nie wystawiaj usługi rekurencyjnej do publicznego internetu; przecież otwarty resolwer może zostać wykorzystany w atakach ze wzmocnieniem DNS.

Strefy prywatne i publiczne korzystają z tego samego modelu rekordów DNS i buforowania. Rekordy niosą TTL, a resolwery buforujące zwykle używają ponownie odpowiedzi, dopóki ten TTL nie wygaśnie, choć ustawienia konkretnego resolwera mogą zmienić faktyczny czas bufora. To zachowanie omawiamy w naszym poradniku o kierowaniu domeny na VPS, w tym podstawy propagacji DNS i TTL, więc nie jest to tu ponownie tłumaczone.

Kiedy twoja sieć VPS naprawdę potrzebuje prywatnego DNS?

Dla dwóch czy trzech statycznych serwerów /etc/hosts naprawdę wystarcza. Wewnętrzny serwer DNS zaczyna się opłacać, gdy flota rośnie, adresy IP zmieniają się regularnie lub aplikacje potrzebują niezawodnego wykrywania usług. Prawdziwym wyzwalaczem jest złożoność operacyjna, a nie stała liczba serwerów.

/etc/hosts to statyczna mapa nazw hostów na adresy IP, która istnieje już na każdej maszynie z Linuksem. Nie wymaga demona ani pliku strefy, ale nieaktualne lub niespójne kopie to bardzo realne tryby awarii. Dodaj do pliku prywatny adres IP każdego serwera, utrzymuj kopie zsynchronizowane, a maszyny odnajdą się po nazwie. Dla małej, stabilnej floty to właściwa odpowiedź, a sięganie zamiast tego po BIND 9 dokłada tylko demona do utrzymania bez żadnego zysku.

To przestaje działać w trzech sytuacjach. Gdy często dodajesz i usuwasz serwery, utrzymanie spójnego pliku statycznego na każdym hoście zamienia się w ręczną mordęgę. Gdy adresy IP zmieniają się przez autoskalowanie, przebudowy albo ponowne przydziały u dostawcy, plik po cichu się dezaktualizuje. A gdy kontenery lub izolowane środowiska uruchomieniowe nie dziedziczą wpisów hosta, mapowanie przestaje być uniwersalne. Każda z tych sytuacji z osobna jest prawdziwym wyzwalaczem. Sama liczba serwerów to zgrubne przybliżenie, a nie właściwy sygnał.

Wniosek z sekcji: wyzwalaczem jest operacyjna zmienność, a nie liczba serwerów. Zamrożona flota dziesięciu maszyn spokojnie przeżyje na /etc/hosts; flota trzech maszyn przebudowywana co noc raczej nie.

Twórz na VPS Linux z dostępem root, NVMe i mocą AMD EPYC.

Zobacz plany Linux

Który serwer DNS uruchomić: BIND 9, Unbound, dnsmasq czy CoreDNS?

Wybieraj według kształtu swojej floty. dnsmasq pasuje do małych sieci, które chcą lekkiego DNS i, gdy trzeba, DHCP z tego samego demona. Unbound to oszczędny, walidujący resolwer rekurencyjny, który obsłuży też skromną strefę lokalną. BIND 9 daje szerokie możliwości autorytatywne i rekurencyjne przy największej powierzchni konfiguracji. CoreDNS pasuje do flot kontenerowych i Kubernetes, gdzie DNS jest częścią wykrywania usług.

Logika wyboru jest krótka. Jeśli potrzebujesz małego resolwera opartego na pliku w stylu hosts albo i tak rozdajesz dzierżawy DHCP, dnsmasq usuwa jeden ruchomy element. Jeśli potrzebujesz głównie walidującego resolwera, który przekazuje zapytania na zewnątrz i obsługuje skromną strefę wewnętrzną, Unbound daje dokładnie ten węższy zestaw funkcji bez pełnego wdrożenia BIND 9. Jeśli potrzebujesz pełnej kontroli autorytatywnej, delegacji i największego zasobu dokumentacji, na którym można się oprzeć o trzeciej w nocy, BIND 9 pozostaje wyborem zachowawczym mimo szerszej powierzchni konfiguracji. Jeśli DNS jest już częścią kontenerowego lub Kubernetesowego stosu wykrywania usług, CoreDNS wpasowuje się tam wprost. Reguła kciuka: uruchamiaj najmniejszą rzecz, która pokrywa kształt twojej floty.

W produkcyjnej flocie nie czyń jednej instancji DNS jedyną drogą do każdej nazwy wewnętrznej. Uruchom co najmniej dwie instancje DNS które potrafią obsłużyć strefę, umieść je w miarę możliwości w osobnych domenach awarii i skonfiguruj klientów tak, by sięgały do obu. W przeciwnym razie jedna awaria DNS potrafi sprawić, że zdrowe usługi wyglądają na martwe.

Jak nazwać domenę wewnętrzną: .internal, .local czy subdomena?

W większości produkcyjnych sieci VPS użyj własnej subdomeny, na przykład internal.example.com. Przestrzeni nazw .internal używaj tylko w odizolowanej instalacji, w której akceptowalne są kolizje nazw między sieciami, zarządzanie certyfikatami przez prywatne CA i szczególna obsługa DNSSEC. Unikaj .local, które rezerwuje mDNS.

Problem z .local jest konkretny. RFC 6762 przyznaje nazwom kończącym się na .local specjalne traktowanie w Multicast DNS, więc unicastowa strefa w BIND 9 lub Unbound z tym samym sufiksem może kolidować z zachowaniem mDNS na urządzeniach Apple i innych systemach z mDNS. Użyj innej przestrzeni nazw, zamiast polegać na obejściach właściwych dla konkretnych klientów.

Wskazówka: Jeśli odziedziczyłeś wewnętrzną strefę .local, potraktuj ją jak dług techniczny. Część klientów wysyła zapytania .local do mDNS zamiast do twojego unicastowego serwera DNS, co może dawać awarie zależne od klienta albo sprawiające wrażenie sporadycznych.

Zarząd ICANN na stałe zarezerwował .internal przed delegacją w korzeniu publicznego DNS w lipcu 2024 roku, w ślad za wcześniejszą rekomendacją SSAC. Nazwy pod nim z założenia nie będą rozwiązywane przez globalny DNS. Wiążą się z tym kompromisy: nazwy .internal nie są globalnie unikalne, od publicznych urzędów certyfikacji nie oczekuje się wydawania dla nich certyfikatów, a resolwery walidujące DNSSEC w oparciu o globalną kotwicę zaufania nie zdołają ich rozwiązać. Jeśli potrzebujesz HTTPS na .internal, zaplanuj prowadzenie prywatnego CA.

Rozdziel tu dwie rzeczy. Rezerwacja ICANN jest ostateczna. Osobno istnieje aktywny Internet-Draft, draft-davies-internal-tld-06, opublikowany 6 maja 2026 roku, aby udokumentować tę przestrzeń nazw i porównać ją z adresacją prywatną z RFC 1918. Wciąż pozostaje Internet-Draftem w toku prac, a nie opublikowanym RFC, więc opisuj .internal jako zarezerwowaną przez ICANN domenę najwyższego poziomu do użytku prywatnego, a nie standard IETF.

Dla większości flot VPS bezpieczniejszym domyślnym wyborem jest subdomena domeny, którą kontrolujesz. ISC zaleca hierarchię subdomen, na przykład wewnętrzną subdomenę własnej domeny, zamiast utrzymywać osobne i niekompletne wewnętrzne oraz publiczne wersje tej samej strefy nadrzędnej. Ta preferencja nie jest kwestią stylu: zapobiega awarii opisanej w następnej sekcji.

Wniosek z sekcji: decyzja o przestrzeni nazw zostaje z tobą na długo. Subdomena, którą kontrolujesz, jest domyślnym wyborem w większości środowisk produkcyjnych, bo zachowuje globalną unikalność i działa z publicznym PKI. Sięgaj po .internal wtedy, gdy odizolowana prywatna przestrzeń nazw pasuje lepiej i akceptujesz jej kompromisy dotyczące DNSSEC, certyfikatów i kolizji.

DNS z podzielonym horyzontem i błędy, które go psują

DNS z podzielonym horyzontem zwraca dla tej samej nazwy hosta inną odpowiedź zależnie od tego, kto pyta: wewnątrz prywatne IP, na zewnątrz publiczne. Najczęściej psuje się przez pułapkę NXDOMAIN w obrębie tej samej domeny, przez alternatywne resolwery omijające zamierzony widok i przez kontenerowe ścieżki DNS, które nie docierają do oczekiwanego serwera nadrzędnego. Zrobienie tego dobrze zależy od trzech rzeczy naraz, nie od jednej.

Pułapka NXDOMAIN to dokładnie ta awaria, przed którą ISC ostrzega wprost. Jeśli twoje serwery wewnętrzne są autorytatywne dla domeny nadrzędnej, ale ich wersja strefy nie zawiera publicznego rekordu, na przykład hosta www, to klient wewnętrzny pytający o tę nazwę dostanie NXDOMAIN, choć strefa publiczna ten rekord ma. Strefa wewnętrzna jest autorytatywna i dla domeny nadrzędnej nie sięga awaryjnie do publicznego DNS. Właśnie dlatego podejście z hierarchią subdomen z sekcji o nazewnictwie jest projektem preferowanym przez ISC.

Wskazówka: Zanim skierujesz serwery na konfigurację z podzielonym horyzontem w obrębie tej samej domeny, sprawdź z wnętrza sieci rozwiązanie znanej publicznej nazwy w tej domenie. Odpowiedź NXDOMAIN dla nazwy, która z zewnątrz rozwiązuje się bez problemu, to podpis tej pułapki.

Trzy kolejne pułapki łatwo przeoczyć. Alternatywny resolwer skonfigurowany na hoście lub w kontenerze może ominąć ten podział; zależnie od implementacji resolwera może być odpytywany po upływie limitu czasu albo równolegle, więc odpowiedzi bywają różne. Kontenery na domyślnym moście Dockera przy starcie dostają kopię konfiguracji DNS hosta, a kontenery w sieciach własnych pytają wbudowany resolwer Dockera pod adresem 127.0.0.11. Ten resolwer przekazuje zapytania zewnętrzne do serwerów DNS skonfigurowanych dla hosta lub kontenera, więc zachowanie split-DNS zależy od konfiguracji Dockera i hosta, a nie tylko od własnego pliku resolwera w kontenerze. Jeśli usługa wewnętrzna stoi za reverse proxy takim jak Menedżer Proxy Nginx, walidacja certyfikatu może się nie powieść, gdy certyfikat nie obejmuje żądanej nazwy hosta albo wystawiający go CA nie jest zaufany dla klienta. Samo używanie innego certyfikatu wewnętrznie nie jest błędem. To luki konfiguracyjne, a nie błędy narzędzi.

Klienci zdalni mogą natrafić na tę samą awarię, gdy samodzielnie hostowany VPN nie przekazuje ani nie kieruje zapytań DNS do zamierzonego wewnętrznego resolwera.

Jest też wymiar bezpieczeństwa. Jeśli wewnętrzne nazwy hostów i prywatne adresy IP wyciekną do publicznych rekordów DNS, odsłaniasz część swojego wewnętrznego schematu nazewnictwa i adresacji przed każdym, kto zapyta. Podzielony horyzont istnieje między innymi po to, by trzymać tę mapę wewnątrz, a źle skonfigurowana strefa publiczna po cichu to niweczy.

Wniosek z sekcji: awarie podzielonego horyzontu to pułapki konfiguracyjne, a nie wady narzędzi. Poprawność zależy od dyscypliny nazewniczej, od wiedzy, którego resolwera faktycznie pyta każdy klient, oraz od właściwego zakresu strefy, a nie od jednego ustawienia.

CZYTAJ

Jak przekierować domenę na VPS: krótki poradnik

Podsumowanie: jak wybrać właściwy projekt prywatnego DNS

Potrafisz już rozpoznać, o który system „prywatnego DNS” naprawdę ci chodzi. W sieciach VPS jest to wewnętrzna strefa DNS, a nie ustawienie DNS-over-TLS w Androidzie ani brandowane autorytatywne serwery nazw. Jeśli twoja flota jest mała i stabilna, /etc/hosts to obronny wybór. Jeśli nie jest, weź jako domyślną przestrzeń nazw własną subdomenę, wybierz najmniejszy serwer DNS pasujący do floty i trzymaj jawnie ustalone: dostęp, nadmiarowość oraz zakres strefy wewnętrznej wobec publicznej. Po .internal sięgaj tylko wtedy, gdy odizolowana przestrzeń nazw pasuje lepiej i akceptujesz jej kompromisy dotyczące certyfikatów, DNSSEC i kolizji.

Często zadawane pytania