CHAOS TXT DNS Resolver Hardening German

CHAOS TXT gilt vielen als obskure Fussnote irgendwo im Fossilienkeller des DNS Protokolls, eine Reliktklasse aus Zeiten, in denen man ernsthaft meinte, Klassen¹ wie HS und CH bräuchten eine Zukunft. In der realen Welt der heutigen Angriffsoberflächen wirkt dieses Fossil allerdings erstaunlich lebendig: genau diese alten Mechanismen werden nach wie vor genutzt, um Resolver auszuleuchten, Implementationen zu fingerprinten und Vorarbeit für den nächsten Exploit zu leisten.

Ich betreibe mit CenturionDNS² bewusst einen Gegenentwurf zu dieser Nachlässigkeit. Wer einen öffentlichen, validierenden Resolver ins Netz stellt, aber gleichzeitig brav auf version.bind antwortet, hat seine Hausaufgaben nicht verstanden, sondern betreibt unfreiwillig Produktmarketing für Exploitkits.

Dieser kurze Beitrag zerlegt deshalb Schritt für Schritt, was CHAOS TXT eigentlich ist, wie daraus Angriffsoberflächen entstehen, welche Vektoren sich mit einem gezielt zusammengestellten Satz geblockter Domains schliessen lassen und weshalb meine Resolver anders gebaut sind als der übliche Mainstream.

DNS arbeitet mit zwei Dimensionen: Name und Typ kennt jeder, die dritte Dimension Klasse bleibt gern unter dem Tisch. Standardmässig bewegt sich so gut wie alles in Klasse IN für Internet, daneben existiert aber unter anderem Klasse CH für CHAOS³, historisch für das Lisp Maschine Umfeld von Symbolics eingeführt.

Genau diese Klasse CH wird seit Jahrzehnten von Nameserver Implementationen für Selbstdiagnose und Identifikation missbraucht. BIND hat früh damit begonnen, auf Anfragen der Form

CHAOS TXT version.bind

oder

CHAOS TXT hostname.bind

spezielle Antworten auszuliefern, typischerweise inklusive Softwareversion und Hostnamen des Servers.⁴

Die Konvention hat sich verselbstständigt, andere Nameserver wie Knot⁵ ⁶ oder CoreDNS⁷ ⁸ übernehmen sie und erlauben standardisiert Antworten auf Namen wie version.bind, hostname.bind, id.server oder später auch version.server.⁹

Die IETF hat diese faktische Praxis irgendwann formell einsortiert. RFC4892¹⁰ beschreibt explizit die Verwendung von CHAOS TXT auf Labels wie id.server und version.server, um Nameserver in Anycast¹¹ Umgebungen zu identifizieren oder Debugging zu erleichtern.

Aus Sicht von Anycast Betreibern und Root Server Operators ist das nachvollziehbar: mit einem simplen

dig @<ip> CH TXT id.server

lässt sich feststellen, welche konkrete Instanz hinter einer Anycast Adresse gerade antwortet. Root Server und grosse Betreiber nutzen diese Mechanismen für Messungen, Hijack Detection und Routing Debugging.¹²

Für öffentliche Resolver, die nicht zu den Root Servern gehören, sieht die Lage anders aus. Dort wird aus dem netten Diagnosetool sehr schnell eine statische Auskunftsfunktion über internste Serverdetails. Und genau da beginnt die Angriffsoberfläche.

Ein Resolver, der ungefiltert auf CHAOS TXT Anfragen reagiert, präsentiert sich wie ein ausführliches Steckbriefblatt. Die üblichen Konventionen kombinieren mehrere Informationsdimensionen:

