Privates DNS für VPS-Netzwerke: So funktioniert es und wann Sie es brauchen

Sie starten einen dritten Server, wollen, dass sich die Maschinen über Namen statt über IP erreichen, und suchen nach „private DNS VPS“. Drei Ergebnisse kommen zurück, und sie widersprechen sich. Eines ist eine Android-Einstellung, die die Abfragen Ihres Telefons verschlüsselt. Eines ist eine cPanel-Anleitung, um Nameserver einer Domain zu branden. Eines ist ein AWS-Dokument über private Hosted Zones. Am 20. Juli 2026 Cloudflare hat Internal DNS allgemein verfügbar gemacht und beschrieb es als „manchmal auch als privates DNS bezeichnet“, sodass die Verwechslung jetzt auch von Infrastrukturanbietern kommt.

Der Begriff ist überladen. Dieser Artikel trennt die verschiedenen Bedeutungen und konzentriert sich dann auf die VPS-Netzwerkbedeutung: eine interne DNS-Zone für die Kommunikation zwischen Servern. Am Ende können Sie erkennen, welches System Sie brauchen, entscheiden, ob Ihre Flotte privates DNS benötigt, und häufige Designfehler vermeiden.

Kurzfassung

• „Privates DNS“ bezeichnet mindestens drei nicht verwandte Systeme: eine interne DNS-Zone für ein Servernetzwerk, die DNS-over-TLS-Verschlüsselungsfunktion von Android und die gebrandeten Nameserver von cPanel. Dieser Artikel verwendet den Begriff im ersten Sinn: eine interne DNS-Zone für ein VPS-Netzwerk.
• Eine private DNS-Zone eines VPS ist ein netzwerkbezogener interner Namensraum, der Hostnamen wie db.internal.example.com privaten IPs zuordnet. Ihre Einträge werden nicht im öffentlichen DNS veröffentlicht.
• Für eine Handvoll Server mit stabilen IPs ist /etc/hosts wirklich ausreichend. Ein interner DNS-Server rechnet sich, sobald die Flotte wächst, IPs häufig wechseln oder Dienste eine verlässliche Namensauflösung brauchen.
• Verwenden Sie für die meisten produktiven VPS-Netzwerke eine Subdomain, die Ihnen gehört, etwa internal.example.com. Nutzen Sie den Namensraum .internal nur für ein isoliertes Setup, in dem Namenskollisionen zwischen Netzwerken, die Zertifikatsverwaltung über eine private CA und eine spezielle DNSSEC-Behandlung akzeptabel sind. Vermeiden Sie .local, das mDNS reserviert.

Was dieser Artikel nicht behandelt

Dieser Beitrag beschränkt sich auf die VPS-Netzwerkbedeutung von privatem DNS. Nicht behandelt werden unabhängige Consumer- und Hosting-Anwendungen:

• Die Einstellung für privates DNS bzw. DNS-over-TLS von Android auf einem Telefon konfigurieren.
• Private Nameserver in cPanel für eine Hosting-Marke einrichten.
• Eine vollständige Installationsanleitung für BIND 9, Unbound, dnsmasq oder CoreDNS. Die Umsetzung bleibt hier auf Referenzniveau, nicht auf Schritt-für-Schritt-Konfiguration.
• Verschlüsselte Consumer-Resolver wie 1.1.1.1 oder NextDNS, über die Abgrenzung zur Netzwerkbedeutung hinaus.

Was bedeutet „privates DNS“ eigentlich?

„Privates DNS“ ist nicht ein System. Der Begriff bezeichnet mindestens drei nicht verwandte: eine netzwerkbeschränkte DNS-Zone, die interne Hostnamen innerhalb eines VPS- oder VPC-Netzwerks auflöst, die DNS-over-TLS-Verschlüsselungsfunktion von Android und die individuell gebrandeten autoritativen Nameserver von cPanel. Dieser Artikel behandelt das erste, die interne Zone, die Ihre Server abfragen, um einander zu finden. Es gibt auch eine vierte, lockere Verwendung: verschlüsselte öffentliche Resolver, die als „privat“ vermarktet werden.

Die vier Bedeutungen teilen sich einen Namen und sonst nichts:

