Privát DNS VPS-hálózatokhoz: hogyan működik, és mikor van rá szükség

Elindít egy harmadik szervert, azt szeretné, hogy a gépek név alapján érjék el egymást IP helyett, és rákeres a „private DNS VPS” kifejezésre. Három találat jön vissza, és nem egyeznek. Az egyik egy Android-beállítás, amely titkosítja a telefon lekérdezéseit. A másik egy cPanel-útmutató egy domain névszervereinek márkázásához. A harmadik egy AWS-dokumentum a privát hosted zone-okról. 2026. július 20-án A Cloudflare általánosan elérhetővé tette az Internal DNS-t és úgy írta le, mint amit „néha privát DNS-nek is neveznek”, így az ütközés immár az infrastruktúra-szállítók felől is érkezik.

A kifejezés túlterhelt. Ez a cikk szétválasztja a különböző jelentéseket, majd a VPS-hálózati jelentésre összpontosít: egy belső DNS-zónára a szerverek közötti kommunikációhoz. A végére felismeri, melyik rendszerre van szüksége, eldöntheti, hogy a géppark igényel-e privát DNS-t, és elkerülheti a gyakori tervezési hibákat.

Röviden

• A „privát DNS” legalább három, egymással nem összefüggő rendszert jelöl: egy belső DNS-zónát egy szerverhálózathoz, az Android DNS-over-TLS titkosítási funkcióját és a cPanel márkázott névszervereit. Ez a cikk az első értelemben használja a kifejezést: belső DNS-zóna egy VPS-hálózathoz.
• A VPS privát DNS-zónája egy hálózatra korlátozott belső névtér, amely az olyan gépneveket, mint a db.internal.example.com privát IP-címekre képezi le. A rekordjai nem jelennek meg a nyilvános DNS-ben.
• Néhány, állandó IP-címmel rendelkező szerver esetén a /etc/hosts valóban elegendő. Egy belső DNS-szerver akkor térül meg, ha a géppark növekszik, az IP-címek gyakran változnak, vagy a szolgáltatásoknak megbízható névfeloldásra van szükségük.
• A legtöbb éles VPS-hálózathoz használjon saját tulajdonú aldomaint, például internal.example.com. A .internal névteret csak olyan elszigetelt környezetben használja, ahol elfogadható a hálózatok közötti névütközés, a privát CA-val végzett tanúsítványkezelés és a DNSSEC speciális kezelése. Kerülje a .local használatát, amelyet az mDNS foglal le.

Amit ez a cikk nem tárgyal

Ez az írás a privát DNS VPS-hálózati jelentésénél marad. Nem tér ki a nem ide tartozó fogyasztói és tárhelyszolgáltatói felhasználásokra:

• Az Android privát DNS vagy DNS-over-TLS beállításának konfigurálása telefonon.
• cPanel privát névszerverek beállítása egy tárhelymárkához.
• Teljes telepítési útmutató a BIND 9, Unbound, dnsmasq vagy CoreDNS rendszerhez. A megvalósítás itt referenciaszinten marad, nem lépésről lépésre haladó konfiguráció.
• Titkosított, fogyasztói feloldók, például az 1.1.1.1 vagy a NextDNS, azon túl, hogy elhatároljuk őket a hálózati jelentéstől.

Mit jelent valójában a „privát DNS”?

A „privát DNS” nem egyetlen rendszer. A kifejezés legalább három, egymással nem összefüggő dolgot jelöl: egy hálózatra korlátozott DNS-zónát, amely egy VPS- vagy VPC-hálózaton belül oldja fel a belső gépneveket, az Android DNS-over-TLS titkosítási funkcióját, valamint a cPanel egyedi márkázású mérvadó névszervereit. Ez a cikk az elsővel foglalkozik: azzal a belső zónával, amelyet a szerverei lekérdeznek, hogy megtalálják egymást. Létezik egy negyedik, lazább használat is: titkosított nyilvános feloldók, amelyeket „privátként” hirdetnek.

A négy jelentésben csak a név közös, semmi más:

A Cloudflare bejelentése az Internal DNS általános elérhetőségéről bejelentése az első jelentés aktuális, menedzselt példája, és egyben az egyik oka annak, hogy az ütközés most vált láthatóvá: egy infrastruktúra-szállító mostantól a „privát DNS”-t a belső DNS szinonimájaként használja a bevezető szövegeiben. A leírt rendszer, vagyis a Gateway Resolver az Internal Authoritative DNS-szel az Enterprise ügyfelek számára, ugyanabba a kategóriába tartozik, mint amit Ön maga épít fel egy VPS-parkon, csak menedzselt formában.

