Privé-DNS voor VPS-netwerken: hoe het werkt en wanneer je het nodig hebt

Je start een derde server, wilt dat de machines elkaar op naam bereiken in plaats van op IP, en zoekt op "private DNS VPS". Er komen drie resultaten terug en ze spreken elkaar tegen. Eén is een Android-instelling die de lookups van je telefoon versleutelt. Eén is een cPanel-handleiding om nameservers van een domein te branden. Eén is een AWS-document over private hosted zones. Op 20 juli 2026 Cloudflare bracht Internal DNS uit in algemene beschikbaarheid en beschreef het als "soms ook privé-DNS genoemd", waardoor de verwarring nu ook van infrastructuurleveranciers komt.

De term is overladen. Dit artikel scheidt de verschillende betekenissen en richt zich vervolgens op de VPS-netwerkbetekenis: een interne DNS-zone voor communicatie tussen servers. Aan het eind kun je bepalen welk systeem je nodig hebt, beslissen of je serverpark privé-DNS vereist en veelgemaakte ontwerpfouten vermijden.

TL;DR

• "Privé-DNS" duidt minstens drie ongerelateerde systemen aan: een interne DNS-zone voor een servernetwerk, de DNS-over-TLS-versleutelingsfunctie van Android en de gebrande nameservers van cPanel. Dit artikel gebruikt de term in de eerste betekenis: een interne DNS-zone voor een VPS-netwerk.
• Een privé-DNS-zone van een VPS is een tot het netwerk beperkte interne naamruimte die hostnamen zoals db.internal.example.com koppelt aan privé-IP's. De records ervan worden niet gepubliceerd in het publieke DNS.
• Voor een handvol servers met stabiele IP's is /etc/hosts echt genoeg. Een interne DNS-server verdient zichzelf terug zodra het serverpark groeit, IP's vaak wisselen of diensten betrouwbare naamresolutie nodig hebben.
• Gebruik voor de meeste productie-VPS-netwerken een subdomein dat je zelf bezit, zoals internal.example.com. Gebruik de naamruimte .internal alleen voor een geïsoleerde opzet waarin naamconflicten tussen netwerken, certificaatbeheer via een private CA en een bijzondere DNSSEC-afhandeling acceptabel zijn. Vermijd .local, dat door mDNS is gereserveerd.

Wat dit artikel niet behandelt

Dit stuk blijft beperkt tot de VPS-netwerkbetekenis van privé-DNS. Het behandelt geen losstaande consumenten- en hostingmerktoepassingen:

• De instelling voor privé-DNS of DNS-over-TLS van Android op een telefoon configureren.
• Privé-nameservers in cPanel opzetten voor een hostingmerk.
• Een volledige installatiehandleiding voor BIND 9, Unbound, dnsmasq of CoreDNS. De implementatie blijft hier op referentieniveau, niet op stapsgewijze configuratie.
• Versleutelde consumentenresolvers zoals 1.1.1.1 of NextDNS, verder dan het onderscheid met de netwerkbetekenis.

Wat betekent "privé-DNS" eigenlijk?

"Privé-DNS" is niet één systeem. De term duidt minstens drie ongerelateerde systemen aan: een tot het netwerk beperkte DNS-zone die interne hostnamen binnen een VPS- of VPC-netwerk resolvet, de DNS-over-TLS-versleutelingsfunctie van Android en de op maat gebrande autoritatieve nameservers van cPanel. Dit artikel behandelt het eerste: de interne zone die je servers bevragen om elkaar te vinden. Er bestaat ook een vierde, losser gebruik: versleutelde publieke resolvers die als "privé" worden vermarkt.

De vier betekenissen delen een naam en verder niets:

De aankondiging van de algemene beschikbaarheid van Internal DNS door Cloudflare is een actueel managed voorbeeld van de eerste betekenis, en een reden waarom de verwarring nu zichtbaar wordt: een infrastructuurleverancier gebruikt "privé-DNS" nu als synoniem voor intern DNS in zijn lanceringstekst. Het beschreven systeem, een Gateway Resolver plus Internal Authoritative DNS voor Enterprise-klanten, hoort tot dezelfde categorie als wat je zelf op een VPS-park bouwt, alleen dan managed.

Conclusie van deze sectie: de belangrijkste systemen die "privé-DNS" heten delen een label, geen functie. Bepaal welke betekenis bedoeld is voordat je een installatiehandleiding volgt.

Hoe werkt privé-DNS op een VPS-netwerk?

