DNS, TLS und WAF: Zusammenspiel am öffentlichen Eingang

TL;DR

DNS, TLS und WAF erfüllen am öffentlichen Eingang unterschiedliche Aufgaben, wirken aber als gemeinsame Verarbeitungskette. Anycast DNS und Multi-Provider-DNS führen Anfragen zur Edge, TLS-Termination macht verschlüsselten Traffic prüfbar, und die Web Application Firewall bewertet HTTP-/HTTPS-Anfragen. Entscheidend ist nicht die Einzelfunktion, sondern ihr Zusammenspiel.

Einleitung

Ein häufiger Architekturfehler besteht darin, DNS, TLS und WAF als separat buchbare Dienste zu betrachten. Dann wird DNS lediglich als Verweis auf einen Endpoint konfiguriert, TLS an irgendeiner Stelle beendet und die WAF nachträglich vor ein Backend gesetzt. Das erschwert Fehleranalyse, Failover und Sicherheitsbewertung. Technisch handelt es sich um eine Verarbeitungskette: DNS bestimmt den Einstiegspunkt, TLS authentifiziert und verschlüsselt die Verbindung, und die WAF analysiert den entschlüsselten HTTP-/HTTPS-Verkehr. Eine Edge-Plattform muss diese Übergänge kontrolliert abbilden, bevor Anfragen die eigentlichen Backends erreichen.

1. DNS bestimmt, wo die Verarbeitung beginnt

DNS entscheidet nicht über die fachliche Zulässigkeit einer Anfrage, sondern darüber, welcher öffentliche Eingang erreicht wird. Bei Anycast DNS kann derselbe Dienst über mehrere Netzwerkstandorte angekündigt werden. Routing auf Netzwerkebene führt die Anfrage typischerweise zu einer geeigneten erreichbaren Instanz. Dadurch wird DNS Teil der Erreichbarkeitsarchitektur und nicht nur ein Verzeichnisdienst.

Multi-Provider-DNS ergänzt diesen Ansatz um eine organisatorische und technische Entkopplung von einem einzelnen DNS-Anbieter. Unterschiedliche autoritative Provider können die Namensauflösung redundant bereitstellen. Das reduziert die Abhängigkeit von einer einzelnen DNS-Infrastruktur, ersetzt aber keine saubere Zustands- und Änderungsstrategie: TTLs, Health Checks, Delegation und Failover müssen zusammenpassen.

Im Kontext der ayedo Edge Cloud bildet Anycast DNS den Namenseinstieg in eine verteilte Edge-Infrastruktur. Multi-Provider-DNS kann dabei die DNS-Ebene zusätzlich providerübergreifend absichern. Die Edge selbst basiert auf eigener Netzwerk-Infrastruktur, eigenem Autonomous System und einem Aktiv-Aktiv-Prinzip. DNS ist damit der erste Teil einer Kette, deren nachgelagerte Schutz- und Routingfunktionen an der Edge ausgeführt werden.

2. TLS-Termination schafft den prüfbaren Verkehrskontext

HTTPS schützt die Verbindung zwischen Client und dem Punkt, an dem TLS beendet wird. Solange der Datenstrom verschlüsselt ist, kann eine nachgelagerte HTTP-Sicherheitskomponente Inhalte, Header und Request-Struktur nicht bewerten. TLS-Termination an der Edge schafft deshalb den technischen Übergang von verschlüsseltem Transport zu prüfbarem Anwendungstraffic.

Dieser Übergang ist sicherheitsrelevant. Zertifikate, unterstützte Protokolle und die Zuordnung von Hostnamen müssen an der öffentlichen Eingangsschicht konsistent verwaltet werden. Ebenso muss klar sein, welche Verbindung geschützt wird: zwischen Client und Edge, zwischen Edge und Backend oder in beiden Abschnitten. Eine TLS-Terminierung an der Edge bedeutet nicht automatisch, dass der gesamte interne Transport unverschlüsselt erfolgt.

Für die WAF ist die TLS-Terminierung eine Voraussetzung, um HTTPS-Anfragen auf Anwendungsebene zu analysieren. Die ayedo Edge Cloud kann TLS an der Edge terminieren und den anschließend verarbeitbaren Traffic an die vorgesehenen Backends weiterleiten. Backend Cloaking unterstützt dabei die Trennung zwischen öffentlichem Einstiegspunkt und tatsächlich betriebenen Ursprungsdiensten: Clients adressieren die Edge, nicht unmittelbar die Backend-Infrastruktur.

3. Die WAF arbeitet nach der Entschlüsselung

Eine Web Application Firewall schützt HTTP-/HTTPS-Services auf Anwendungsebene. Sie bewertet beispielsweise Request-Strukturen, Pfade, Parameter und Header gegen definierte Sicherheitsregeln. Damit unterscheidet sie sich von DDoS-Schutz oder reinem Layer-4-Loadbalancing: Die WAF benötigt einen interpretierbaren HTTP-Kontext und kann nicht allein anhand von IP-Adresse und Port entscheiden.

Die Verarbeitungskette ist deshalb entscheidend. DNS führt zur Edge, TLS authentifiziert den vorgesehenen Dienst und entschlüsselt die Verbindung, danach kann die WAF die Anfrage prüfen. Erst wenn diese Prüfung erfolgreich ist, wird der Traffic per Routing und Loadbalancing an ein Backend übergeben. Wird eine Anfrage abgewiesen, erreicht sie die Anwendung nicht.