A szakasz tanulsága: a „privát DNS” néven futó fő rendszerekben a címke közös, nem a funkció. Tisztázza, melyik jelentésről van szó, mielőtt bármilyen beállítási útmutatót követne.

Hogyan működik a privát DNS egy VPS-hálózatban?

A VPS privát DNS-zónája egy hálózatra korlátozott névtér, amelyet egy olyan feloldó szolgál ki, amelynek használatára a szerverei be vannak állítva. A belső gépneveket, például a db.internal.example.com az Ön által felügyelt tartományba eső privát IP-címekre képezi le. A rekordok nem jelennek meg a nyilvános DNS-ben, még ha a lekérdezések privát alagúton vagy menedzselt DNS-vezérlősíkon át jutnak is el a feloldóhoz. Éppen ez az elkülönítés a privát és a nyilvános DNS közötti különbség lényege: a protokoll ugyanaz, de a zóna láthatósága és hozzáférési köre más.

Három rész végzi a munkát. Egy mérvadó szerver vagy zónaforrás tárolja a belső zónát és annak rekordjait. Egy feloldó válaszol a szerverei által küldött lekérdezésekre. A zóna A és AAAA rekordjai pedig a belső gépneveket privát címekre képezik le, így a app.internal.example.com az alkalmazásrétegre oldódik fel, a db.internal.example.com az adatbázisra oldódik fel. Más rekordtípusok álneveket vagy szolgáltatásinformációkat adhatnak. Ha a zóna és a feloldó útvonala megfelelően van beállítva, a feloldó helyben válaszolja meg a belső lekérdezést ahelyett, hogy a nyilvános DNS-gyökér felé küldené.

A felhőplatformok ezt a hálózathoz kötik, nem a géphez, ami hasznos referenciamodell. Az AWS Route 53 privát hosted zone-jai csak akkor működnek, ha a VPC-ben az enableDnsHostnames és az enableDnsSupport is true értékű, a feloldó pedig a privát zónából válaszol minden hozzá társított VPC esetén. A Google Cloud privát zónái az engedélyezett VPC-hálózatokra korlátozódnak, és a szabványos VPC-feloldási sorrendben a nyilvános DNS előtt ellenőrzi őket a rendszer, hacsak egy kimenő szerverházirend meg nem változtatja az útvonalat. Ezeket a minta szemléltetéseként olvassa, nem platformoktatóként: egy saját üzemeltetésű belső DNS-szerver ugyanez az elgondolás, csak a saját VPS-én futtatva.

A zóna nyilvános DNS-en kívül tartása csak a munka fele. Kösse a DNS-szolgáltatást privát interfészhez, vagy korlátozza az 53-as UDP- és TCP-portot a privát hálózatára vagy VPN-jére. Ne tegye ki a rekurzív szolgáltatást a nyilvános internetnek; hiszen egy nyílt feloldó visszaélésre használható DNS-erősítéses támadásokban.

A privát és a nyilvános zónák ugyanazt a DNS-rekord- és gyorsítótármodellt használják. A rekordokhoz TTL tartozik, és a gyorsítótárazó feloldók rendszerint addig használják újra a választ, amíg ez a TTL le nem jár, bár a feloldóra jellemző beállítások módosíthatják a tényleges gyorsítótárazási időt. Ezt a viselkedést a domain VPS-re irányításáról szóló útmutatónkban tárgyaljuk, beleértve a DNS-terjedés és TTL alapjait, ezért itt nem magyarázzuk el újra.

Mikor van valóban szüksége a VPS-hálózatának privát DNS-re?

Két-három állandó szerver esetén a /etc/hosts valóban elegendő. Egy belső DNS-szerver akkor térül meg, ha a géppark növekszik, az IP-címek rendszeresen változnak, vagy az alkalmazásoknak megbízható szolgáltatásfelderítésre van szükségük. A tényleges kiváltó ok az üzemeltetési bonyolultság, nem egy rögzített szerverszám.

/etc/hosts egy statikus gépnév–IP megfeleltetés, amely már minden Linux-gépen ott van. Nem kell hozzá démon vagy zónafájl, de az elavult vagy egymástól eltérő másolatok valós hibaforrások. Vegye fel minden szerver privát IP-címét a fájlba, tartsa szinkronban a másolatokat, és a gépek név alapján megtalálják egymást. Kicsi, állandó gépparknál ez a helyes válasz, a BIND 9 bevetése helyette csupán egy karbantartandó démont ad hozzá minden haszon nélkül.

