Privátní DNS pro sítě VPS: jak funguje a kdy jej potřebujete

Spustíte třetí server, potřebujete, aby se stroje našly podle jména místo podle IP, a vyhledáte „private DNS VPS“. Vrátí se tři výsledky a neshodují se. Jeden je nastavení Androidu, které šifruje dotazy vašeho telefonu. Druhý je návod pro cPanel na značkové jmenné servery domény. Třetí je dokument AWS o privátních hosted zónách. Dne 20. července 2026 Cloudflare uvedla Internal DNS do obecné dostupnosti a popsala jej jako „někdy též označovaný jako privátní DNS“, takže záměna nyní přichází i od dodavatelů infrastruktury.

Termín je přetížený. Tento článek odděluje jednotlivé významy a poté se soustředí na význam v sítích VPS: interní DNS zónu pro komunikaci mezi servery. Na konci dokážete určit, který systém potřebujete, rozhodnout, zda vaše flotila vyžaduje privátní DNS, a vyhnout se běžným návrhovým chybám.

Stručně

• „Privátní DNS“ označuje nejméně tři nesouvisející systémy: interní DNS zónu pro síť serverů, funkci šifrování DNS-over-TLS v Androidu a značkové jmenné servery cPanelu. Tento článek používá termín v prvním významu: interní DNS zóna pro síť VPS.
• Privátní DNS zóna VPS je interní jmenný prostor omezený na síť, který mapuje názvy hostitelů jako db.internal.example.com na privátní IP adresy. Jeho záznamy se nezveřejňují ve veřejném DNS.
• Pro hrstku serverů se stabilními IP adresami /etc/hosts opravdu stačí. Interní DNS server se vyplatí, jakmile flotila roste, IP adresy se často mění nebo služby potřebují spolehlivé překládání jmen.
• Pro většinu produkčních sítí VPS použijte subdoménu, kterou vlastníte, například internal.example.com. Jmenný prostor .internal používejte jen pro izolované nasazení, kde jsou přijatelné kolize jmen mezi sítěmi, správa certifikátů přes privátní CA a zvláštní zacházení s DNSSEC. Vyhněte se .local, které si vyhrazuje mDNS.

Co tento článek nepokrývá

Tento text zůstává u významu privátního DNS v sítích VPS. Nezabývá se nesouvisejícími spotřebitelskými a hostingovými použitími:

• Nastavení privátního DNS nebo DNS-over-TLS v Androidu na telefonu.
• Nastavení privátních jmenných serverů v cPanelu pro hostingovou značku.
• Kompletní návod na instalaci BIND 9, Unbound, dnsmasq nebo CoreDNS. Implementace zde zůstává na referenční úrovni, nikoli na úrovni konfigurace krok za krokem.
• Šifrované spotřebitelské resolvery jako 1.1.1.1 nebo NextDNS, nad rámec jejich odlišení od síťového významu.

Co vlastně znamená „privátní DNS“?

„Privátní DNS“ není jeden systém. Termín označuje nejméně tři nesouvisející: DNS zónu omezenou na síť, která překládá interní názvy hostitelů uvnitř sítě VPS nebo VPC, funkci šifrování DNS-over-TLS v Androidu a vlastní značkové autoritativní jmenné servery v cPanelu. Tento článek se věnuje prvnímu z nich, tedy interní zóně, na kterou se vaše servery dotazují, aby se navzájem našly. Existuje i čtvrté, volnější použití: šifrované veřejné resolvery prodávané jako „privátní“.

Tyto čtyři významy spojuje jen název, nic víc:

Oznámení obecné dostupnosti Internal DNS od Cloudflare je aktuální spravovaný příklad prvního významu a jeden z důvodů, proč je záměna nově vidět: dodavatel infrastruktury nyní ve svých textech k uvedení používá „privátní DNS“ jako synonymum interního DNS. Popisovaný systém, tedy Gateway Resolver spolu s Internal Authoritative DNS pro zákazníky Enterprise, patří do stejné kategorie jako to, co si sami postavíte na flotile VPS, jen ve spravované podobě.

Shrnutí sekce: hlavní systémy zvané „privátní DNS“ sdílejí označení, nikoli funkci. Než se pustíte do nějakého návodu, ujasněte si, o který význam jde.

Jak funguje privátní DNS v síti VPS?

