Autoritative DNS-Zonen zwischen intern und extern trennen

TL;DR

Ein belastbares DNS-Namenskonzept trennt interne Auflösung von öffentlich autoritativen Edge-Diensten. Internal und External DNS Zones haben unterschiedliche Sichtbarkeiten, Auflösungswege und Sicherheitsgrenzen. Statt Zonen nachträglich zu synchronisieren, sollten Unternehmen Namensräume, Verantwortlichkeiten und Datenflüsse frühzeitig getrennt definieren.

Einleitung

Der häufigste Fehler bei der DNS-Architektur ist nicht ein falscher Record, sondern ein unklarer Verantwortungsbereich. Wenn interne Service-Namen, administrative Endpunkte und öffentliche Anwendungen in derselben autoritativen Zone liegen, wird jede Änderung zur Sicherheits- und Betriebsfrage. Ein interner Name kann versehentlich öffentlich sichtbar werden; ein öffentlicher Record kann von internen Resolvern über einen unerwarteten Weg beantwortet werden. Die zentrale Architekturentscheidung lautet deshalb: Welche Zone ist intern maßgeblich, welche Zone wird für öffentliche Edge-Dienste autoritativ bereitgestellt – und wo verlaufen die DNS-Sicherheitsgrenzen?

1. Namensräume nach Sichtbarkeit statt nach Organisation schneiden

Internal DNS Zones und External DNS Zones sollten nicht lediglich unterschiedliche Ansichten derselben Datenbank sein. Sie erfüllen unterschiedliche Aufgaben. Eine interne Zone enthält beispielsweise Namen für Cluster-Endpunkte, private Backends, Verwaltungsdienste oder Service Discovery. Diese Informationen benötigen interne Resolver und sollen nicht Teil der öffentlichen DNS-Antworten sein.

External Zones enthalten dagegen Namen, die aus dem Internet auflösbar sein müssen. Dazu gehören etwa öffentliche Webanwendungen, APIs oder Mail- und Verifikations-Records. Für diese Namen ist ein öffentlich autoritativer Dienst zuständig, der Anfragen unabhängig von internen Resolvern beantworten kann.

Ein sauberes DNS-Namenskonzept trennt daher nicht nur Records, sondern möglichst auch Domänen oder Subdomänen. api.example.com kann öffentlich auf die Edge zeigen, während api.internal.example.com ausschließlich intern auflösbar ist. Die Namensgebung transportiert damit eine technische Eigenschaft: Sichtbarkeit und Zuständigkeit.

2. Auflösungswege als Sicherheitsgrenze definieren

Split-Horizon-DNS wird problematisch, wenn es nur als Komfortfunktion für unterschiedliche Antworten verstanden wird. Entscheidend ist der Auflösungsweg. Interne Resolver sollten interne Zonen direkt oder über klar definierte Weiterleitungen erreichen. Öffentliche Resolver dürfen dagegen ausschließlich die External Zones sehen, die für Internetdienste bestimmt sind.

Diese Trennung reduziert das Risiko, dass interne Zieladressen, Hostnamen oder Infrastrukturinformationen nach außen gelangen. Sie verhindert zugleich, dass interne Clients für öffentliche Namen einen unnötigen Umweg über interne Spezialregeln nehmen. Ein öffentlicher Dienst sollte aus internen Netzen entweder über den vorgesehenen öffentlichen Namen und die Edge erreichbar sein oder über einen ausdrücklich definierten internen Namen. Beides ungeplant zu vermischen, erschwert Fehlersuche und Sicherheitsbewertung.

Für die ayedo Edge Cloud ist diese Unterscheidung relevant, weil Anycast DNS und Multi-Provider-DNS den öffentlichen autoritativen Pfad bilden können. Die External Zone stellt dabei die Namen für öffentliche Edge-Dienste bereit. Interne Zonen bleiben in der eigenen DNS-Verantwortung und werden nicht automatisch Bestandteil dieses öffentlichen Namensraums.

3. Autoritative Daten bewusst zuordnen

Die Frage „Welche Zone enthält den Record?“ sollte durch eine Zuständigkeitsentscheidung beantwortet werden, nicht durch technische Bequemlichkeit. Records für öffentliche Services gehören in die External Zone, wenn ihre Auflösung zur Erreichbarkeit über die Edge erforderlich ist. Dazu zählen beispielsweise Namen, die auf öffentliche Anycast-Endpunkte zeigen oder für TLS- und Domainvalidierung benötigt werden.