Három helyzetben akad el. Ha gyakran vesz fel és távolít el szervereket, egy statikus fájl minden gépen való egyben tartása kézi robottá válik. Ha az IP-címek automatikus skálázás, újraépítés vagy a szolgáltatói újrakiosztás miatt változnak, a fájl csendben elavul. Ha pedig a konténerek vagy az elszigetelt futtatókörnyezetek nem öröklik a gazdagép bejegyzéseit, a leképezés megszűnik általánosnak lenni. Bármelyikük önmagában a valódi kiváltó ok. A szerverek száma önmagában csak durva közelítés, nem a tényleges jelzés.

A szakasz tanulsága: a kiváltó ok az üzemeltetési mozgás, nem a szerverek száma. Egy befagyasztott, tízgépes géppark elvan a /etc/hostsfájllal; egy háromgépes, éjszakánként újraépülő géppark viszont valószínűleg nem.

Melyik DNS-szervert érdemes futtatni: BIND 9, Unbound, dnsmasq vagy CoreDNS?

A géppark alakja alapján válasszon. A dnsmasq olyan kis hálózatokhoz illik, amelyek könnyű DNS-t, és ahol releváns, ugyanabból a démonból DHCP-t is szeretnének. Az Unbound egy karcsú, ellenőrző rekurzív feloldó, amely egy szerény helyi zónát is ki tud szolgálni. A BIND 9 széles körű mérvadó és rekurzív képességeket ad, a legnagyobb konfigurációs felülettel. A CoreDNS a konténeres és Kubernetes-gépparkokhoz illik, ahol a DNS a szolgáltatásfelderítés része.

A választás logikája rövid. Ha egy hosts-szerű fájlra támaszkodó kis feloldóra van szüksége, vagy amúgy is DHCP-bérleteket oszt, a dnsmasq egy mozgó alkatrésszel kevesebbet jelent. Ha főként olyan ellenőrző feloldóra van szüksége, amely kifelé továbbít és egy szerény belső zónát szolgál ki, az Unbound pontosan ezt a szűkebb funkciókészletet adja teljes BIND 9-telepítés nélkül. Ha teljes mérvadó felügyeletre, delegálásra és a legnagyobb dokumentációs bázisra van szüksége, amelyre hajnali háromkor támaszkodhat, a BIND 9 marad az óvatos választás a szélesebb konfigurációs felület ellenére. Ha a DNS már egy konténeres vagy Kubernetes-alapú szolgáltatásfelderítési rendszer része, a CoreDNS ott találkozik vele. Az ökölszabály: a legkisebb dolgot futtassa, amely lefedi a géppark alakját.

Éles gépparkban ne tegyen egyetlen DNS-példányt az egyetlen úttá minden belső névhez. Futtasson legalább két DNS-példányt amelyek ki tudják szolgálni a zónát, helyezze őket lehetőség szerint külön hibatartományba, és állítsa be a klienseket úgy, hogy mindkettőt elérjék. Különben egyetlen DNS-kiesés is halottnak mutathat egészséges szolgáltatásokat.

Hogyan nevezze el a belső domainjét: .internal, .local vagy aldomain?

A legtöbb éles VPS-hálózathoz használjon saját tulajdonú aldomaint, például internal.example.com. A .internal névteret csak olyan elszigetelt környezetben használja, ahol elfogadható a hálózatok közötti névütközés, a privát CA-val végzett tanúsítványkezelés és a DNSSEC speciális kezelése. Kerülje a .local használatát, amelyet az mDNS foglal le.

A .local problémája kézzelfogható. RFC 6762 a .local végződésű neveknek külön kezelést ad a Multicast DNS keretében, ezért egy ugyanezt a végződést használó unicast BIND 9- vagy Unbound-zóna ütközhet az mDNS viselkedésével Apple-eszközökön és más mDNS-képes rendszereken. Használjon másik névteret ahelyett, hogy klienshez kötött kerülőmegoldásokra hagyatkozna.

Profi tipp: Ha örökölt egy .local belső zónát, tekintse technikai adósságnak. Egyes kliensek a .local lekérdezéseket az mDNS felé küldik a unicast DNS-szervere helyett, ami klienstől függő vagy szakaszosnak tűnő hibákat okozhat.

Az ICANN igazgatótanácsa véglegesen fenntartotta a .internal domaint a nyilvános DNS-gyökérben történő delegálástól 2024 júliusában, egy korábbi SSAC-ajánlás nyomán. Az alatta lévő nevek tervezetten nem oldódnak fel a globális DNS-en keresztül. Ez kompromisszumokkal jár: a .internal nevek nem globálisan egyediek, a nyilvános hitelesítésszolgáltatóktól nem várható, hogy tanúsítványt adjanak ki rájuk, és a globális bizalmi horgonyra támaszkodó, DNSSEC-et ellenőrző feloldók nem tudják feloldani őket. Ha HTTPS kell a .internal alatt, tervezzen be egy saját privát CA üzemeltetését.

