DNS Traffic Engineering

1. Einleitung

Alpin Networks hat bereits einige Erfahrung im Bereich DNS Traffic Engineering. Doch was heisst das eigentlich?

Ich habe in den letzten Jahren mit verschiedenen sogenannten DNS Architekten bei unterschiedlichen Kunden zusammengearbeitet. Der Begriff ist dabei teilweise fragwürdig. Denn was heisst eigentlich DNS Architektur?

DNS Architektur bedeutet nicht einfach, irgendwo zwei DNS Server hinzustellen und die Sache damit als erledigt zu betrachten. Es bedeutet, eine moderne, state of the art DNS Umgebung so zu designen, dass sie mindestens die Grundanforderungen an Verfügbarkeit, Sicherheit, Steuerbarkeit, Trennung der Datenpfade und Betriebsfähigkeit unter Last erfüllt.

Dieser Artikel widmet sich dabei einem oft unterschätzten Teilbereich: DNS Traffic Engineering.

2. Was heisst DNS Architektur überhaupt

DNS Architektur ist mehr als die Anzahl Server oder die Frage, ob die Plattform virtuell oder physisch betrieben wird. Es geht darum, wie der Dienst aufgebaut ist, wie sich Traffic durch das System bewegt, wie Rollen getrennt werden und wie die Plattform unter Last, Fehler oder Angriff kontrollierbar bleibt.

Dazu gehören unter anderem:

• Trennung von Management, Client Traffic und Backend Traffic
• Routing und Rückrouting der verschiedenen Datenpfade
• Schutz des Management Zugriffs unter Last oder DDoS
• saubere Trennung zwischen aDNS und cDNS Rollen
• Filterung und Steuerung auf Betriebssystem Ebene
• klare Modelle für Monitoring, Logging und Troubleshooting

2.1 Begriffe: aDNS und cDNS

In diesem Artikel verwende ich bewusst die Begriffe aDNS und cDNS, weil beide Rollen technisch unterschiedlich sind und deshalb auch unterschiedlich designt werden müssen.

aDNS steht für authoritative DNS. Gemeint sind DNS Server, die autoritativ für Zonen antworten, also zum Beispiel für öffentliche oder interne Domains. Ein aDNS Server beantwortet Anfragen für die Zonen, für die er zuständig ist, rekursiert aber nicht für Clients.

cDNS steht für caching DNS beziehungsweise rekursiven Resolver. Ein cDNS Server nimmt Client Anfragen entgegen, löst diese rekursiv über die DNS Hierarchie oder definierte Upstream Resolver auf und speichert Antworten im Cache.

3. Was ist mit DNS Traffic Engineering gemeint

Mit DNS Traffic Engineering ist die gezielte Steuerung des DNS Verkehrs gemeint.

Dazu gehört unter anderem:

• über welche Interfaces DNS Traffic läuft
• wie Management Traffic von DNS Traffic getrennt wird
• wie eingehende Client Queries und ausgehende Resolver Queries getrennt behandelt werden
• wie Routing und Rückrouting definiert werden
• wie sich Traffic unter Last, DDoS oder Betriebsstörung verhält
• wie auf OS Ebene gefiltert, markiert oder priorisiert wird
• wie sichergestellt wird, dass der Dienst weiterhin administrierbar bleibt

DNS Traffic Engineering ist damit kein Luxus, sondern ein zentraler Teil moderner DNS Infrastruktur.

4. Der Denkfehler aus alten DNS Setups

In Kundengesprächen höre ich immer wieder dieselbe Aussage:

Gemeint ist oft ein Setup, bei dem auf einem Server sowohl Management Traffic als auch eingehender DNS Traffic über dieselbe Schnittstelle laufen. Dieses Modell stammt aus einer Zeit, in der DNS Umgebungen kleiner, einfacher und deutlich weniger exponiert waren.

Für eine moderne DNS Infrastruktur ist das zu kurz gedacht.

Denn eine DNS Plattform muss heute nicht nur Anfragen beantworten. Sie muss auch:

• unter hoher Last stabil bleiben
• unter Angriff administrierbar bleiben
• zwischen verschiedenen Traffic Klassen unterscheiden können
• Rekursion, Authoritative Traffic und Management sauber trennen
• auf Betriebssystem Ebene steuerbar sein

CPU und RAM allein beantworten diese Fragen nicht.

5. Warum Management und DNS Traffic getrennt werden sollten

Ein zentraler Punkt im DNS Traffic Engineering ist die Trennung von Management Traffic und DNS Traffic.

Wenn Management und DNS Queries über denselben Pfad laufen, entsteht ein offensichtliches Problem:

Die Trennung bringt mehrere Vorteile:

• Management bleibt besser kontrollierbar
• Firewall Regeln können differenziert pro Interface greifen
• DNS Traffic kann unabhängig vom Management Traffic gefiltert werden
• Zugriffsmodelle werden klarer
• Betriebsstörungen sind besser eingrenzbar
• Monitoring und Troubleshooting werden sauberer

Wichtig ist dabei: Eine eigene Schnittstelle allein löst das Problem noch nicht vollständig. Wenn derselbe Hypervisor Uplink, derselbe vSwitch oder dieselbe physische Access Schicht betroffen ist, kann auch ein separates Interface mitgestört werden. Wirklich robuste Designs kombinieren deshalb Interface Trennung mit separaten Netzen, ACLs, QoS und idealerweise einem logisch oder physisch getrennten Management Pfad.