Softwareversion. version.bind oder version.server liefern je nach Implementierung stringgenaue Versionsangaben der Resolver Software, teilweise inklusive Patchlevel und Betriebsystemartefakten. BIND gibt standardmässig seine Versionszeichenkette aus, sofern der Administrator sie nicht explizit deaktiviert.¹³ Dokumentation und Exploit Sammlungen nennen genau diese Query als Standardweg, um beispielsweise nach verwundbaren BIND Versionen für SigRed oder ähnliche Schwachstellen zu scannen.¹⁴
Identität und Topologie. hostname.bind und id.server enthalten je nach Konfiguration den FQDN des Servers, einen Anycast Knoten Namen oder andere Identifikatoren.¹⁵ Forscher und Betreiber verwenden genau diese Felder, um Anycast Instanzen zu trennen und Routinganomalien zu erkennen.¹⁶ Aus Sicht eines Angreifers lässt sich mit denselben Daten ein Mapping erstellen, welche Knoten zu einem Resolververbund gehören, wie sie benannt sind und welche Netze dahinter stehen.
Implementationsfamilie. Selbst wenn Versionen gestripped sind und statt „BIND 9.20.15“ nur ein Platzhalter wie „[SECURED]“ auftaucht, erlauben Timingverhalten, Antwortlängen, Headerflags und Auswertung mehrerer CHAOS Queries in Kombination ein sehr präzises Fingerprinting. Arbeiten zu Resolver Fingerprinting zeigen genau diese Strategien: Kombination aus CHAOS TXT, speziellen IN Queries, DNSSEC¹⁷ Testdomains und EDNS¹⁸ Optionen.¹⁹
Interner Zustand. Über Zusatznamen wie cachesize.bind, hits.bind, misses.bind, servers.bind oder managed-keys.bind lassen sich Cachegrössen, Hitratios oder Details der DNSSEC Schlüsselverwaltung auslesen, sofern der Betreiber nicht nachgezogen hat. Entsprechende Checks findet man in Monitoring Suiten und kommerziellen „DNS Integrity“ Produkten, die ausdrücklich davor warnen, diese Informationen im öffentlichen Netz preiszugeben.²⁰

Die offensichtliche Verwendungsart in der Offensive Security Welt liegt auf der Hand. Werkzeuge wie nmap²¹, fpdns²², diverse Penetrationstestsammlungen und Recon Frameworks rufen genau diese Queries ab, um aus einer nackten IP Adresse ein exaktes Modell des dahinter arbeitenden DNS Stacks zu bauen.²³

Wer kennt, welcher Resolvertyp und welche Version auf Port 53 lauscht, spart sich wildes Raten. Man kann direkt gezielt Proof of Concept Code für bekannte Schwachstellen testen, Vorbedingungen für Cache Poisoning Experimente prüfen, Fragmentierungsangriffe abstimmen oder entscheiden, ob sich der Angriff über DNSSEC Eigenheiten lohnen dürfte.²⁴

Kurz formuliert: CHAOS TXT ist der klassische Bannergrabbing Kanal für DNS, bloss ohne TCP Banner und ohne Login. Und wie bei allen Bannergrabbing Vektoren lautet die nächste Frage: weshalb lässt man die überhaupt offen, wenn man es besser weiss.

Die Blockstrategie, die ich in CenturionDNS verfolge, setzt bewusst früh an. AdGuard Home bietet die Möglichkeit, bestimmte Domains als „nicht zugelassen“ zu definieren. Anfragen werden still verworfen, sie tauchen nicht im Log auf und werden nie an den eigentlichen Resolver weitergereicht. Genau diese Eigenschaft nutze ich, um den gesamten CHAOS Versuchszirkus auf der Aussenschale zu terminieren.

Der Satz an geblockten Domains lässt sich in mehrere Gruppen gliedern.