Diese Reihenfolge beeinflusst auch den Betrieb. Eine fehlerhafte DNS-Konfiguration erzeugt Erreichbarkeitsprobleme, ein Zertifikatsfehler verhindert den TLS-Aufbau, und eine zu restriktive WAF-Regel kann gültige Requests blockieren. Die Fehlerbilder liegen an unterschiedlichen Stellen, obwohl Nutzer jeweils nur einen nicht erreichbaren Dienst wahrnehmen. Traffic- und Usage-Statistiken sowie Backend Health Checks helfen, diese Ebenen voneinander zu trennen. Die WAF ist damit kein isoliertes Add-on, sondern ein Bestandteil des öffentlichen Datenpfads.

4. Gemeinsame Steuerung reduziert betriebliche Brüche

Die größte Wirkung entsteht, wenn DNS, TLS, WAF und Backend-Routing als ein gemeinsamer Service-Einstieg betrieben werden. Ein neuer Hostname benötigt dann nicht nur einen DNS-Eintrag, sondern auch eine passende TLS-Zuordnung, WAF-Regeln und ein gesundes Backend. Änderungen an einer Ebene müssen auf die anderen Ebenen abgestimmt werden.

Das betrifft insbesondere Failover. DNS kann nur den Einstieg beeinflussen; ob ein Ziel tatsächlich Anfragen verarbeitet, hängt zusätzlich von Edge-Verfügbarkeit, WAF-Zustand und Backend Health Checks ab. Ein DNS-Failover ohne korrespondierende Anwendungs- und Sicherheitskonfiguration kann zwar die Auflösung ändern, aber keinen funktionsfähigen Service herstellen. Umgekehrt ist ein gesundes Backend wertlos, wenn TLS oder DNS den Zugriff verhindern.

Bei der ayedo Edge Cloud werden diese Funktionen innerhalb einer verteilten Edge-Plattform verbunden: Anycast DNS, Multi-Provider-DNS, TLS-Termination, WAF, DDoS Protection, Routing und Health-basierte Weiterleitung bilden eine zusammenhängende Eingangsschicht. Das ist auch unabhängig vom verwendeten Compute-Provider relevant. Kubernetes-Workloads können über die Edge angebunden werden, egal ob sie in ayedo Managed Kubernetes, einem eigenen Cluster oder bei einem anderen Provider laufen.

Betriebsszenario: Ein HTTPS-Service mit Failover

Ein Unternehmen betreibt eine API unter api.example.de in zwei Kubernetes-Clustern bei unterschiedlichen Providern. Der DNS-Name verweist über Anycast DNS auf die Edge. Zusätzlich ist die Zone bei mehreren DNS-Providern delegiert. Die TLS-Verbindung wird an der Edge terminiert, bevor die WAF Requests anhand von Host, Pfad und Parametern prüft. Nur zulässiger Traffic wird an ein Backend weitergeleitet.

Fällt ein Cluster aus, erkennen Health Checks das fehlerhafte Ziel und die Edge leitet Anfragen an das verbleibende Backend. DNS muss dafür nicht bei jeder Störung geändert werden. Die öffentliche Adresse, das Zertifikatsmodell und die WAF-Regeln bleiben an der Eingangsschicht stabil. Das reduziert die Zahl synchron zu ändernder Komponenten und hält die Backend-Adressen verborgen.

FAQ

Ist eine WAF ohne TLS-Termination nutzlos?

Nicht grundsätzlich. Sie kann unverschlüsselten HTTP-Traffic prüfen. Für HTTPS muss der Datenstrom jedoch an einem vertrauenswürdigen Punkt terminiert oder anderweitig entschlüsselt werden, damit Anwendungsebene und Request-Inhalt analysierbar sind.

Ersetzt Multi-Provider-DNS die Edge-Redundanz?

Nein. Multi-Provider-DNS reduziert die Abhängigkeit von einzelnen DNS-Anbietern. Die Verfügbarkeit der Edge, TLS-Verarbeitung, WAF und Backends müssen zusätzlich redundant und unabhängig betrachtet werden.

Funktioniert die Kette nur mit ayedo Managed Kubernetes?

Nein. Die Edge Cloud kann auch eigene oder bei anderen Providern betriebene Kubernetes-Cluster anbinden. DNS, TLS und WAF bleiben dabei Funktionen des öffentlichen Eingangs, nicht des verwendeten Compute-Clusters.

Fazit

DNS, TLS und WAF sollten nicht als drei unabhängige Sicherheits- oder Netzwerkdienste modelliert werden. Sie bilden eine Verarbeitungskette mit klaren Übergängen: Namensauflösung führt zur Edge, TLS macht den Dienstkontext vertrauenswürdig und prüfbar, die WAF bewertet den HTTP-/HTTPS-Traffic, bevor Backends erreicht werden. Die ayedo Edge Cloud ordnet diese Funktionen in einer providerunabhängigen, verteilten Eingangsschicht ein. Entscheidend ist damit weniger die einzelne Funktion als die Konsistenz des gesamten öffentlichen Datenpfads.