6. Zwei Interfaces sind besser als eins

Die erste sinnvolle Verbesserung ist daher ein Design mit mindestens zwei Interfaces:

Das ist bereits deutlich besser als ein Ein Interface Modell. Management und DNS Datenpfad können getrennt gefiltert und kontrolliert werden.

Aber auch das ist noch nicht das Ende. Denn bei einem cDNS Resolver besteht DNS Traffic nicht nur aus eingehenden Client Queries und Antworten an Clients. Ein rekursiver Resolver erzeugt selbst ausgehenden Traffic in Richtung Upstream oder DNS Hierarchie. Genau dieser Traffic sollte in vielen Designs nicht über denselben Pfad laufen wie der eingehende Kundentraffic.

7. Das bessere Modell: drei getrennte Pfade

Für moderne cDNS Resolver ist ein dreigeteiltes Modell oft sauberer:

Damit wird klar getrennt zwischen Betrieb und Administration, Client Facing DNS Service und Resolver Egress.

Dieses Modell hat mehrere Vorteile:

• der Kundentraffic bleibt auf einem klar definierten Pfad
• rekursive Anfragen laufen getrennt vom eingehenden DNS Traffic
• Logging und Troubleshooting werden klarer
• Security Regeln können gezielter formuliert werden
• Upstream Traffic lässt sich separat filtern, limitieren oder überwachen
• Rückwege lassen sich sauberer kontrollieren

7.1 Anycast gehört heute dazu

Ein weiterer Punkt, der bei moderner DNS Infrastruktur nicht fehlen darf, ist Anycast. Für öffentliche DNS Dienste und in vielen grösseren internen Umgebungen ist Anycast heute kein Nice to have mehr, sondern ein Muss. Es verbessert Verfügbarkeit, Lastverteilung und Verhalten im Fehlerfall deutlich.

In der Praxis gehört dazu nicht nur Anycast selbst, sondern auch ein sauberes Routing und Health Modell, typischerweise mit BGP und oft zusätzlich BFD, damit Fehler schnell erkannt und Routen sauber zurückgezogen werden können.

8. Warum dafür Policy Based Routing nötig ist

Sobald eingehender Traffic über eth1 hereinkommt, die rekursiven Lookups aber bewusst über eth2 hinausgehen sollen, reicht klassisches Routing nach Zieladresse oft nicht mehr.

Hier braucht es Policy Based Routing.

Ziel ist dabei:

• Client Queries kommen über eth1
• Antworten an Clients gehen konsistent über eth1 zurück
• rekursive Abfragen des Resolvers gehen aber über eth2 hinaus
• das Ganze bleibt trotzdem symmetrisch und nachvollziehbar

In der Praxis wird das sauber gelöst über separate Routing Tabellen, Regeln auf Quelladressen oder Marks und bei Bedarf zusätzliche Paketmarkierung auf OS Ebene.

9. Was auf OS Ebene zusätzlich wichtig ist

DNS Traffic Engineering endet nicht bei den Interfaces. Auf Betriebssystem Ebene gehören weitere Punkte dazu:

10. Gilt das für aDNS und cDNS gleichermassen

Nein. Und genau hier machen viele Designs den Fehler, beide Rollen gleich zu behandeln. aDNS und cDNS sind keine zwei Namen für dasselbe, sondern zwei klar unterschiedliche DNS Rollen mit unterschiedlichem Traffic Verhalten und unterschiedlichen Anforderungen an Interfaces, Routing und Betriebsmodell.

Das Modell mit einem dedizierten dritten Interface für rekursive Lookups gilt daher primär für cDNS. Bei aDNS kann ein drittes Interface trotzdem sinnvoll sein, aber die fachliche Begründung ist dort eine andere.

11. Was DNS Traffic Engineering in der Praxis bedeutet

DNS Traffic Engineering bedeutet also nicht einfach:

Es bedeutet:

• DNS Pfade bewusst designen
• Rollen und Verkehrsarten trennen
• Rekursion und Authoritative Betrieb unterschiedlich behandeln
• Management Pfade schützen
• Routing bewusst steuern
• den DNS Dienst auch unter Störung, Last oder Angriff kontrollierbar halten

Wer nur zwei grosse Server mit einem Interface baut, baut nicht automatisch eine moderne DNS Plattform. Er baut oft nur ein grösseres altes Muster.

12. Fazit

DNS Architektur bedeutet nicht, einfach zwei Server hinzustellen und auf genügend Ressourcen zu hoffen.

Die eigentliche Frage ist nicht nur, ob DNS antwortet. Die eigentliche Frage ist:

Und genau dort beginnt DNS Traffic Engineering.

Eine moderne DNS Infrastruktur trennt mindestens Management und Client Facing DNS Traffic und bei cDNS zusätzlich den Resolver Egress. Wo nötig, ergänzt um nftables auf OS Ebene, Policy Based Routing, getrennte Management Pfade und klare Betriebsmodelle für Last, Angriff und Fehlerfall.

Anycast mit BGP und BFD gehört in modernen DNS Umgebungen ebenfalls dazu und ist für öffentliche Dienste heute ein Muss. Die Details dazu folgen in einem separaten Beitrag.

Erst dann wird aus einem DNS Server Setup eine belastbare DNS Plattform.