Die erste Gruppe umfasst die klassischen Identitätskonventionen. Dazu gehören version.bind, version.server, hostname.bind, hostname.server, id.server sowie Mischformen wie server.id oder id.server.bind. Diese Namen bilden den Kern der in RFC 4892 formalisierten Praxis und werden in praktisch jeder Dokumentation zu CHAOS Queries im Zusammenhang mit Resolveridentifikation zitiert. Wer sie blockiert, zerschneidet bereits einen grossen Teil des klassischen Fingerprinting Pfades.
Die zweite Gruppe beinhaltet Meta Informationen über Implementationen und Autoren. authors.bind, authors.server und abwegigere Varianten wie authorsid.bind tauchen selten im Produktivbetrieb auf, finden sich aber in Wordlists, Scannern und historischen Implementationen.²⁵ Hier geht es weniger um konkrete Exploits, sondern um Reduktion von Seitendaten, die Angreifern das Clustern von Installationen ermöglichen.
Die dritte Gruppe besteht aus introspektiven Statistiknamen. Werte wie cachesize.bind, hits.bind, misses.bind, insertions.bind, evictions.bind, servers.bind oder managed-keys.bind verraten internste Kennzahlen. Aus Sicht eines Penetrationstesters lässt sich damit abschätzen, ob ein Resolver überprovisioniert, knapp dimensioniert oder unter Last steht und wie seine DNSSEC Verankerung gehandhabt wird.²⁶ Im öffentlichen Betrieb hat diese Form der Selbstauskunft keinen Mehrwert.
Die vierte Gruppe sind implementationseigene Besonderheiten. In die Kategorie fallen zum Beispiel trustanchor.unbound bei Unbound Instanzen oder Vendor spezifische Labels wie version.pdns, version.pdns-recursor, version.yadifa und ähnliche Konstrukte, die in Dokumentationen und Blogposts zu diesen Produkten auftauchen.²⁷ Selbst wenn gerade keine konkrete Schwachstelle darauf aufbaut, destabilisiert jeder zusätzliche Informationskanal das Prinzip der Informationsminimierung.

Die Wirkung des Filters lässt sich ziemlich trocken zusammenfassen. Ein Scanner, der mit einer Standardsequenz von CHAOS Queries arbeitet, läuft gegen eine schwarze Wand. Keine Versionsstrings, keine Hostnamen, keine Statistiken, keine DNSSEC Key Details. Im besten Fall sieht er NXDOMAIN, im schlechteren Fall einen Timeout, aber in keinem Fall die Art von Material, aus der Lust auf Exploitentwicklung entsteht.

Natürlich lässt sich mit ausreichend Aufwand auch ohne CHAOS Antworten ein Fingerprint basteln. Es bleibt möglich, anhand von Edgecases im Protokollverhalten zwischen BIND, Unbound, Knot, PowerDNS, dnsmasq, CoreDNS und obskuren Eigenbauten zu unterscheiden. Forschung dazu existiert zur Genüge.²⁸ Der Punkt einer gehärteten Konfiguration liegt jedoch gerade darin, den trivialen, kostengünstigen Pfad konsequent zu verschliessen.

Die CenturionDNS Architektur kombiniert mehrere Schichten, die gemeinsam eine Defence in Depth für DNS darstellen. Die Behandlung von CHAOS TXT bildet darin nur eine feine, aber konsequente Kante.

An der Aussenseite arbeitet AdGuard Home, verantwortlich für DoQ²⁹, DoT³⁰, klassisches UDP/TCP DNS und die Policy Logik, die in meinem Setup Advertiser, Malware und diverses unerwünschtes Netzrauschen ausfiltert. Dahinter sitzt Unbound als validierender, rekursiver Resolver, der ausschliesslich IN Queries nach aussen sendet, DNSSEC³¹ sauber validiert, QNAME Minimisation³² betreibt und keine überflüssigen Upstreamresolver einbindet.

In AdGuard Home ist die Liste „Nicht zugelassene Domains“ explizit mit den relevanten CHAOS Namen gefüllt. Wenn irgendein Client versucht, version.bind, hostname.bind, id.server, authors.bind, version.server, cachesize.bind, trustanchor.unbound oder verwandte Namen aufzulösen, dann wird die Anfrage von AdGuard verworfen, ohne dass Unbound davon überhaupt erfährt.

Parallel dazu ist auf Unbound Seite keine CHAOS spezifische Spezialbehandlung aktiv, die ihrerseits Antworten generieren würde. Unbound dokumentiert selbst, dass Anfragen in Klassen wie CH in erster Linie zu Debuggingzwecken auftreten, behandelt sie aber nicht als produktiven Teil des Resolverbetriebes.³³ Es existiert folglich keine zusätzliche Angriffsoberfläche aus diesem Pfad.