Privátní DNS zóna VPS je jmenný prostor omezený na síť, který obsluhuje resolver nastavený na vašich serverech. Mapuje interní názvy hostitelů jako db.internal.example.com na privátní IP adresy v rozsahu, který spravujete. Záznamy se ve veřejném DNS nezveřejňují, i když dotazy mohou před dosažením resolveru procházet privátním tunelem nebo spravovanou řídicí vrstvou DNS. Právě toto oddělení je jádrem rozdílu mezi privátním a veřejným DNS: protokol je stejný, ale viditelnost zóny a rozsah přístupu k ní se liší.

Práci dělají tři části. Autoritativní server nebo zdroj zóny drží interní zónu a její záznamy. Resolver odpovídá na dotazy, které vaše servery posílají. A záznamy A a AAAA této zóny mapují interní názvy hostitelů na privátní adresy, takže app.internal.example.com se přeloží na aplikační vrstvu a db.internal.example.com se přeloží na databázi. Jiné typy záznamů mohou poskytovat aliasy nebo informace o službách. Když jsou zóna i cesta k resolveru nastavené správně, resolver odpoví na interní dotaz lokálně, místo aby jej posílal ke kořeni veřejného DNS.

Cloudové platformy to vážou na síť, nikoli na stroj, což je užitečný referenční model. Privátní hosted zóny AWS Route 53 fungují jen tehdy, když má VPC nastavené enableDnsHostnames i enableDnsSupport na true, a resolver odpovídá z privátní zóny pro každou VPC, kterou k ní přiřadíte. Privátní zóny Google Cloud jsou omezené na autorizované sítě VPC a ve standardním pořadí překladu ve VPC se kontrolují dřív než veřejné DNS, pokud cestu nezmění politika odchozích serverů. Berte to jako ilustraci principu, ne jako návod k platformě: vlastní spravovaný interní DNS server je tatáž myšlenka, jen běží na vašem VPS.

Udržet zónu mimo veřejné DNS je jen půlka práce. Navažte službu DNS na privátní rozhraní nebo omezte UDP a TCP port 53 na svou privátní síť či VPN. Nevystavujte rekurzivní službu veřejnému internetu; vždyť otevřený resolver lze zneužít při útocích s DNS zesílením.

Privátní i veřejné zóny používají stejný model DNS záznamů a cachování. Záznamy nesou TTL a cachující resolvery obvykle znovu použijí odpověď, dokud tato TTL nevyprší, byť nastavení konkrétního resolveru může efektivní dobu cache změnit. Toto chování rozebíráme v našem návodu, jak nasměrovat doménu na VPS, včetně základů propagace DNS a TTL, takže se to zde nevysvětluje znovu.

Kdy vaše síť VPS opravdu potřebuje privátní DNS?

Pro dva nebo tři statické servery /etc/hosts opravdu stačí. Interní DNS server se vyplatí, když flotila roste, IP adresy se pravidelně mění nebo aplikace potřebují spolehlivé vyhledávání služeb. Skutečným spouštěčem je provozní složitost, nikoli pevný počet serverů.

/etc/hosts je statická mapa názvů hostitelů na IP adresy, která už existuje na každém linuxovém stroji. Nepotřebuje démona ani zónový soubor, ale zastaralé či nekonzistentní kopie jsou reálné způsoby selhání. Přidejte do souboru privátní IP každého serveru, udržujte kopie synchronizované a stroje se najdou podle jména. Pro malou a stabilní flotilu je to správná odpověď a sáhnout místo toho po BIND 9 znamená jen přidat démona k údržbě bez jakéhokoli přínosu.

Přestane to stačit ve třech situacích. Když často přidáváte a odebíráte servery, udržet statický soubor konzistentní na každém hostiteli se změní v ruční dřinu. Když se IP adresy mění kvůli automatickému škálování, přestavbám nebo přeřazení u poskytovatele, soubor tiše zastarává. A když kontejnery nebo izolovaná běhová prostředí nedědí záznamy hostitele, mapování přestává být univerzální. Kterákoli z těchto situací je tím skutečným spouštěčem. Samotný počet serverů je jen hrubé přiblížení, nikoli skutečný signál.

Shrnutí sekce: spouštěčem je provozní fluktuace, nikoli počet serverů. Zmrazená flotila deseti strojů si vystačí s /etc/hosts; flotila tří strojů, která se každou noc přestavuje, spíš ne.

Stavte na Linux VPS s root přístupem, NVMe a výkonem AMD EPYC.

Zobrazit Linux plány

Který DNS server provozovat: BIND 9, Unbound, dnsmasq, nebo CoreDNS?

