Funktion

DNS-Firewall & Load Balancer

Beschleunigen Sie Unternehmens-DNS-Verkehr und blockieren Sie bösartige Anfragen — in einer einzigen Schicht.

DNS ist der Ausgangspunkt jeder modernen Anwendung. Jede Session, jeder API-Aufruf und jede Remote-Verbindung beginnt mit einer DNS-Anfrage — und doch ist die DNS-Schicht in den meisten Unternehmen immer noch ein einzelner Server, nicht überwacht und direkt der Außenwelt ausgesetzt. TR7 DNS-Firewall und Load Balancer schließt diese Lücke entlang beider Achsen, Performance und Sicherheit: DNS-Anfragen werden mit intelligenten Algorithmen über mehrere Backend-Resolver verteilt; unhealthy Server werden durch aktive Health Checks innerhalb von Sekunden aus der Rotation genommen; häufig angefragte Records werden nahe am Client zwischengespeichert; moderne DoT-/DoH-/DoQ-Transports werden am Gateway terminiert. Dieselbe Schicht setzt DNS-Firewall-Regeln durch — sie blockiert bösartige Anfragen, erkennt Muster von Domain Generation Algorithms (DGA), mildert DNS-Exfiltration und Amplification-Angriffe und wendet geografische, IP- und ratenbasierte Richtlinien aus einer einzigen Regel-Engine an. In der TR7-Plattformarchitektur trägt diese Schicht gleichzeitig zwei Identitäten: Sie erweitert die Load-Balancing-Philosophie des TR7 ADC in das DNS-Protokoll und dehnt den Security-Policy-Ansatz des TR7 WAAP in den DNS-Flow.

5
Auf DNS-Workloads abgestimmte Load-Balancing-Algorithmen
3
Terminierte moderne DNS-Transports — DoT, DoH, DoQ
11+
Firewall-Aktionstypen — Block, Drop, Refuse, Spoof, Route, Tag und mehr

DNS ist die am häufigsten übersehene Sicherheits- und Performance-Schicht im Unternehmen.

Die meisten Organisationen investieren Jahre in die Feinabstimmung ihrer HTTP-Load-Balancing-Strategie und bauen tiefen WAAP-Schutz für Web-Traffic auf — und behandeln ihre DNS-Infrastruktur trotzdem als einzelnen rekursiven Server mit statischer IP. Dieser einzelne Server wird gleichzeitig zum Performance-Engpass und zum hochwertigen Angriffsziel.

Auf der Performance-Seite drückt eine langsame DNS-Schicht Latenz in jede benutzerseitige Transaktion. Ohne sauberes Load Balancing verzögert ein gesättigter Resolver jeden nachgelagerten Lookup — und klassische Anycast-basierte DNS-Cluster sind in privaten Rechenzentren, in denen On-Prem-Kontrolle gefordert ist, schwer zu verwalten.

Auf der Sicherheitsseite wissen Angreifer, dass DNS selten inspiziert wird. DNS-Tunneling-Tools schleusen Gigabytes von Daten durch harmlos wirkende TXT-Records; DGA-basierte Malware greift auf Tausende zufällig erzeugter Domains zu, um Command-and-Control zu finden; DNS-Amplification-Kampagnen missbrauchen offene Resolver als Reflection-Vektor; und Stub-Clients in Gast-Netzwerken fragen beliebige Upstream-Resolver ab und umgehen so jede andere Sicherheitskontrolle der Organisation.

TR7 DNS-Firewall und Load Balancer behandelt DNS als First-Class-Anwendungsprotokoll, das dieselbe Load-Balancing-, Health-Management-, Caching- und Security-Policy-Durchsetzung verdient, die HTTP-Dienste bereits erhalten.

Unser Ansatz

TR7 behandelt DNS als First-Class-Anwendungsprotokoll: Anfragen erhalten von der ADC-Seite volles Load Balancing und health-bewusste Zustellung, und sie passieren von der WAAP-Seite eine Policy-Engine — alles, ohne dasselbe Gateway zu verlassen.

Intelligentes Load Balancing über DNS-Backends

