Wie DNS funktioniert und welche Risiken bestehen

Das Domain Name System (DNS) übersetzt menschenfreundliche Namen wie example.com in IP-Adressen wie 93.184.216.34. Fast jede Netzwerktransaktion beginnt mit einer DNS-Abfrage, wodurch DNS zu einem besonders wertvollen Angriffsziel wird.

Wenn ein Angreifer die Namensauflösung kontrolliert oder manipuliert, kann er Opfer unbemerkt auf bösartige Server umleiten, Datenverkehr abfangen oder Daten exfiltrieren, ohne die Anwendung selbst anzutasten. Das Verständnis des Auflösungspfads ist der erste Schritt zu seiner Absicherung.

Eine typische rekursive Auflösung durchläuft eine Kette von Servern:

• Stub-Resolver auf dem Client (dem Betriebssystem).
• Rekursiver Resolver (Ihr Internetanbieter oder 8.8.8.8), der die eigentliche Arbeit übernimmt.
• Root-Server, die auf die TLD-Server verweisen.
• TLD-Server (z. B. .com), die auf autoritative Server verweisen.
• Autoritative Server, die die tatsächlichen Datensätze enthalten.

Jeder Sprung kann ein möglicher Abfang- oder Spoofing-Punkt sein.

Ein rekursiver Resolver beantwortet jede Anfrage, indem er Verweise im Auftrag des Clients verfolgt und das Ergebnis im Cache speichert. Ein autoritatives Server antwortet nur für die Zonen, für die es zuständig ist, und liefert die verbindlichen Daten.

Aus Sicherheitssicht können offene rekursive Resolver für Amplification-Angriffe missbraucht werden, während autoritative Server Ziele für die Übernahme von Zonen und die Kompromittierung von Registraren sind. Beschränken Sie die rekursive Auflösung auf Ihr eigenes Netzwerk.

Records, die Ihnen bei der Analyse begegnen:

• A / AAAA — IPv4- bzw. IPv6-Adresse.
• CNAME — Alias für einen anderen Namen (achten Sie auf verwaiste CNAMEs, die eine Übernahme von Subdomains ermöglichen).
• MX — Mailserver.
• NS — Delegation an autoritative Server.
• TXT — Freitext, der für SPF und DKIM verwendet und häufig für Tunneling missbraucht wird.

Klassisches DNS läuft über UDP-Port 53, mit einem Fallback auf TCP 53 für große Antworten und Zonentransfers. UDP ist verbindungs- und zustandslos, daher gibt es keinen Handshake, der belegt, dass der Antwortgeber tatsächlich derjenige ist, für den er sich ausgibt.

Die einzige Zuordnung zwischen einer Anfrage und ihrer Antwort besteht aus einer 16-Bit-Transaktions-ID und dem Quellport. Diese schwache Bindung ist die Ursache für Spoofing und Cache-Poisoning.

Um die Last zu reduzieren, speichern Resolver Antworten für die Dauer des TTL (Gültigkeitsdauer) des Records im Cache. Eine Antwort mit TTL 3600 bleibt eine Stunde lang im Cache.

Caching ist zweischneidig: Es verbessert die Leistung, bedeutet aber auch, dass eine einzige vergiftete Antwort vielen Opfern bereitgestellt werden kann, bis die TTL abläuft. Angreifer versuchen häufig, lange TTL-Werte durchzusetzen, damit bösartige Einträge dauerhaft bestehen bleiben.

DNS eröffnet zahlreiche Angriffsflächen:

• On-Path-Spoofing — Fälschen von Antworten, die schneller eintreffen als die des legitimen Servers.
• Cache-Poisoning — Einschleusen fehlerhafter Datensätze in den Cache eines Resolvers.
• Übernahme von Registrar oder Zone — Die Kontrolle über die Domain selbst erlangen.
• Tunneling — Kodieren von Daten in Anfragen, um Kontrollen für ausgehenden Datenverkehr zu umgehen.
• DDoS-Amplification — Missbrauch offener Resolver als Reflektoren.

Herkömmliches DNS bietet keine Garantie für Integrität oder Authentizität. Eine Antwort wird als vertrauenswürdig eingestuft, wenn Quell-IP, Zielport, Abfragename und Transaktions-ID übereinstimmen. Ein Angreifer auf dem Übertragungsweg kann all diese Werte erraten oder beobachten.

Diese Designannahme – dass das Netzwerk vertrauenswürdig ist – erklärt, warum nachträglich aufgesetzte Schutzmechanismen wie DNSSEC, DNS over TLS (DoT) und DNS over HTTPS (DoH) existieren.

Vor einem Angriff zählen Angreifer DNS-Daten auf, um Ihre Infrastruktur abzubilden. Fehlkonfigurierte Zonentransfers (AXFR) können sämtliche Datensätze offenlegen. Brute-Force-Angriffe auf Subdomains und Certificate-Transparency-Logs machen verborgene Hosts sichtbar.

Verteidiger sollten Zonentransfers auf bekannte sekundäre Server beschränken und auf Muster massenhafter Abfragen achten, die auf eine Aufzählung hindeuten.

DNS over TLS (Port 853) und DNS over HTTPS (Port 443) verschlüsseln die Anfrage, sodass Beobachter auf dem Übertragungsweg sie weder lesen noch manipulieren können. Das erschwert Spoofing und schützt die Privatsphäre.

Der Nachteil für Verteidiger: Verschlüsseltes DNS kann die eigenen Filter- und Überwachungsmöglichkeiten einschränken. Viele Unternehmen konfigurieren Clients fest auf einen kontrollierten DoH-/DoT-Resolver, anstatt den Endpunkten die Auswahl externer Resolver zu überlassen.

Praktische Maßnahmen zur Absicherung des Auflösungspfads:

• Betreiben Sie interne rekursive Resolver und blockieren Sie direkte ausgehende Verbindungen über Port 53 ins Internet.
• Deaktivieren Sie die offene Rekursion auf autoritativen Servern.
• Beschränken und protokollieren Sie AXFR-Zonentransfers.
• Sperren Sie die Domain beim Registrar (Registry Lock, MFA).
• Überwachen Sie Abfragevolumen und Entropie auf Tunneling und Aufzählungsaktivitäten.

Testen Sie Ihr Verständnis dafür, warum DNS Angriffen ausgesetzt ist.

Sie haben gelernt, dass die DNS-Auflösung eine Kette vom Stub-Resolver über Root- und TLD-Server bis zu autoritativen Servern durchläuft und dass Antworten anhand der TTL im Cache gespeichert werden. Da klassisches DNS über UDP/53 keine Authentifizierung bietet, ist es Spoofing, Cache-Poisoning, Übernahmen, Tunneling und Amplification-Angriffen ausgesetzt.

Zentrale Schutzmaßnahmen sind geschlossene Rekursion, beschränkte Zonentransfers, Sperren beim Registrar, verschlüsselter Transport (DoT/DoH) und DNSSEC. Als Nächstes gehen wir ausführlich auf Spoofing und Cache-Poisoning ein.