Vybírejte podle tvaru své flotily. dnsmasq se hodí malým sítím, které chtějí odlehčené DNS a případně i DHCP z téhož démona. Unbound je úsporný validující rekurzivní resolver, který dokáže odpovídat i na skromnou lokální zónu. BIND 9 nabízí široké autoritativní i rekurzivní schopnosti s nejrozsáhlejší konfigurační plochou. CoreDNS sedí kontejnerovým a Kubernetes flotilám, kde je DNS součástí vyhledávání služeb.

Logika výběru je krátká. Pokud potřebujete malý resolver opřený o soubor ve stylu hosts, nebo už rozdáváte DHCP zápůjčky, dnsmasq odebere jednu pohyblivou součástku. Pokud potřebujete hlavně validující resolver, který přeposílá ven a odpovídá na skromnou interní zónu, Unbound poskytne přesně tuto užší sadu funkcí bez plného nasazení BIND 9. Pokud potřebujete plnou autoritativní kontrolu, delegaci a největší množství dokumentace, o kterou se lze opřít ve tři ráno, BIND 9 zůstává konzervativní volbou navzdory širší konfigurační ploše. Pokud je DNS už součástí kontejnerového nebo Kubernetes stacku pro vyhledávání služeb, CoreDNS do něj zapadne. Pravidlo palce zní: provozujte to nejmenší, co pokryje tvar vaší flotily.

U produkční flotily nedělejte z jediné instance DNS jedinou cestu ke každému internímu jménu. Provozujte alespoň dvě instance DNS které dokážou zónu obsloužit, umístěte je pokud možno do oddělených domén selhání a nastavte klienty tak, aby dosáhli na obě. Jinak může jediný výpadek DNS způsobit, že zdravé služby budou vypadat mrtvě.

Jak pojmenovat interní doménu: .internal, .local, nebo subdoménu?

Pro většinu produkčních sítí VPS použijte subdoménu, kterou vlastníte, například internal.example.com. Jmenný prostor .internal používejte jen pro izolované nasazení, kde jsou přijatelné kolize jmen mezi sítěmi, správa certifikátů přes privátní CA a zvláštní zacházení s DNSSEC. Vyhněte se .local, které si vyhrazuje mDNS.

Problém s .local je konkrétní. RFC 6762 přiznává jménům končícím na .local zvláštní zacházení v rámci Multicast DNS, takže unicastová zóna v BIND 9 nebo Unbound se stejnou příponou může kolidovat s chováním mDNS na zařízeních Apple i dalších systémech s mDNS. Použijte jiný jmenný prostor, místo abyste spoléhali na obezličky pro konkrétní klienty.

Tip: Pokud jste zdědili interní zónu na .local, berte ji jako technický dluh. Někteří klienti posílají dotazy na .local do mDNS místo na váš unicastový DNS server, což může vést k výpadkům závislým na klientovi nebo vypadajícím jako nahodilé.

Správní rada ICANN trvale vyhradila .internal z delegace v kořeni veřejného DNS v červenci 2024, v návaznosti na dřívější doporučení SSAC. Jména pod ním se záměrně nebudou překládat přes globální DNS. To s sebou nese kompromisy: jména .internal nejsou globálně jedinečná, od veřejných certifikačních autorit se nečeká, že pro ně budou vydávat certifikáty, a resolvery validující DNSSEC podle globální kotvy důvěry je nepřeloží. Pokud potřebujete HTTPS na .internal, počítejte s provozem vlastní privátní CA.

Rozlišujte zde dvě věci. Vyhrazení ze strany ICANN je konečné. Samostatně existuje aktivní Internet-Draft draft-davies-internal-tld-06, zveřejněný 6. května 2026, aby zdokumentoval tento jmenný prostor a porovnal jej s privátním adresováním podle RFC 1918. Zůstává rozpracovaným Internet-Draftem, nikoli vydanou RFC, takže .internal popisujte jako doménu nejvyšší úrovně pro soukromé použití vyhrazenou ICANN, nikoli jako standard IETF.

Pro většinu flotil VPS je bezpečnější výchozí volbou subdoména domény, kterou spravujete. ISC doporučuje hierarchii subdomén, například interní subdoménu vlastní domény, před udržováním oddělených a neúplných interních a veřejných verzí téže nadřazené zóny. Tato preference není otázkou stylu; předchází selhání popsanému v další části.