Mehrere Algorithmen — Round Robin, Least-Outstanding, Consistent Hash, Weighted Random und Weighted Hash — verteilen DNS-Anfragen über Resolver- oder autoritative Pools. Jeder Algorithmus ist auf die Workload abgestimmt: Round Robin für symmetrische Pools, Least-Outstanding für variable Backend-Antwortzeiten, Consistent Hash für Cache-Affinitätsszenarien.

Aktive Zustandsüberwachung hält den DNS-Pfad gesund

Konfigurierbare Health Checks prüfen DNS-Backends kontinuierlich — UDP-Query-Checks, TCP-Query-Checks, benutzerdefinierte Namensauflösungs-Checks. Unhealthy Server fallen innerhalb von Sekunden aus der Rotation; nach Erholung kommen sie automatisch zurück. Dasselbe Health-Modell, das der Rest von TR7 für HTTP-Pools verwendet, gilt auch für DNS-Pools.

DNS-Firewall-Regeln setzen die Sicherheitsrichtlinie für jede Anfrage durch

Per-Rule-Matching auf Query-Name, Query-Type, Quell-IP, EDNS-Optionen, reguläre Ausdrücke und Kombinationen davon. Aktionen umfassen Block, Drop, Refuse, Truncate, Spoofing einer kontrollierten Antwort, Routing zu einem anderen Pool oder Tagging der Anfrage für nachgelagerte Inspektion. Die Richtlinie wird ausgewertet, bevor die Anfrage an irgendein Backend gesendet wird.

DNS-Rate-Limiting und dynamisches Blocking

Rate Limits können pro Quell-IP, pro Query-Name, pro Query-Type oder pro kombinierter Dimension angewendet werden. Dynamische Blocks aktivieren sich automatisch, wenn Traffic-Muster vom Operator definierte Schwellen überschreiten — eine einzelne Quelle, die das Gateway mit NXDOMAIN-Anfragen flutet, wird ohne Operator-Eingriff gedrosselt oder vorübergehend blockiert.

Funktionen

Die TR7 DNS-Firewall und der Load Balancer bringen die volle TR7-Traffic-Management-Philosophie — Load Balancing, Health Checks, Caching, Policy und Observability — in das DNS-Protokoll.

Fünf Load-Balancing-Algorithmen, abgestimmt auf DNS-Workloads

Round Robin für gleichmäßige Pools, Least-Outstanding für Backends mit variabler Antwortzeit, Consistent Hash und Weighted Hash für Cache-Affinitätsszenarien, in denen dieselbe Anfrage dasselbe Backend erreichen soll, und Weighted Random für schrittweise Traffic-Verschiebungen. Jeder vService wählt seinen eigenen Algorithmus; Algorithmen lassen sich live ohne Neustart wechseln.

Server-Pools leiten verschiedene Query-Kategorien an unterschiedliche Backends

Interne Unternehmensdomains können über einen Pool aufgelöst werden, öffentliche Domains über einen anderen, Partnerzonen über einen dritten. Per-Pool-Routing-Regeln lenken Anfragen anhand von QName-Mustern, Quell-IP-Bereichen oder gematchten Policy-Tags. Dasselbe Gateway bedient mehrere DNS-Architekturen sauber.

Aktive Health Checks mit mehreren Probe-Typen

TCP- und UDP-DNS-Query-Probes, benutzerdefinierte Namensauflösungs-Probes und timing-basierte Response-Checks verifizieren die Backend-Health kontinuierlich. Schwellwerte legen fest, wie viele fehlgeschlagene Prüfungen eine Entfernung auslösen und wie viele erfolgreiche Prüfungen ein Backend wieder einsetzen. Langsame Backends können entfernt werden, selbst wenn sie antworten — was benutzersichtbare Latenz verhindert.

Packet-Cache reduziert Backend-Last und beschleunigt die Antwort

Häufig angefragte Records werden am Gateway mit TTL-bewusster Invalidierung gecached. Der Cache respektiert DNSSEC, wo zutreffend, und kann selektiv für sensible Zonen umgangen werden. Die Cache-Hit-Ratio wird in Echtzeitmetriken offengelegt, sodass Operatoren genau sehen, wie viel Last das Gateway absorbiert.