Interne Backend-Namen, private Adressen und clusterinterne Service-Namen gehören dagegen in Internal Zones. Sie werden nicht veröffentlicht, nur weil ein öffentlicher Dienst technisch auf sie zugreift. Die Edge Cloud benötigt für die externe Erreichbarkeit nicht zwangsläufig die interne Namensstruktur. Backend Cloaking unterstützt genau diese Entkopplung: Der öffentliche DNS-Name verweist auf die Edge, während die eigentliche Backend-Topologie verborgen bleibt.

Wichtig ist außerdem, Änderungen nicht über eine nachträgliche Synchronisierung beider Zonen zu organisieren. Synchronisierung kann divergierende Zustände, unklare Löschverantwortung und unbeabsichtigte Veröffentlichungen erzeugen. Besser ist eine eindeutige Quelle pro Record-Kategorie und ein klarer Übergang zwischen öffentlichem Frontend und internem Backend.

4. Betrieb und Governance an der Zonengrenze

Die Trennung der Zonen wirkt sich direkt auf den Betrieb aus. Für External Zones müssen TTLs, Failover-Verhalten, DNSSEC- oder Providerkonzepte und Änderungen an öffentlichen Services berücksichtigt werden. Interne Zonen folgen dagegen den Anforderungen von Plattformbetrieb, Service Discovery und privaten Netzwerken. Beide Bereiche haben unterschiedliche Änderungsfrequenzen und unterschiedliche Ausfallfolgen.

Auch Berechtigungen sollten an der Zonengrenze ausgerichtet werden. Ein Team, das einen öffentlichen API-Endpunkt betreibt, benötigt nicht automatisch Zugriff auf interne Infrastrukturzonen. Umgekehrt sollte ein Plattformteam interne Namen verwalten können, ohne öffentliche DNS-Änderungen direkt auszuführen. Diese Trennung verbessert Nachvollziehbarkeit und reduziert den Einfluss fehlerhafter Automatisierung.

Bei mehreren DNS-Anbietern oder einer Edge-Plattform wie ayedo müssen außerdem die autoritativen Zuständigkeiten explizit dokumentiert sein. Multi-Provider-DNS kann die Verfügbarkeit des öffentlichen Pfads erhöhen; es ersetzt aber kein Namenskonzept. Die technische Redundanz ist nur dann belastbar, wenn alle beteiligten autoritativen Systeme dieselbe klar abgegrenzte External Zone bedienen.

Praxisszenario: Öffentliche API mit privatem Backend

Ein Unternehmen betreibt eine API in einem Kubernetes-Cluster bei einem externen Provider. Intern existieren Namen wie orders-api.cluster.internal.example.com und mehrere private Backend-Adressen. Öffentlich soll ausschließlich api.example.com sichtbar sein.

In der External Zone zeigt api.example.com auf die ayedo Edge Cloud. Dort können TLS Termination, WAF, DDoS Protection und Loadbalancing erfolgen. Die Backend-Adresse und interne Namensstruktur werden nicht veröffentlicht. Interne Clients verwenden entweder ebenfalls den öffentlichen Namen über den vorgesehenen Edge-Pfad oder einen separaten internen Namen – abhängig von Routing- und Sicherheitsanforderungen. Entscheidend ist, dass beide Pfade bewusst modelliert werden. Ein automatisch synchronisierter Recordbestand wäre hier keine Vereinfachung, sondern eine zusätzliche Fehlerquelle.

FAQ

Ist Split-Horizon-DNS immer erforderlich?

Nein. Separate Domänen oder Subdomänen sind oft einfacher. Split-Horizon-DNS ist sinnvoll, wenn derselbe Name abhängig vom Anfragekontext unterschiedliche Antworten benötigt.

Gehören Backend-Records in die External Zone?

Nein. Öffentlich erforderlich ist der Frontend-Name. Backend-Namen und private Adressen sollten in Internal Zones verbleiben und nicht aus der öffentlichen Zone ableitbar sein.

Kann die Edge Cloud interne DNS-Zonen ersetzen?

Nein. Die Edge Cloud stellt den öffentlichen DNS- und Traffic-Pfad bereit. Interne Namensauflösung, Service Discovery und private Zonen bleiben eine separate Architekturverantwortung.

Fazit

Internal und External DNS Zones sind keine bloßen Kopien mit unterschiedlichen Antworten, sondern getrennte Verantwortungsbereiche. Ein bewusstes DNS-Namenskonzept definiert Sichtbarkeit, Auflösungswege und Zuständigkeiten bereits vor dem Betrieb. Die ayedo Edge Cloud kann dabei den autoritativen öffentlichen Pfad für Edge-Dienste bilden, während interne Zonen und Backend-Namen abgeschirmt bleiben. So entstehen klarere Sicherheitsgrenzen, weniger Synchronisationsrisiken und besser kontrollierbare Betriebsprozesse.