Itt két dolgot érdemes elkülöníteni. Az ICANN fenntartása végleges. Ettől függetlenül egy aktív Internet-Draft, a draft-davies-internal-tld-06, amely 2026. május 6-án jelent meg, hogy dokumentálja a névteret, és összevesse az RFC 1918 szerinti privát címzéssel. Ez továbbra is munkában lévő Internet-Draft, nem kiadott RFC, ezért a .internal domaint ICANN által fenntartott, privát használatú legfelső szintű domainként írja le, ne IETF-szabványként.

A legtöbb VPS-géppark esetén az Ön által felügyelt domain aldomainje a biztonságosabb alapértelmezés. Az ISC aldomain-hierarchiát javasol, például a saját domainje egy belső aldomainjét, ahelyett hogy ugyanannak a szülőzónának külön és hiányos belső, illetve nyilvános változatát tartaná karban. Ez a preferencia nem stílus kérdése: megelőzi a következő szakaszban tárgyalt hibát.

A szakasz tanulsága: a névtérről hozott döntés hosszú életű. Az Ön által felügyelt aldomain a legtöbb éles környezetben az alapértelmezés, mert megőrzi a globális egyediséget, és működik a nyilvános PKI-val. A .internal akkor jó, ha egy elszigetelt privát névtér illik jobban, és elfogadja a DNSSEC-cel, a tanúsítványokkal és a névütközésekkel járó kompromisszumokat.

Split-horizon DNS és a hibák, amelyek elrontják

A split-horizon DNS ugyanarra a gépnévre attól függően ad más választ, hogy ki kérdez: belülről a privát IP-t, kívülről a nyilvánosat. Leggyakrabban az azonos domainen belüli NXDOMAIN csapda, a szándékolt nézetet megkerülő alternatív feloldók és a várt fölérendelt szervert el nem érő konténeres DNS-útvonalak miatt romlik el. Ahhoz, hogy jól működjön, egyszerre három dolognak kell stimmelnie, nem egynek.

Az NXDOMAIN-csapda pontosan az a hiba, amelyre az ISC közvetlenül figyelmeztet. Ha a belső szerverei mérvadók a szülődomainre, de a zóna náluk lévő változata nem tartalmaz egy nyilvános rekordot, például a www gépet, akkor az ezt a nevet lekérdező belső kliens NXDOMAIN választ kap, jóllehet a nyilvános zónában szerepel. A belső zóna mérvadó, és a szülődomain esetén nem tér vissza a nyilvános DNS-hez. Pontosan ezért az elnevezésről szóló szakasz aldomain-hierarchiás megközelítése az a felépítés, amelyet az ISC előnyben részesít.

Profi tipp: Mielőtt a szervereit egy azonos domainen belüli split-horizon felállásra irányítaná, próbáljon meg a hálózaton belülről feloldani egy ismert nyilvános nevet abban a domainben. Ha NXDOMAIN érkezik olyan névre, amely kívülről gond nélkül feloldódik, az ennek a csapdának a kézjegye.

További három buktatót könnyű elnézni. Egy gazdagépen vagy konténerben beállított alternatív feloldó megkerülheti a szétválasztást; a feloldó megvalósításától függően időtúllépés után vagy párhuzamosan is lekérdezhető, így a válaszok eltérhetnek. A Docker alapértelmezett hídján lévő konténerek induláskor megkapják a gazdagép DNS-beállításának másolatát, míg az egyedi hálózatokon futó konténerek a Docker beépített feloldóját kérdezik a 127.0.0.11címen. Ez a feloldó a külső lekérdezéseket a gazdagéphez vagy a konténerhez beállított DNS-szerverek felé továbbítja, így a split-DNS viselkedése a Docker és a gazdagép beállításain múlik, nem pusztán a konténer saját feloldófájlján. Ha egy belső szolgáltatás fordított proxy mögött van, például a Nginx Proxy Manager, a tanúsítvány ellenőrzése elbukhat, ha a tanúsítvány nem fedi le a kért gépnevet, vagy ha a kibocsátó hitelesítésszolgáltatóban a kliens nem bízik meg. Önmagában az, hogy belül más tanúsítványt használ, nem hiba. Ezek konfigurációs hézagok, nem az eszközök hibái.

