- Alle Räder stehen still, wenn Dein starker Arm das will
- Kommentar zu aktuellen Hypes um DNS
- HTTPS Absicherung mit DANE durch Middleboxen
- Bereit zum Wechsel des Schlüssels der Root Zone?
- Der Hauptschlüssel des Internets wird gewechselt
- Outsourcing mit Hindernissen
- DNS(SEC) Fehler bei einer Versicherung
DNS ist öffentlich
Es gibt öfters die Frage, warum ich für meine Domains den freien Zonentransfer von überall zulasse. Der wesentliche Grund ist, meine Serverressoucen zu schonen.
An die Einträge einer Zone, die öffentlich per DNS abfragbar ist, kommt man praktisch immer heran:
- Man kann die Einträge schlicht raten, denn DNS Namen sollen ja für Menschen verständlich sein. Mit einigen hundertausend Anfragen ist man gut im Rennen und hat in überschaubarer Zeit eine stattliche Masse an Treffern gelandet.
- Man kann das reverse DNS durchnummerieren. Für alle IP(v4) Adressen eine typischen Kunden braucht man nur ein paar tausend Anfragen. Die Ergebnisse sind praktisch instantan verfügbar und geben beste Anhaltspunkte zum weiteren Raten.
- Man kann mit DNSSEC die Zone ablaufen. Damit ist die Zone mit einigen hundert Anfragen komplett ausgelesen.
Aus Effizienzgründen habe ich mich dafür entschieden, die öffentliche Natur der Daten im DNS dadurch zu dokumentieren, daß ich AXFR von überall zulassen. Dies hat zwei Vorteile:
- Wenn jemand an die Zoneninhalte herankommen will, belastet es meine Serverressoucen nicht wirklich. Es ist nur noch eine Query pro Zone.
- Ich kann beliebig hidden secondaries aufstellen. Diese DNS-Server können sich die Zone einfach ziehen und lokal bedienen. Dies erhöht drastisch die Stabilität von Netzkomponenten, die auf funktionierendes DNS angewiesen sind. Gerade Mailserver und Monitoringsysteme profitieren in Ausfallszenarien deutlich von einer funktionierenden lokalen Auflösung.
Es gibt nun noch die Frage, wieviel Daten ins DNS gehören. Und da vertrete ich die Ansicht, daß eine Unterscheidung zwischen "innen" und "außen" nicht möglich ist. Mobile Kommunikationsformen machen keinen Unterschied, ob das Gerät im lokalen WLAN oder per GSM arbeitet. Beides muß funktionieren. Mit DNSSEC kommt hinzu, daß man nicht trivial intern und extern verschiedene Zonen betreiben kann.
Konsequenterweise bevorzuge ich es, die internen DNS Server (die ja alle IPv6 haben) von extern erreichbar zu machen und dieses als Delegation im DNS zu dokumentieren. Gerade Microsoft Betriebssysteme mit den Active Directory Einträgen danken es einem. Auch wenn IPv6 im Mobilfunknetz nicht funktioniert, verhindert diese Technik wenigstens die NXDOMAIN-Umlenkung auf eine providerseitige Suchmaschine.
Andere Meinungen
Natürlich gibt es andere Ansichten. So schreibt djb von 10^29 Queries beim Raten. Das bezieht sich aber auf das blinde maschinelle Raten beliebiger – vor allem langer und zufälliger – Namen. Diese treten im DNS jedoch praktisch nicht auf. Ich halte die Zahlen von djb schlicht für bewußte Polemik.
Auch die Gegenmaßnahmen gegen DNSSEC Zone Walking überzeugen mich alle nicht besonders. Man kann die NSEC Records dynamisch erzeugen und so minimale Bereiche ausweisen. Der offenkundige Nachteil ist, daß der DNS Server so anfällig für eine CPU-lastige DOS-Attacke wird.
Normalerweise liefert das Zone Walking direkt Klarnamen, wie hier bei den Beweis, daß zwischen "www.iks-jena.de" und "www-cache.iks-jena.de" keine weiteren Einträge liegen und daß für "www.iks-jena.de" nur die Recordtypen A, MX, AAAA sinnvoll existieren:
;; QUESTION SECTION: ;www.iks-jena.de. PTR ;; AUTHORITY SECTION: iks-jena.de. SOA avalon.iks-jena.de. ... iks-jena.de. RRSIG SOA ... www.iks-jena.de. NSEC www-cache.iks-jena.de. A MX AAAA RRSIG NSEC www.iks-jena.de. RRSIG NSEC ...
Man kann aber auch die Namen kryptographisch verschleiern. Ein entsprechender Auszug enthält die Beweise, daß es den Eintrag selbst nicht gibt, sowie auch keine Wildcardeinträge existieren. Die Nichtexistenz des Wildcard ist der Beweis, daß zwischen dem Hash der Zone "de" und dem nächsten Eintrag nichts steht. Nur die Zone selbst hat einen SOA, also muß der Hash "h319dm..." von "de" stammen.
;; QUESTION SECTION: ;iks-jena*.de. IN PTR ;; AUTHORITY SECTION: de. SOA f.nic.de. ... de. RRSIG SOA ... 3tq06gmsoae3cupqcegc23rt137ane2c.de. NSEC3 1 1 15 BA5EBA11 ( 3TQ5J08P3FUF2070LK5EFJA0MHCQ0SG1 ) 3tq06gmsoae3cupqcegc23rt137ane2c.de. RRSIG NSEC3 ... h319dm5gc3edek691vqbhehot7vggj2b.de. NSEC3 1 1 15 BA5EBA11 ( H31A76ES4OKI8LOPOTTQVTAMJ734376J NS SOA NAPTR RRSIG DNSKEY NSEC3PARAM ) h319dm5gc3edek691vqbhehot7vggj2b.de. RRSIG NSEC3 ... svt1592dp1s8dffp1ks6fp0g313vf1i5.de. NSEC3 1 1 15 BA5EBA11 ( SVT86EFS1182P3IPTNLF4E2IH0O34ULQ A RRSIG ) svt1592dp1s8dffp1ks6fp0g313vf1i5.de. RRSIG NSEC3 ...
Was man beim NSEC3 Walking herausbekommt, ist also eine Liste von Hashes der existierenden Einträge. Gegen diese Liste kann man dann die Ratetechnik anwenden. Der große Vorteil ist, daß das Vergleichen von Hashes um Größenordnungen schneller geht, als jeder Versuch eine DNS Anfrage zu stellen. Konsequenterweise gibt es einen nsec3walker.
Fazit
Öffentliches DNS enthält öffentliche Daten. Verstecken ist kein Ersatz für den Schutz der am Netz hängenden Systeme. Auch wenn es weh tut.
Aber: Ich bin es irgendwann leid geworden, ständig irgendwelche Findings von Penetration Tests, die Kunden haben durchführen lassen, zu kommentieren und zu diskutieren. Das AXFR einfach zuzumachen ist der Weg des geringeren Widerstands. Da gibt es andere Bereiche, bei denen ich mit mehr Emotion dabei bin.
Grüße
Marc
Total 1 comments