Auf der autoritativen Seite, also im CenturionNet mit BIND 9 als Nameserver im Hidden Master Betrieb, ergibt sich ein ähnliches Bild. BIND Dokumentation und Knowledge Base zeigen exemplarisch, wie sich sowohl version.bind als auch hostname.bind im CHAOS Kontext auf „none“ setzen lassen.³⁴ Ich konfiguriere autoritative Server grundsätzlich so, dass sie für CHAOS Queries keine aussagekräftigen Antworten liefern. Wer versucht, meine Nameserver auf Port 53 als Spielwiese für Bannergrabbing zu benutzen, erhält exakt nichts Informatives.

Zusammen mit weiteren Härtungsmassnahmen wie striktem TSIG³⁵ Einsatz für Zonentransfers³⁶, DNSSEC Signierung, Rate Limiting und sauberer Trennung zwischen Resolvern und Autoritativen entsteht eine Infrastruktur, die nicht nur funktional korrekt arbeitet, sondern auch die Hilfskanäle für Reconnaissance weitgehend austrocknet.

Wie positioniert sich dieses Verhalten im Vergleich zu den üblichen Verdächtigen im Consumer und Enterprise Umfeld.

Grosse öffentliche Resolver wie Google Public DNS oder Cloudflare 1.1.1.1 haben immerhin verstanden, dass direkte Versionsauskunft auf Anfrage keine geniale Idee ist. Dokumentierte Tests und Erfahrungsberichte zeigen, dass Anfragen wie dig @8.8.8.8 CHAOS TXT version.bind keine Versionszeichenkette liefern, sondern mit einer neutralen Antwortform wie SERVFAIL oder leerem Resultat abgewiesen werden.³⁷ Das ist ein Fortschritt gegenüber der frühen Phase, in der selbst grosse Provider noch stolz ihre exakten BIND Versionen präsentierten.

Root Server und bestimmte Anycast Netze bleiben aus gutem Grund eine Ausnahme. Hier werden CHAOS TXT Anfragen gezielt für Debugging und Routing Analysen genutzt, um etwa einzelne Instanzen identifizieren zu können. Die entsprechende Literatur zur Messung und Hijack Detection beschreibt das sehr offen.³⁸ Es handelt sich dabei aber um einen kontrollierten Einsatz in einer klar abgegrenzten Rolle, nicht um das sorglose Offenstehenlassen dieser Mechanismen an zufälligen ISP Resolvern.

Im Massenmarkt sieht die Lage weniger erfreulich aus. Zahlreiche Routerfirmwares, CPE Boxen, Enterprise Appliances und selbstgepflegte BIND oder dnsmasq Installationen in Unternehmen beantworten noch immer brav version.bind, hostname.bind und artverwandte Queries mit detaillierten Informationen.

Sicherheitsblogs, Pentest Handbücher und Recon Tools dokumentieren genau diese Realität, mit konkreten Befehlen und Beispielen, wie Resolver über version.bind CHAOS TXT und ähnliche Queries identifiziert und klassifiziert werden.³⁹

Hinzu kommt: der typische Anwender eines öffentlichen Resolvers erhält keine verbindliche Aussage dazu, wie mit CHAOS umgegangen wird, ob und welche Meta Informationen weiterhin ausgeliefert werden, welche Logging Policies gelten und, ob mögliche zusätzliche Diagnose Endpunkte existieren. Im besten Fall gibt es Marketing Blätter mit Aussagen wie „Privacy first“ und „Security focussed“, aber keine verifizierbare Beschreibung der Härtung im Detail.

CenturionDNS führt hier eine bewusst andere Linie. Meine Resolver sind nicht nur validierend, DNSSEC affine und über saubere Protokolle wie DoT⁴⁰, DoQ⁴¹ und DoH⁴² erreichbar, sondern in ihrem Verhalten gegenüber exotischen Anfragen dokumentierbar restriktiv. Ich entscheide bewusst, welche Antworten überhaupt möglich sind, und entferne systematisch alles, was eigentlich nur Nettigkeit gegenüber Scannerframeworks darstellt.