Die Ankündigung der allgemeinen Verfügbarkeit von Internal DNS bei Cloudflare ist ein aktuelles Managed-Beispiel für die erste Bedeutung und einer der Gründe, warum die Verwechslung neu sichtbar wird: Ein Infrastrukturanbieter verwendet „privates DNS“ nun als Synonym für internes DNS in seinem Launch-Text. Das beschriebene System, ein Gateway Resolver plus Internal Authoritative DNS für Enterprise-Kunden, gehört zur selben Kategorie wie das, was Sie auf einer VPS-Flotte selbst bauen, nur eben managed.

Fazit des Abschnitts: Die wichtigsten Systeme namens „privates DNS“ teilen sich ein Etikett, keine Funktion. Klären Sie die Bedeutung, bevor Sie einer Anleitung folgen.

Wie funktioniert privates DNS in einem VPS-Netzwerk?

Eine private DNS-Zone eines VPS ist ein netzwerkbezogener Namensraum, der von einem Resolver bereitgestellt wird, den Ihre Server nutzen sollen. Sie ordnet interne Hostnamen wie db.internal.example.com privaten IPs aus einem Bereich zu, den Sie kontrollieren. Die Einträge werden nicht im öffentlichen DNS veröffentlicht, auch wenn die Abfragen über einen privaten Tunnel oder eine verwaltete DNS-Control-Plane laufen können, bevor sie den Resolver erreichen. Diese Trennung ist der Kern des Unterschieds zwischen privatem und öffentlichem DNS: Das Protokoll ist dasselbe, aber Sichtbarkeit und Zugriffsbereich der Zone unterscheiden sich.

Drei Teile erledigen die Arbeit. Ein autoritativer Server oder eine Zonenquelle hält die interne Zone und ihre Einträge. Ein Resolver beantwortet die Abfragen, die Ihre Server senden. Und die A- und AAAA-Einträge der Zone ordnen interne Hostnamen privaten Adressen zu, sodass app.internal.example.com auf die Anwendungsschicht auflöst und db.internal.example.com auf die Datenbank auflöst. Andere Record-Typen können Aliase oder Dienstinformationen liefern. Sind Zone und Resolver-Pfad korrekt konfiguriert, beantwortet der Resolver die interne Abfrage lokal, statt sie an die öffentliche DNS-Root zu schicken.

Die Cloud-Plattformen binden das an das Netzwerk statt an die Maschine, was ein nützliches Referenzmodell ist. Private Hosted Zones von AWS Route 53 funktionieren nur, wenn beim VPC sowohl enableDnsHostnames als auch enableDnsSupport auf true stehen, und der Resolver antwortet aus der privaten Zone für jedes VPC, das Sie damit verknüpfen. Private Zonen von Google Cloud sind auf autorisierte VPC-Netzwerke beschränkt, und in der Standard-Auflösungsreihenfolge eines VPC werden sie vor dem öffentlichen DNS geprüft, sofern nicht eine Outbound-Server-Policy den Weg ändert. Lesen Sie das als Veranschaulichung des Musters, nicht als Plattform-Tutorial: Ein selbst verwalteter interner DNS-Server folgt derselben Idee, nur auf Ihrem eigenen VPS.

Die Zone aus dem öffentlichen DNS herauszuhalten ist nur die halbe Arbeit. Binden Sie den DNS-Dienst an eine private Schnittstelle oder beschränken Sie UDP- und TCP-Port 53 auf Ihr privates Netzwerk oder VPN. Setzen Sie den rekursiven Dienst nicht dem öffentlichen Internet aus; ein offener Resolver kann für DNS-Amplification-Angriffe missbraucht werden.

Private und öffentliche Zonen verwenden dasselbe Modell für DNS-Einträge und Caching. Einträge tragen eine TTL, und cachende Resolver verwenden eine Antwort normalerweise wieder, bis diese TTL abläuft, auch wenn resolver-spezifische Einstellungen die effektive Cache-Zeit ändern können. Dieses Verhalten behandelt unser Leitfaden zum Verweisen einer Domain auf einen VPS, einschließlich die Grundlagen von DNS-Propagierung und TTL, daher wird das hier nicht noch einmal erklärt.

Wann braucht Ihr VPS-Netzwerk wirklich privates DNS?