Per-Rule-Matching über QName, QType, Quell-IP und EDNS

Firewall-Regeln matchen auf jede Kombination aus Query-Name (exakt, Suffix, Regex), Query-Type (A, AAAA, TXT, MX, ANY usw.), Quell-IP, EDNS Client Subnet, EDNS-Optionen und Request-Flags. Bedingungen können mit AND/OR-Logik kombiniert werden. Regeln werden in operator-definierter Reihenfolge mit expliziter Allow/Deny-Semantik ausgewertet.

Aktions-Set deckt Block, Drop, Refuse, Truncate, Spoof und Route ab

Block gibt einen kontrollierten Fehler zurück; Drop verwirft still; Refuse gibt REFUSED zurück; Truncate erzwingt TCP-Fallback (nützlich gegen Amplification); Spoof gibt eine kontrollierte Antwort zurück (Block per NXDOMAIN, Redirect zu einem Sinkhole, Rückgabe einer sicheren Alternative); Route sendet die Anfrage an einen anderen Pool. Tag-Aktionen markieren Anfragen für nachgelagerte Inspektion, ohne die Antwort zu verändern.

Erkennung von DGA und DNS-Tunneling

Muster- und statistikbasierte Erkennung identifiziert Anfragen an algorithmisch erzeugte Domains (DGA-Malware-C2) und ungewöhnliche TXT/CNAME-Payloads, die für DNS-basierte Datenexfiltration typisch sind. Erkannte Anfragen können blockiert, in ein Sinkhole geleitet oder nur protokolliert werden für die Analystenprüfung.

Amplification-Angriffsabwehr am Gateway

DNS-Amplification-Angriffe missbrauchen offene Resolver, um Ziele mit reflektiertem Traffic zu fluten. TR7 erkennt ANY-Anfragen, Muster großer Antworten und Quell-Spoofing-Indikatoren und wendet Response Rate Limiting sowie Source-Validation-Aktionen an, bevor eine Reflection auf den Draht geht. Das Gateway wird niemals zum Amplification-Vektor.

Geografische, ASN- und Zugriffskontroll-Richtlinien

Anfragen können nach Quellland, ASN, IP-Bereich oder Zeitfenster bewertet werden. Block-Listen, Allow-Listen und bedingte Aktionsrichtlinien gelten auf der DNS-Schicht genauso wie auf der HTTP-Schicht in TR7 WAAP — mit demselben Policy-Editor und demselben Enforcement-Modell.

Moderne DNS-Transport-Unterstützung — DoT, DoH, DoQ

DNS über TLS (DoT, RFC 7858), DNS über HTTPS (DoH, RFC 8484) und DNS über QUIC (DoQ, RFC 9250) werden am Gateway terminiert. Die Zertifikatsverwaltung verwendet denselben TR7-Zertifikatsspeicher wie HTTP-Dienste. Moderne Stub-Resolver und Browser-DoH-Clients verbinden sich nativ.

EDNS Client Subnet (ECS)-Handling

Von nachgelagerten Resolvern übergebene ECS-Informationen können beachtet, überschrieben, auf ein datenschutzfreundliches Prefix maskiert oder vollständig entfernt werden. Das Verhalten ist per Policy konfigurierbar, was Datenschutz-Compliance für einige Flows ermöglicht und gleichzeitig geografische Genauigkeit für andere bewahrt.

Strukturiertes Logging und Echtzeitmetriken

Jede Anfrage, Entscheidung und Aktion wird in einen strukturierten Log-Stream im SIEM-kompatiblen Format geschrieben. Echtzeitmetriken zeigen Query-Rate, Antwortzeit, Cache-Hit-Ratio, Backend-Health und Regel-Match-Zahlen. Operatoren sehen DNS-Traffic mit derselben Observability-Tiefe, die der Rest von TR7 für HTTP bietet.

Betriebliche Tiefe