Angriffsminimierung als Designprinzip

Die Diskussion um CHAOS TXT illustriert exemplarisch einen grundlegenden Unterschied zwischen zwei Philosophien im Sicherheitsdesign.

Die bequeme Variante lautet: „Standarddefaults werden schon passen, wir patchen nach, wenn jemand eine CVE⁴³ ⁴⁴ schreibt.“ Dieses Muster sieht man quer durch die IT, von exponierten Webservern, die lauthals ihre exakte Apache oder nginx Signatur im Server Header mitteilen, bis hin zu DNS Resolvern, die ohne Not Versionsstrings, interne Hostnamen und Metriken preisgeben.

Die alternative Variante ist anstrengender. Sie geht davon aus, dass jede zusätzliche Auskunft, die ein Dienst ins Netz stellt, eine potentielle Angriffsoberfläche erhöht, selbst dann, wenn aktuell keine konkrete CVE daran hängt. Informationsminimierung ist kein akademischer Luxus, sondern gelebte Ausprägung des Prinzip „least information“, analog zu „least privilege“⁴⁵.

CHAOS TXT ist in diesem Bild ein Paradebeispiel. Man kann argumentieren, dass die dort transportierten Informationen für bestimmte Debugging Szenarien nützlich sind. Man kann aber genauso gut festhalten, dass der Schaden, den sie im produktiven, öffentlich erreichbaren Resolverbetrieb anrichten, strukturell grösser ist als ihr Nutzen.

Ich habe mich mit CenturionDNS deshalb für eine radikale, aber gut begründbare Entscheidung entschieden: auf meinen öffentlichen Resolvern existiert faktisch kein sinnvoll auswertbares CHAOS Antwortverhalten. Wer Bannergrabbing spielen möchte, darf das mit jemand anders machen. Die Resolver selbst bleiben so schweigsam wie möglich.

Am Ende lässt sich CHAOS TXT als kleines Detail im grossen Ganzen abtun. Man kann sich einreden, dieser eine Querytyp würde den Unterschied nicht ausmachen, solange doch DNSSEC aktiv ist und der Resolver irgendwie vertrauenswürdig wirkt. Genau diese Mentalität unterscheidet allerdings Mittelmass von ernsthaftem Sicherheitsdesign.

CenturionDNS steht für das Gegenteil von „wird schon reichen“. Ich hänge mir keine „Security by Design“ Schlagworte an die Tür und hoffe darauf, dass niemand nachfragt. Ich dokumentiere, wie meine Resolver aufgebaut sind, welche Protokolle sie sprechen, welche Klassen und Recordtypen sie akzeptieren, welche sie ignorieren und an welcher Stelle explizite Härtung greift.

Die Blockierung von CHAOS TXT über gezielt konfigurierte „nicht zugelassene Domains“ in AdGuard Home, das Hinterlegen eines validierenden Unbound mit sauber gesetzten Trust Anchors, DNSSEC Validierung und QNAME Minimisation, die Trennung von Resolvern und autoritativen Nameservern, die Härtung von BIND gegen Info Leaks, die Abwesenheit beliebiger dritter Upstreamresolver und eine restriktive Loggingpolitik sind keine Zufallsprodukte, sondern bewusst gesetzte Bausteine.

Wer meine Resolver nutzt, bekommt nicht nur schnelle Antworten und einen werbefreien, malwarebereinigten Namensraum, sondern auch die Gewissheit, dass selbst scheinbar unbedeutende Fossilien wie CHAOS TXT nicht als Seiteneingang für Reconnaissance offenstehen.

Worldclass DNS heisst für mich eben nicht, irgendwo einen schicken Markennamen auf einen Standardstack zu kleben, sondern bis in diese kleinen, historisch aufgeladenen Ecken hinein aufzuräumen. Genau dort trennt sich nach meiner Erfahrung die Spreu vom Weizen.

Angriffsminimierung als Designprinzip

Widgets