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 Application Delivery Controller 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 Application Delivery Controller 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.
Rekursive Auflösung ab der Root, mit DNSSEC-Validierung
Der Resolver geht die Kette selbst und validiert die Signaturen der Antwort, sodass eine gefälschte Antwort bricht, bevor sie in den Cache kommt. Per Zugriffsliste gesteuert; ein Forward-only-Profil deckt Netze ohne Internet-Egress ab.
Response Policy Zones, live über AXFR/IXFR versorgt
Threat Intelligence kommt als DNS-Zone und aktualisiert sich in Minuten ohne Neustart. Trigger auf den abgefragten Namen, den Client, die zurückgegebene Adresse oder den Nameserver hinter der Zone — und ein Feed, der nicht mehr aktualisiert, löst Alarm aus, statt veraltet ausgeliefert zu werden.
Fünf verschlüsselte Transporte, auf der Appliance terminiert
Do53, DoT, DoH, DoH über HTTP/3 und DNS over QUIC, dazu DNSCrypt. Ein Satz in einer Ausschreibung — „Anfragen müssen über DNS over QUIC angenommen werden“ — und das Feld schrumpft auf eine Plattform.
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.
Abfragemetriken je Zone und je Eintrag, mit RCODE-Verteilung
DNS wird gemessen, nicht vermutet: Abfragezahlen je Zone und je Eintrag, Verteilungen nach Abfragetyp und Antwortcode (RCODE), Sichtbarkeit von Cache-Treffern und -Fehlschlägen sowie Health-Check-Historie mit Failover-Ereignisprotokollen. Ein Anstieg von SERVFAIL oder NXDOMAIN wird zur Zahl auf einem Panel statt zum Supportanruf.
Betriebliche Tiefe
Die DNS-Firewall und der Application Delivery Controller werden gemeinsam mit der Regelreihenfolge, der Pool-Topologie, dem Cache-Tuning, der Wahl des Transportprotokolls und der Audit-Aufbewahrung betrieben.
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.
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.
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.
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.
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.
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.
Fünf verschlüsselte Transporte, drei Auflösungsmodi, eine Policy-Engine
Die Anfrage kommt verschlüsselt an, wird im gewählten Modus aufgelöst und nach einer lesbaren Policy beantwortet. <b>DNS over QUIC wird hier terminiert — keine konkurrierende Application-Delivery-Plattform terminiert es.</b>
Verschlüsselte Transporte — auf der Appliance terminiert
Auflösung — autoritativ, rekursiv, weiterleitend
Policy — Response Policy Zones und Firewall-Aktionen
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 Application Delivery Controller 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?
Welche DNS-Transports werden unterstützt?
Wie schützt das gegen DGA-Malware?
Wird das Gateway selbst zum Amplification-Vektor?
Können wir DNSSEC-signierte Antworten cachen?
Wie funktioniert das zusammen mit TR7 ADC und TR7 WAAP?
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.