Een privé-DNS-zone van een VPS is een tot het netwerk beperkte naamruimte, bediend door een resolver die je servers moeten gebruiken. Ze koppelt interne hostnamen zoals db.internal.example.com aan privé-IP's binnen een bereik dat jij beheert. De records worden niet in het publieke DNS gepubliceerd, ook al kunnen de query's via een private tunnel of een managed DNS-control plane lopen voordat ze de resolver bereiken. Die scheiding vormt de kern van het verschil tussen privé-DNS en publiek DNS: het protocol is hetzelfde, maar de zichtbaarheid van de zone en de toegangsreikwijdte verschillen.

Drie onderdelen doen het werk. Een autoritatieve server of zonebron bevat de interne zone en haar records. Een resolver beantwoordt de query's die je servers versturen. En de A- en AAAA-records van de zone koppelen interne hostnamen aan privé-adressen, waardoor app.internal.example.com naar de applicatielaag verwijst en db.internal.example.com naar de database verwijst. Andere recordtypen kunnen aliassen of service-informatie leveren. Als de zone en het resolverpad juist zijn geconfigureerd, beantwoordt de resolver de interne query lokaal in plaats van hem naar de publieke DNS-root te sturen.

De cloudplatforms koppelen dit aan het netwerk in plaats van aan de machine, wat een nuttig referentiemodel is. Private hosted zones van AWS Route 53 werken alleen als de VPC zowel enableDnsHostnames als enableDnsSupport op true heeft staan, en de resolver antwoordt vanuit de privézone voor elke VPC die je eraan koppelt. Privézones van Google Cloud zijn beperkt tot geautoriseerde VPC-netwerken, en in de standaard resolutievolgorde van een VPC worden ze vóór het publieke DNS geraadpleegd, tenzij een uitgaand serverbeleid het pad wijzigt. Lees dit als illustraties van het patroon, niet als platformhandleidingen: een zelfbeheerde interne DNS-server is hetzelfde idee, draaiend op je eigen VPS.

De zone buiten het publieke DNS houden is maar de helft van het werk. Bind de DNS-dienst aan een privé-interface of beperk UDP- en TCP-poort 53 tot je privénetwerk of VPN. Stel de recursieve dienst niet bloot aan het publieke internet; een open resolver kan worden misbruikt bij DNS-amplificatieaanvallen.

Privé- en publieke zones gebruiken hetzelfde model voor DNS-records en caching. Records dragen een TTL, en cachende resolvers hergebruiken een antwoord normaal gesproken totdat die TTL verloopt, al kunnen resolverspecifieke instellingen de effectieve cachetijd wijzigen. Dat gedrag komt aan bod in onze gids over het laten wijzen van een domein naar een VPS, inclusief de basis van DNS-propagatie en TTL, dus dat wordt hier niet opnieuw uitgelegd.

Wanneer heeft je VPS-netwerk echt privé-DNS nodig?

Voor twee of drie statische servers is /etc/hosts echt genoeg. Een interne DNS-server verdient zichzelf terug wanneer het serverpark groeit, IP's regelmatig wijzigen of applicaties betrouwbare service discovery nodig hebben. De echte trigger is operationele complexiteit, niet een vast aantal servers.

/etc/hosts is een statische toewijzing van hostnaam naar IP die al op elke Linux-machine bestaat. Er is geen daemon of zonebestand voor nodig, maar verouderde of inconsistente kopieën zijn echte faalscenario's. Zet het privé-IP van elke server in het bestand, houd de kopieën gesynchroniseerd, en de machines kunnen elkaar op naam vinden. Voor een klein, stabiel serverpark is dat het juiste antwoord, en in plaats daarvan naar BIND 9 grijpen voegt alleen een te onderhouden daemon toe zonder winst.

Het houdt in drie situaties op te schalen. Wanneer je vaak servers toevoegt en verwijdert, wordt het handmatig zwoegen om een statisch bestand op elke host consistent te houden. Wanneer IP's veranderen door autoscaling, herbouw of herverdeling door de provider, veroudert het bestand geruisloos. En wanneer containers of geïsoleerde runtimes de vermeldingen van de host niet erven, is de koppeling niet langer universeel. Elk van die situaties is de echte trigger. Het aantal servers alleen is een ruwe benadering, niet het eigenlijke signaal.

Conclusie van deze sectie: de trigger is operationele beweeglijkheid, niet het aantal servers. Een bevroren park van tien machines kan prima leven met /etc/hosts; een park van drie machines dat elke nacht opnieuw wordt gebouwd waarschijnlijk niet.

Bouw op een Linux VPS met root-toegang, NVMe en AMD EPYC-kracht.