Die DNS-Firewall und der Load Balancer werden gemeinsam mit der Regelreihenfolge, der Pool-Topologie, dem Cache-Tuning, der Wahl des Transportprotokolls und der Audit-Aufbewahrung betrieben.

01

Regelauswertungsreihenfolge und explizite Semantik

Firewall-Regeln werden standardmäßig top-down nach First-Match-Wins ausgewertet. Per-Rule-Tags erlauben es nachgelagerten Regeln, auf Basis früherer Matches unterschiedlich zu agieren. Explizite Allow-Regeln am Anfang der Kette fixieren bekannten guten Traffic, bevor generische Block-Regeln greifen, und eliminieren so False Positives in der Produktion.

02

Pool-Topologie und Pool-Auswahl

Backend-Pools gruppieren Resolver nach Zweck: interne Unternehmensauflösung, öffentliche Rekursion, Partnerzonen, Sinkhole-Pool. Per-Pool-Routing-Regeln lenken Anfragen anhand von QName, Quell-IP oder gematchten Tags. Pool-Failover-Schwellen verhindern, dass ein einzelnes unhealthy Backend allen Traffic übernimmt.

03

Packet-Cache-Tuning

Cache-Größe, TTL-Verhalten, ECS-bewusstes Caching und selektives Bypassing für sensible Zonen werden alle vom Operator gesteuert. Negative Response Caching (NXDOMAIN, NODATA) reduziert die Backend-Last für Workloads mit hoher NX-Rate, wie sie in DGA-infizierten Netzwerken typisch sind.

04

Auswahl des Transportprotokolls

Plain UDP/TCP DNS, DoT, DoH und DoQ können pro vService-Listener aktiviert werden. Moderne Clients handeln ihren bevorzugten Transport aus; ältere Clients fallen auf UDP zurück. Zertifikats- und Cipher-Richtlinien orientieren sich am zentralen TR7-TLS-Profil-Pool.

05

Audit-Aufbewahrung und SIEM-Streaming

Per-Query-Audit-Records können für Compliance-Fenster aufbewahrt werden; in umfangreichen Umgebungen lässt sich Sampling anwenden. Strukturierte JSON-Logs streamen direkt an SIEM. Operatoren wählen pro Pool zwischen vollständiger Aufbewahrung, gesampelter Aufbewahrung und Event-only-Aufbewahrung.

06

Hochverfügbarkeitsverhalten

DNS-Sessions sind auf Protokollebene zustandslos, sodass das Failover zwischen aktiven Knoten für die meisten Anfragen transparent ist. TCP-DNS-Sessions und lange DoH-Verbindungen werden über das HA-Paar koordiniert, um Unterbrechungen zu minimieren. Health-Check- und Cache-Status werden pro Knoten unabhängig verwaltet.

Wann einsetzen

Härtung des internen Unternehmens-DNS

Unternehmensresolver, die das interne Netzwerk bedienen, gewinnen Rate Limiting, Query-Filterung, Audit-Logging und Hochverfügbarkeit. Endpunkte können nicht mehr beliebige externe Resolver befragen; DGA-infizierte Hosts werden am Gateway erkannt und blockiert.

Schutz öffentlich erreichbarer rekursiver Resolver

Organisationen, die öffentliche DNS-Dienste betreiben — ISPs, Hosting-Anbieter, öffentliche Portale — terminieren Amplification-Angriffe am Gateway. Rate Limiting, Source-Validation und Response-Pattern-Checks bewahren den Resolver davor, als Reflection-Vektor missbraucht zu werden.

Verhinderung DNS-basierter Datenexfiltration

Netzwerke im Gesundheits-, Finanz- und Behördensektor ergänzen eine Erkennungsschicht für TXT-Record-basierte Exfiltration und Tunneling-Techniken. Verdächtige Flows werden in ein Sinkhole geleitet oder mit vollem Session-Kontext für die Analystenprüfung protokolliert.

Front-Line autoritatives DNS für TR7 GTM