Für zwei oder drei statische Server ist /etc/hosts wirklich ausreichend. Ein interner DNS-Server rechnet sich, wenn die Flotte wächst, IPs sich regelmäßig ändern oder Anwendungen eine verlässliche Service-Discovery brauchen. Der eigentliche Auslöser ist die betriebliche Komplexität, nicht eine feste Serverzahl.

/etc/hosts ist eine statische Zuordnung von Hostnamen zu IPs, die auf jeder Linux-Maschine bereits existiert. Sie braucht weder Daemon noch Zonendatei, aber veraltete oder inkonsistente Kopien sind echte Fehlerquellen. Tragen Sie die private IP jedes Servers in die Datei ein, halten Sie die Kopien synchron, und die Maschinen finden einander über den Namen. Für eine kleine, stabile Flotte ist das die richtige Antwort, und stattdessen zu BIND 9 zu greifen fügt nur einen zu pflegenden Daemon ohne Gewinn hinzu.

In drei Situationen stößt das an seine Grenzen. Wenn Sie häufig Server hinzufügen und entfernen, wird es zur manuellen Plackerei, eine statische Datei auf jedem Host konsistent zu halten. Wenn IPs sich ändern, durch Autoscaling, Neuaufbauten oder Neuzuweisungen des Anbieters, veraltet die Datei stillschweigend. Und wenn Container oder isolierte Laufzeiten die Einträge des Hosts nicht erben, ist die Zuordnung nicht mehr universell. Jede einzelne davon ist der eigentliche Auslöser. Die Serverzahl allein ist ein grober Näherungswert, nicht das eigentliche Signal.

Fazit des Abschnitts: Der Auslöser ist die betriebliche Fluktuation, nicht die Serverzahl. Eine eingefrorene Flotte aus zehn Maschinen kann gut mit /etc/hostsauskommen; eine Flotte aus drei Maschinen, die nächtlich neu gebaut wird, sollte das eher nicht.

Entwickeln Sie auf einem Linux-VPS mit Root-Zugriff, NVMe und AMD-EPYC-Power.

Linux-Pläne ansehen

Welchen DNS-Server sollten Sie betreiben: BIND 9, Unbound, dnsmasq oder CoreDNS?

Wählen Sie nach der Form Ihrer Flotte. dnsmasq passt zu kleinen Netzwerken, die schlankes DNS und, wo relevant, DHCP aus demselben Daemon wollen. Unbound ist ein schlanker validierender rekursiver Resolver, der auch eine bescheidene lokale Zone beantworten kann. BIND 9 bietet breite autoritative und rekursive Fähigkeiten mit der größten Konfigurationsfläche. CoreDNS passt zu Container- und Kubernetes-Flotten, in denen DNS Teil der Service-Discovery ist.

Die Auswahllogik ist kurz. Wenn Sie einen kleinen Resolver auf Basis einer hosts-artigen Datei brauchen oder ohnehin DHCP-Leases vergeben, nimmt dnsmasq ein bewegliches Teil aus dem System. Wenn Sie vor allem einen validierenden Resolver brauchen, der nach außen weiterleitet und eine bescheidene interne Zone beantwortet, liefert Unbound genau diesen engeren Funktionsumfang ohne ein vollständiges BIND-9-Deployment. Wenn Sie volle autoritative Kontrolle, Delegierung und den größten Fundus an Dokumentation brauchen, auf den Sie sich um 3 Uhr nachts stützen können, bleibt BIND 9 trotz der breiteren Konfigurationsfläche die konservative Wahl. Wenn DNS bereits Teil eines Container- oder Kubernetes-Service-Discovery-Stacks ist, fügt sich CoreDNS dort ein. Die Faustregel: Betreiben Sie das Kleinste, das die Form Ihrer Flotte abdeckt.

Machen Sie in einer Produktionsflotte nicht eine einzige DNS-Instanz zum einzigen Weg zu jedem internen Namen. Betreiben Sie mindestens zwei DNS-Instanzen die die Zone beantworten können, platzieren Sie sie nach Möglichkeit in getrennten Fehlerdomänen und konfigurieren Sie die Clients so, dass sie beide erreichen. Sonst kann ein einziger DNS-Ausfall gesunde Dienste tot aussehen lassen.