Bekijk Linux-plannen

Welke DNS-server moet je draaien: BIND 9, Unbound, dnsmasq of CoreDNS?

Kies op basis van de vorm van je serverpark. dnsmasq past bij kleine netwerken die lichtgewicht DNS willen en, waar relevant, DHCP vanuit dezelfde daemon. Unbound is een slanke validerende recursieve resolver die ook een bescheiden lokale zone kan beantwoorden. BIND 9 biedt brede autoritatieve en recursieve mogelijkheden met het grootste configuratieoppervlak. CoreDNS past bij container- en Kubernetes-parken waar DNS deel uitmaakt van service discovery.

De keuzelogica is kort. Heb je een kleine resolver nodig die op een hosts-achtig bestand steunt, of deel je al DHCP-leases uit, dan haalt dnsmasq een bewegend onderdeel weg. Heb je vooral een validerende resolver nodig die naar buiten doorstuurt en een bescheiden interne zone beantwoordt, dan levert Unbound precies dat smallere pakket zonder een volledige BIND 9-uitrol. Heb je volledige autoritatieve controle, delegatie en het grootste corpus documentatie nodig om om 3 uur 's nachts op terug te vallen, dan blijft BIND 9 de behoudende keuze ondanks het bredere configuratieoppervlak. Maakt DNS al deel uit van een container- of Kubernetes-service-discoverystack, dan sluit CoreDNS daar naadloos op aan. De vuistregel: draai het kleinste dat de vorm van je serverpark dekt.

Maak in een productiepark niet één DNS-instantie het enige pad naar elke interne naam. Draai minstens twee DNS-instanties die de zone kunnen beantwoorden, plaats ze waar mogelijk in aparte faaldomeinen en configureer clients zo dat ze beide bereiken. Anders kan één DNS-storing gezonde diensten dood doen lijken.

Hoe moet je je interne domein noemen: .internal, .local of een subdomein?

Gebruik voor de meeste productie-VPS-netwerken een subdomein dat je zelf bezit, zoals internal.example.com. Gebruik de naamruimte .internal alleen voor een geïsoleerde opzet waarin naamconflicten tussen netwerken, certificaatbeheer via een private CA en een bijzondere DNSSEC-afhandeling acceptabel zijn. Vermijd .local, dat door mDNS is gereserveerd.

Het probleem met .local is concreet. RFC 6762 geeft namen die op .local eindigen een speciale behandeling voor Multicast DNS, waardoor een unicastzone in BIND 9 of Unbound met hetzelfde achtervoegsel kan botsen met mDNS-gedrag op Apple-apparaten en andere mDNS-systemen. Gebruik een andere naamruimte in plaats van te leunen op clientspecifieke workarounds.

Pro-tip: heb je een interne .local-zone geërfd, behandel die dan als technische schuld. Sommige clients sturen .local-query's naar mDNS in plaats van naar je unicast-DNS-server, wat clientafhankelijke of ogenschijnlijk sporadische storingen kan opleveren.

Het bestuur van ICANN heeft .internal permanent gereserveerd van delegatie in de publieke DNS-root in juli 2024, na een eerdere aanbeveling van de SSAC. Namen daaronder zullen per ontwerp niet via het wereldwijde DNS resolven. Daar horen afwegingen bij: .internal-namen zijn niet wereldwijd uniek, van publieke certificaatautoriteiten wordt niet verwacht dat ze er certificaten voor uitgeven, en DNSSEC-validerende resolvers die op het wereldwijde trust anchor steunen zullen ze niet kunnen resolven. Heb je HTTPS nodig op .internal, reken dan op het beheren van een private CA.

Houd hier twee dingen uit elkaar. De reservering van ICANN is definitief. Los daarvan is een actieve Internet-Draft, draft-davies-internal-tld-06, gepubliceerd op 6 mei 2026 om de naamruimte te documenteren en te vergelijken met de private adressering uit RFC 1918. Het blijft een Internet-Draft in bewerking en geen gepubliceerde RFC, dus omschrijf .internal als een door ICANN gereserveerde TLD voor privégebruik, niet als een IETF-standaard.

Voor de meeste VPS-parken is een subdomein van een domein dat je zelf beheert de veiligere standaardkeuze. ISC beveelt een subdomeinhiërarchie aan, zoals een intern subdomein van je eigen domein, boven het onderhouden van gescheiden en onvolledige interne en publieke versies van dezelfde bovenliggende zone. Die voorkeur is geen stijlkwestie: ze voorkomt de storing uit de volgende paragraaf.