Wenn TR7 GTM autoritatives DNS für Multi-Region-Anwendungen liefert, steht die DNS-Firewall und der Load Balancer vor GTM als Rate-Limiting-, Caching- und Firewall-Schicht. GTM konzentriert sich auf Routing-Intelligenz; das Gateway absorbiert feindlichen Traffic.

Häufig gestellte Fragen

Ist das dasselbe wie TR7 GTM?
Nein. TR7 GTM ist ein autoritativer DNS-Dienst — Sie hosten Ihre Zone darauf und er beantwortet Anfragen zu Ihren eigenen Domains mit intelligenter Routing-Logik. TR7 DNS-Firewall und Load Balancer ist ein Proxy- und Security-Gateway, das vor DNS-Backends sitzt (rekursive Resolver, autoritative Server oder TR7 GTM selbst) und Load Balancing, Caching, Firewall-Regeln, Rate Limiting und moderne Transport-Unterstützung hinzufügt. Beide ergänzen sich: GTM liefert autoritative Routing-Intelligenz, die DNS-Firewall und der Load Balancer liefern DNS-Schicht-Delivery und -Schutz.
Welche DNS-Transports werden unterstützt?
Plain DNS über UDP und TCP (RFC 1035), DNS über TLS (DoT, RFC 7858), DNS über HTTPS (DoH, RFC 8484) und DNS über QUIC (DoQ, RFC 9250). Die Zertifikatsverwaltung für TLS-basierte Transports verwendet denselben TR7-Zertifikatsspeicher wie HTTP-Dienste. Moderne Stub-Resolver und browserseitige DoH-Clients verbinden sich nativ.
Wie schützt das gegen DGA-Malware?
Domain Generation Algorithms erzeugen Tausende zufällig wirkender Domainnamen, damit Malware ihre Command-and-Control-Infrastruktur finden kann. Muster- und statistikbasierte Erkennung identifiziert diese Anfragen — kurze zufällige Labels, ungewöhnliche Zeichenverteilungen, hohe NXDOMAIN-Raten von einer einzelnen Quelle. Erkannte Anfragen werden je nach Richtlinie blockiert, in ein kontrolliertes Sinkhole geleitet oder nur protokolliert.
Wird das Gateway selbst zum Amplification-Vektor?
Nein. Das Gateway wendet Response Rate Limiting (pro Quell-IP und pro Query-Name), Source Validation, ANY-Query-Drosselung und Blocking bekannter schädlicher Quellen an, bevor eine große Antwort reflektiert wird. Operatoren können außerdem Mindest-Response-Größen erzwingen und TCP für Anfragen verlangen, die historisch auf Amplification-Muster hindeuten. Das Gateway ist darauf ausgelegt, Amplification-Versuche zu absorbieren, nicht zu verstärken.
Können wir DNSSEC-signierte Antworten cachen?
Ja. Der Packet-Cache ist DNSSEC-bewusst und respektiert RRSIG-TTLs. Operatoren können den Cache selektiv für Zonen umgehen, bei denen Aktualität wichtiger ist als Performance, und gleichzeitig den Großteil der volumenstarken Anfragen für typische Workloads cachen.
Wie funktioniert das zusammen mit TR7 ADC und TR7 WAAP?
Es verwendet dasselbe vService-Modell, dieselben Backend-Pool-Definitionen, dieselbe Health-Check-Infrastruktur und denselben Policy-Editor wie ADC und WAAP. Die Konfiguration ist plattformübergreifend konsistent — Operatoren müssen kein separates DNS-spezifisches Werkzeug lernen. Als Funktion wird sie sowohl von ADC erkannt (Delivery-Seite: Load Balancing, Caching, moderne Transports) als auch von WAAP (Sicherheits-Seite: Firewall-Regeln, Rate Limiting, Amplification-Abwehr).

Bringen Sie DNS in dieselbe Delivery- und Schutzschicht wie Ihren HTTP-Verkehr

Intelligentes Load Balancing, aktive Health Checks, moderne Transports und eine vollständige Firewall-Regel-Engine — alles in einem Gateway. Lassen Sie uns Sie durch ein Live-Setup auf Ihrer DNS-Infrastruktur führen.