Wie sollten Sie Ihre interne Domain benennen: .internal, .local oder eine Subdomain?

Verwenden Sie für die meisten produktiven VPS-Netzwerke eine Subdomain, die Ihnen gehört, etwa internal.example.com. Nutzen Sie den Namensraum .internal nur für ein isoliertes Setup, in dem Namenskollisionen zwischen Netzwerken, die Zertifikatsverwaltung über eine private CA und eine spezielle DNSSEC-Behandlung akzeptabel sind. Vermeiden Sie .local, das mDNS reserviert.

Das Problem mit .local ist konkret. RFC 6762 gibt Namen, die auf .local enden, eine Sonderbehandlung für Multicast DNS, sodass eine Unicast-Zone in BIND 9 oder Unbound mit demselben Suffix mit dem mDNS-Verhalten auf Apple-Geräten und anderen mDNS-fähigen Systemen kollidieren kann. Nutzen Sie einen anderen Namensraum, statt sich auf clientspezifische Behelfslösungen zu verlassen.

Profi-Tipp: Wenn Sie eine interne .local-Zone geerbt haben, behandeln Sie sie als technische Schuld. Manche Clients senden .local-Abfragen an mDNS statt an Ihren Unicast-DNS-Server, was zu clientabhängigen oder scheinbar sporadischen Fehlern führen kann.

Der Vorstand der ICANN hat .internal dauerhaft reserviert im Juli 2024 von der Delegierung in der öffentlichen DNS-Root ausgenommen, nach einer früheren SSAC-Empfehlung. Namen darunter werden per Design nicht über das globale DNS auflösen. Damit gehen Kompromisse einher: .internal-Namen sind nicht global eindeutig, von öffentlichen Zertifizierungsstellen wird nicht erwartet, dass sie dafür Zertifikate ausstellen, und DNSSEC-validierende Resolver, die sich auf den globalen Trust Anchor stützen, werden sie nicht auflösen. Wenn Sie HTTPS auf .internal brauchen, planen Sie den Betrieb einer privaten CA ein.

Halten Sie hier zwei Dinge auseinander. Die Reservierung der ICANN ist endgültig. Davon getrennt wurde ein aktiver Internet-Draft, draft-davies-internal-tld-06am 6. Mai 2026 veröffentlicht, um den Namensraum zu dokumentieren und ihn mit der privaten Adressierung nach RFC 1918 zu vergleichen. Er bleibt ein Internet-Draft in Arbeit und keine veröffentlichte RFC. Beschreiben Sie .internal also als von der ICANN reservierte TLD zur privaten Nutzung, nicht als IETF-Standard.

Für die meisten VPS-Flotten ist eine Subdomain einer Domain, die Sie kontrollieren, die sicherere Standardwahl. Die ISC empfiehlt eine Subdomain-Hierarchie, etwa eine interne Subdomain Ihrer eigenen Domain, statt getrennte und unvollständige interne und öffentliche Fassungen derselben übergeordneten Zone zu pflegen. Diese Präferenz ist keine Stilfrage: Sie verhindert den Fehler aus dem nächsten Abschnitt.

Fazit des Abschnitts: Die Entscheidung über den Namensraum ist langlebig. Eine Subdomain, die Sie kontrollieren, ist der Standard für die meisten Produktionsumgebungen, weil sie globale Eindeutigkeit bewahrt und mit öffentlicher PKI funktioniert. Nutzen Sie .internal, wenn ein isolierter privater Namensraum besser passt und Sie dessen Kompromisse bei DNSSEC, Zertifikaten und Kollisionen akzeptieren.

Split-Horizon-DNS und die Fehler, die es kaputt machen

Split-Horizon-DNS liefert für denselben Hostnamen je nach Fragesteller eine andere Antwort: intern die private IP, extern die öffentliche. Am häufigsten scheitert es an der NXDOMAIN Falle innerhalb derselben Domain, an alternativen Resolvern, welche die vorgesehene Sicht umgehen, und an DNS-Pfaden in Containern, die den erwarteten Upstream nicht erreichen. Es richtig hinzubekommen hängt gleichzeitig von drei Dingen ab, nicht von einem.