Conclusie van deze sectie: de keuze van naamruimte gaat lang mee. Een subdomein dat je zelf beheert is de standaard voor de meeste productieomgevingen, omdat het wereldwijde uniciteit behoudt en met publieke PKI werkt. Gebruik .internal wanneer een geïsoleerde privénaamruimte beter past en je de afwegingen rond DNSSEC, certificaten en naamconflicten accepteert.

Split-horizon-DNS en de fouten die het slopen

Split-horizon-DNS geeft voor dezelfde hostnaam een ander antwoord afhankelijk van wie het vraagt: intern het privé-IP, extern het publieke IP. Het gaat het vaakst stuk door de NXDOMAIN val binnen hetzelfde domein, door alternatieve resolvers die de bedoelde view omzeilen, en door DNS-paden in containers die de verwachte upstream niet bereiken. Het goed krijgen hangt van drie dingen tegelijk af, niet van één.

De NXDOMAIN-val is precies de storing waarvoor ISC rechtstreeks waarschuwt. Als je interne servers autoritatief zijn voor het bovenliggende domein, maar hun versie van de zone een publiek record zoals de www-host mist, krijgt een interne client die die naam opvraagt NXDOMAIN terug, ook al staat het record wél in de publieke zone. De interne zone is autoritatief en valt voor het bovenliggende domein niet terug op het publieke DNS. Precies daarom is de subdomeinhiërarchie uit de naamgevingsparagraaf het ontwerp dat ISC verkiest.

Pro-tip: voordat je je servers op een split-horizonopzet binnen hetzelfde domein richt, test je vanuit het netwerk een lookup van een bekende publieke naam in dat domein. Een NXDOMAIN-antwoord voor een naam die extern prima resolvet, is het handschrift van deze val.

Drie andere valkuilen worden makkelijk over het hoofd gezien. Een alternatieve resolver die op een host of container is ingesteld, kan de scheiding omzeilen; afhankelijk van de resolverimplementatie wordt hij na een time-out of parallel bevraagd, waardoor antwoorden kunnen verschillen. Containers op Dockers standaardbridge krijgen bij het starten een kopie van de DNS-configuratie van de host, terwijl containers op eigen netwerken Dockers ingebouwde resolver bevragen op 127.0.0.11. Die resolver stuurt externe lookups door naar de DNS-servers die voor de host of container zijn ingesteld, dus het split-DNS-gedrag hangt af van de Docker- en hostconfiguratie en niet alleen van het eigen resolverbestand van de container. Zit een interne dienst achter een reverse proxy zoals Nginx Proxy Manager, dan kan de certificaatvalidatie mislukken wanneer het certificaat de gevraagde hostnaam niet dekt of de uitgevende CA niet door de client wordt vertrouwd. Intern simpelweg een ander certificaat gebruiken is op zich geen fout. Dit zijn configuratiegaten, geen bugs in de tools.

Externe clients kunnen tegen dezelfde storing aanlopen wanneer een zelfgehoste VPN de DNS-query's niet naar de bedoelde interne resolver duwt of routeert.

Er is ook een beveiligingsdimensie. Als interne hostnamen en privé-IP's in publieke DNS-records lekken, heb je een deel van je interne naam- en adresschema blootgelegd voor iedereen die het opvraagt. Split-horizon bestaat mede om die kaart binnen te houden, en een verkeerd geconfigureerde publieke zone maakt dat stilletjes ongedaan.

Conclusie van deze sectie: de storingen van split-horizon zijn configuratievallen, geen gebreken van de tools. Correctheid hangt af van naamgevingsdiscipline, van weten welke resolver elke client daadwerkelijk bevraagt, en van een juist afgebakende zone, niet van één enkele instelling.

LEES

Hoe koppel je een domeinnaam aan een VPS: een beknopte gids

Conclusie: het juiste privé-DNS-ontwerp kiezen

Je kunt nu bepalen welk "privé-DNS"-systeem je eigenlijk bedoelt. Voor VPS-netwerken is dat de interne DNS-zone, niet de DNS-over-TLS-instelling van Android of gebrande autoritatieve nameservers. Is je serverpark klein en stabiel, dan is /etc/hosts een verdedigbare keuze. Zo niet, neem dan een subdomein dat je zelf bezit als standaardnaamruimte, kies de kleinste DNS-server die bij het park past, en houd toegang, redundantie en de interne versus publieke zonereikwijdte expliciet. Gebruik .internal alleen wanneer een geïsoleerde naamruimte beter past en je de afwegingen rond certificaten, DNSSEC en naamconflicten accepteert.

Veelgestelde vragen