Shrnutí sekce: rozhodnutí o jmenném prostoru vydrží dlouho. Subdoména, kterou spravujete, je výchozí volbou pro většinu produkčních prostředí, protože zachovává globální jedinečnost a funguje s veřejnou PKI. .internal použijte tehdy, když se izolovaný privátní jmenný prostor hodí lépe a přijímáte jeho kompromisy ohledně DNSSEC, certifikátů a kolizí.

Split-horizon DNS a chyby, které jej rozbíjejí

Split-horizon DNS vrací pro tentýž název hostitele různou odpověď podle toho, kdo se ptá: zevnitř privátní IP, zvenčí veřejnou. Nejčastěji se láme kvůli pasti NXDOMAIN v rámci téže domény, kvůli alternativním resolverům obcházejícím zamýšlený pohled a kvůli DNS cestám v kontejnerech, které nedosáhnou na očekávaný nadřazený server. Udělat to správně závisí na třech věcech naráz, ne na jedné.

Past NXDOMAIN je právě to selhání, před nímž ISC přímo varuje. Pokud jsou vaše interní servery autoritativní pro nadřazenou doménu, ale jejich verze zóny neobsahuje veřejný záznam, například hostitele www, interní klient dotazující se na to jméno dostane NXDOMAIN, přestože veřejná zóna záznam má. Interní zóna je autoritativní a pro nadřazenou doménu se nevrací k veřejnému DNS. Přesně proto je přístup s hierarchií subdomén ze sekce o pojmenování designem, který ISC upřednostňuje.

Tip: Než své servery nasměrujete na split-horizon nastavení v rámci téže domény, vyzkoušejte zevnitř sítě překlad známého veřejného jména v této doméně. Odpověď NXDOMAIN u jména, které zvenčí překládá bez potíží, je podpisem této pasti.

Další tři úskalí se snadno přehlédnou. Alternativní resolver nastavený na hostiteli nebo v kontejneru může toto rozdělení obejít; podle implementace resolveru se na něj lze dotazovat po vypršení časového limitu nebo souběžně, takže odpovědi se mohou lišit. Kontejnery na výchozím můstku Dockeru dostávají při startu kopii DNS konfigurace hostitele, zatímco kontejnery ve vlastních sítích se dotazují vestavěného resolveru Dockeru na adrese 127.0.0.11. Tento resolver přeposílá externí dotazy na DNS servery nastavené pro hostitele nebo kontejner, takže chování split-DNS závisí na konfiguraci Dockeru a hostitele, nikoli jen na vlastním souboru resolveru uvnitř kontejneru. Pokud interní služba stojí za reverzní proxy, jako je Správce proxy Nginx, může validace certifikátu selhat, když certifikát nepokrývá požadovaný název hostitele nebo jeho vydávající CA není u klienta důvěryhodná. Používat interně jiný certifikát samo o sobě chyba není. Jde o mezery v konfiguraci, ne o chyby nástrojů.

Vzdálení klienti mohou narazit na totéž selhání, když vlastní hostovaná VPN nepředává ani nesměruje DNS dotazy na zamýšlený interní resolver.

Je tu i bezpečnostní rozměr. Pokud interní názvy hostitelů a privátní IP adresy proniknou do veřejných DNS záznamů, odhalili jste část svého interního schématu pojmenování a adresování komukoli, kdo se zeptá. Split-horizon zčásti existuje proto, aby tato mapa zůstala uvnitř, a špatně nastavená veřejná zóna to tiše ruší.

Shrnutí sekce: selhání split-horizonu jsou pasti v konfiguraci, ne vady nástrojů. Správnost závisí na kázni v pojmenování, na tom, zda víte, kterého resolveru se každý klient skutečně ptá, a na správném rozsahu zóny, nikoli na jediném nastavení.

ČTĚTE

Jak nasměrovat doménu na VPS: stručný návod

Závěr: jak zvolit správný návrh privátního DNS

Teď dokážete určit, který systém zvaný „privátní DNS“ vlastně máte na mysli. V sítích VPS je to interní DNS zóna, nikoli nastavení DNS-over-TLS v Androidu ani značkové autoritativní jmenné servery. Pokud je vaše flotila malá a stabilní, /etc/hosts je obhajitelná volba. Pokud ne, použijte jako výchozí jmenný prostor subdoménu, kterou vlastníte, zvolte nejmenší DNS server, který flotile vyhovuje, a mějte explicitně vyřešený přístup, redundanci i rozsah interní versus veřejné zóny. .internal použijte jen tehdy, když se izolovaný jmenný prostor hodí lépe a přijímáte jeho kompromisy ohledně certifikátů, DNSSEC a kolizí.

Časté dotazy