Die NXDOMAIN-Falle ist genau der Fehler, vor dem die ISC direkt warnt. Wenn Ihre internen Server für die übergeordnete Domain autoritativ sind, ihre Version der Zone aber einen öffentlichen Eintrag wie den www-Host nicht enthält, erhält ein interner Client bei der Abfrage dieses Namens NXDOMAIN, obwohl die öffentliche Zone ihn führt. Die interne Zone ist autoritativ und weicht für die übergeordnete Domain nicht auf das öffentliche DNS aus. Genau deshalb ist der Ansatz der Subdomain-Hierarchie aus dem Abschnitt zur Benennung das von der ISC bevorzugte Design.

Profi-Tipp: Bevor Sie Ihre Server auf ein Split-Horizon-Setup innerhalb derselben Domain richten, testen Sie aus dem Netzwerk heraus die Auflösung eines bekannten öffentlichen Namens dieser Domain. Eine NXDOMAIN-Antwort für einen Namen, der extern problemlos auflöst, ist die Signatur dieser Falle.

Drei weitere Fallstricke werden leicht übersehen. Ein auf einem Host oder Container konfigurierter alternativer Resolver kann die Trennung umgehen; je nach Resolver-Implementierung wird er nach einem Timeout oder parallel abgefragt, sodass die Antworten variieren können. Container auf Dockers Standard-Bridge erhalten beim Start eine Kopie der DNS-Konfiguration des Hosts, während Container in benutzerdefinierten Netzwerken Dockers eingebauten Resolver unter 127.0.0.11. Dieser Resolver leitet externe Abfragen an die für Host oder Container konfigurierten DNS-Server weiter, sodass das Split-DNS-Verhalten von der Docker- und Host-Konfiguration abhängt und nicht allein von der Resolver-Datei des Containers. Wenn ein interner Dienst hinter einem Reverse Proxy wie Nginx Proxy Managersitzt, kann die Zertifikatsprüfung fehlschlagen, wenn das Zertifikat den angefragten Hostnamen nicht abdeckt oder die ausstellende CA vom Client nicht als vertrauenswürdig eingestuft wird. Intern schlicht ein anderes Zertifikat zu verwenden ist für sich genommen kein Fehler. Das sind Konfigurationslücken, keine Fehler der Werkzeuge.

Entfernte Clients können auf denselben Fehler stoßen, wenn ein selbst gehostetes VPN die DNS-Abfragen nicht an den vorgesehenen internen Resolver überträgt oder routet.

Es gibt auch eine Sicherheitsdimension. Wenn interne Hostnamen und private IPs in öffentliche DNS-Einträge sickern, haben Sie einen Teil Ihres internen Namens- und Adressschemas jedem offengelegt, der es abfragt. Split-Horizon existiert unter anderem, um diese Karte intern zu halten, und eine falsch konfigurierte öffentliche Zone macht das stillschweigend zunichte.

Fazit des Abschnitts: Die Fehler von Split-Horizon sind Konfigurationsfallen, keine Mängel der Werkzeuge. Korrektheit hängt von Namensdisziplin ab, davon zu wissen, welchen Resolver jeder Client tatsächlich abfragt, und von einem sauberen Zonenumfang, nicht von einer einzelnen Einstellung.

LESEN

So verknüpfst du eine Domain mit VPS: Eine Kurzanleitung

Fazit: das richtige Design für privates DNS wählen

Sie können jetzt erkennen, welches „private DNS“-System Sie tatsächlich meinen. Im VPS-Netzwerk ist es die interne DNS-Zone und nicht Androids DNS-over-TLS-Einstellung oder gebrandete autoritative Nameserver. Wenn Ihre Flotte klein und stabil ist, ist /etc/hosts eine vertretbare Wahl. Wenn nicht, nehmen Sie eine Subdomain, die Ihnen gehört, als Standard-Namensraum, wählen Sie den kleinsten DNS-Server, der zur Flotte passt, und halten Sie Zugriff, Redundanz und den internen gegenüber dem öffentlichen Zonenumfang explizit. Nutzen Sie .internal nur, wenn ein isolierter Namensraum besser passt und Sie dessen Kompromisse bei Zertifikaten, DNSSEC und Kollisionen akzeptieren.

Häufig gestellte Fragen