A távoli kliensek ugyanebbe a hibába futhatnak, ha egy saját üzemeltetésű VPN nem továbbítja vagy irányítja a DNS-lekérdezéseket a szándékolt belső feloldóhoz.

Van egy biztonsági vetület is. Ha belső gépnevek és privát IP-címek szivárognak ki nyilvános DNS-rekordokba, akkor a belső elnevezési és címzési sémája egy részét bárki előtt feltárta, aki lekérdezi. A split-horizon részben épp azért van, hogy ez a térkép bent maradjon, és egy rosszul beállított nyilvános zóna ezt csendben lerontja.

A szakasz tanulsága: a split-horizon hibái konfigurációs csapdák, nem az eszközök hiányosságai. A helyesség az elnevezési fegyelmen, azon, hogy tudja, melyik feloldót kérdezi valójában az egyes kliensek, és a zóna megfelelő lehatárolásán múlik, nem egyetlen beállításon.

OLVASD

Domain beállítása VPS kiszolgálóra: Gyors útmutató

Összegzés: a megfelelő privát DNS-felépítés kiválasztása

Most már meg tudja állapítani, melyik „privát DNS” rendszerre gondol valójában. VPS-hálózat esetén ez a belső DNS-zóna, nem az Android DNS-over-TLS beállítása vagy a márkázott mérvadó névszerverek. Ha a gépparkja kicsi és állandó, a /etc/hosts védhető választás. Ha nem, akkor alapértelmezett névtérként használjon saját tulajdonú aldomaint, válassza a gépparkhoz illő legkisebb DNS-szervert, és tartsa kimondottan rendezettnek a hozzáférést, a redundanciát, valamint a belső és a nyilvános zóna határát. A .internal domaint csak akkor használja, ha egy elszigetelt névtér illik jobban, és elfogadja a tanúsítványokkal, a DNSSEC-cel és a névütközésekkel járó kompromisszumokat.

Gyakran ismételt kérdések

Az Android privát DNS-e ugyanaz, mint egy privát DNS-szerver egy VPS-en?

Nem. Az Android privát DNS-e egy DNS-over-TLS funkció (lekérdezéstitkosítás a 853-as porton, az Android 9-től), amely az eszköz lekérdezéseit védi átvitel közben. Egy VPS-en futó privát DNS-szerver a belső gépneveket oldja fel privát IP-címekre egy hálózaton belül. Az egyik titkosítja a lekérdezéseket, a másik belső névteret hoz létre. Egymástól független problémákat oldanak meg.

Mi a különbség a privát és a nyilvános DNS között?

A privát DNS egy zónát csak egy adott hálózat, VPN vagy felhőkörnyezet jogosult kliensei számára tesz elérhetővé. A nyilvános DNS olyan rekordokat tesz közzé, amelyeket az interneten lévő feloldók lekérdezhetnek. Mindkettő ugyanazokat a DNS-rekordtípusokat és ugyanazt a gyorsítótármodellt használja; a különbség az, hogy ki éri el a zónát, és hol láthatók a rekordjai.

Mi a különbség a privát és a titkosított DNS között?

A titkosított DNS-protokollok, például a DoT és a DoH, a DNS-lekérdezéseket védik átvitel közben. A hálózati értelemben vett privát DNS hálózatra korlátozott névteret hoz létre a belső nevek számára. A titkosítás azt változtatja meg, hogyan utazik a lekérdezés; a privát zóna azt, hogy mely nevek léteznek, és ki tudja feloldani őket.

Biztonságos a .internal használata belső gépnevekhez?

Igen, fenntartásokkal. Az ICANN 2024 júliusában véglegesen kizárta a .internal domaint a nyilvános delegálásból, így privát feloldón kiszolgálhatja. Ugyanakkor nem globálisan egyedi, a nyilvános hitelesítésszolgáltatóktól nem várható, hogy tanúsítványt adjanak ki rá, és a globális bizalmi horgonyra támaszkodó DNSSEC-ellenőrzők nem tudják feloldani. A legtöbb éles VPS-hálózat esetén egy saját tulajdonú aldomain a biztonságosabb alapértelmezés.

A privát DNS-rekordok ugyanazt a TTL-t és gyorsítótárazást használják, mint a nyilvános DNS?

Igen. A privát és a nyilvános zónák ugyanazt a TTL-alapú gyorsítótármodellt használják: a rekordokhoz TTL tartozik, és a gyorsítótárazó feloldók rendszerint addig használják újra a választ, amíg ez az érték le nem jár. A feloldóra jellemző beállítások ettől még módosíthatják a tényleges gyorsítótárazási időt. Lásd: DNS-terjedés és TTL-viselkedés az alapjául szolgáló működésért.