Kommentar zu aktuellen Hypes um DNS
Ja, die Erwartungen an das heutige Internet haben sich gewandelt. Es ist nicht mehr die vorgeblich heile Welt, in der man vertrauensvoll mit anderen kommunizieren konnte. Jeder Dienstleister, sei es die besuchte Webseite oder der eigne Provider, wird argwöhnisch unter die Lupe genommen. Über all diesem steht die Furcht vor der Politik, dem Staat und den Geheimdiensten.
Lauscher
Es ist nur vernünftig, nicht zu gutgläubig im Netz unterwegs zu sein. Man kann seine E-Mails verschlüsseln (und macht es doch nicht), man kann darauf achten, Webseiten nur über verschlüsseltes HTTPS zu besuchen, man kann SSH und viele andere verschlüsselte Protokolle nutzen. Alle diese Methoden schützen vor dem Ausspionieren auf dem Transportweg.
Aber sie tun es nicht vollständig. Immer noch kann man erkennen, wer mit wem wie viel Daten austauscht. Um das zu verschleiern, muss man auf TOR-Netzwerke setzen. Eine andere Alternative ist es, sämtliche Nutzungsarten auf wenige große Anbieter zu verteilen. Man geht nicht nur in der Masse unter, sondern läßt den Mitlauscher auch im unklaren über seine detaillierten Aktivitäten.
Wer bin ich?
Trotzdem bleibt ein weiteres Problem: Die Namensauflösung. Wir sind es gewohnt, bei E-Mail-Adressen, URL-Zeilen, Spiele-Servern, ja bei jeder Interaktion mehr oder weniger sprechende Namen zu benutzen. Der Dienst, der die Namen in IP-Adressen der zugehörigen Server umwandelt ist das DNS, das Domain-Name-System.
DNS ist clever konstruiert, es funktioniert wie eine verteilte Datenbank. Die innere Struktur der Namen entspricht Hierarchieebenen, die in unterschiedlicher Verantwortung stehen und von vielen verschiedenen Parteien betrieben wird. Die Delegation reicht bis in die Firma oder den Hobbykeller. Von dort aus wird die ganze Welt mit Auskünften versorgt, falls mal jemand wirklich was mit mir zu tun haben will. Das System stellt die Auskunftsdaten in den Hoheitsbereich des jeweiligen (Web-, Mail-)Server-Betreibers. Die Entscheidung, wer welche Auskunft bekommt, liegt damit praktisch beim Endnutzer. So kann eine Firma beispielsweise intern mehr und andere Dienste betreiben als nach außen sichtbar sein sollen.
Eine weitere clevere Idee ist, die Namensauflösung in spezielle Software, die Resolver, durchzuführen. Alles, was diese Software benötigt, ist ein Internetzugang und eine kleine Anzahl fester Root-Server-Adressen, die zu wirklich jeder Frage eine Antwort kennen (auch wenn diese nur heißt, man möge bitte da drüben nachfragen). Diese Resolver merken sich alle Ergebnisse, die sie im Laufe der Zeit zu Gesicht bekommen und halte sie eine bestimmte (einstellbare) Zeit vor. So können sie viele Anfragen direkt beantworten und belästigen nicht den Rest der Welt. Caching sorgt so dafür, dass die Last der DNS-Quell-Server nicht zu groß wird. Da diese Resolver so wenig Anforderungen stellen, kann und soll praktisch jeder und jedes Gerät einen solchen Resolver betreiben.
Früher waren jedoch nicht alle Geräte so leistungsstark, einen vollen Resolver selbst zu betreiben. Also hat die Firma oder der Provider einen großen, leistungsfähigen zentralen Resolver hingestellt den alle Clients benutzen. Der Caching-Effekt wird durch diese regionale Zentralisierung größer, es werden deutlich weniger Anfragen an die DNS-Quell-Server geschickt.
Fäschungen und Zensur
Das Problem mit dem System ist, dass alle Anfragen unverschlüsselt und unauthentisiert sind. Jeder auf dem Weg kann mitlesen und die Antworten beliebig verändern. Da veränderte Antworten gefährlich sind (Umlenkung der Bankseite zu Phishern), wurde DNSSEC erfunden. Es unterschreibt die DNS-Antworten und verhindert somit eine Manipulation. Wer als Betreiber einer eigenen Zone diese nicht unterschreibt, handelt fahrlässig. Es ist wie der Betrieb eines HTTP-Server ohne HTTPS: Man bringt seine Nutzer und Kunden in Gefahr.
Auch die letzte Meile, also die Verbindung zum zentralen Resolver kann man mit DNSSEC gegen Manipulationen schützen. Alternativ kann man hier auch auf die gehypten Verfahren DNS-over-TLS (DOT) oder DNS-over-HTTPS (DoH) setzen, die zusätzlich die letzte Meile verschlüsseln. Besser ist es aber gleich einen eigenen DNSSEC validierenden Resolver auf dem Endgerät zu betreiben, denn das schützt auch gegen Manipulationen am vorgegeben Resolver selbst. Einige Provider lenken Tippfehler auf eigene Seiten um (NXDOMAIN-Rewriting), das muss man sich ja nicht antun.
Bleibt das Problem, das DNS Anfragen i.d.R. immer den vollen Namen anfragen als z.B. www.heise.de, auch wenn sie sich an einen Root-Server wenden. Die Idee dabei ist, die Antwortzeiten zu verkürzen, wenn der angefragte Server ohnehin schon mehr Details kennt, die er gleich mit schicken kann. Solche zusätzlichen Antworten wurden für Angriffe ausgenutzt, indem der DNS-Server von firma.de bei der Frage nach www.firma.de auch immer gleich noch eine (falsche) Antwort für www.heise.de mitschickte und die Resolver diese treudoof lernten. Mit DNSSEC wird es wieder möglich, diese zusätzlichen Antworten auszuliefern, weil der Resolver sie anhand der Signaturen als valide erkennen kann. Hat man das nicht, muss man mit den Antworten sorgsam umgehen.
Privatsphäre
Das Privacy-Problem ist nun noch anzugehen: Alle Root-Server bekommen die vollen Anfragen zu sehen. Aber auch hier gibt es seit Anbeginn eine Empfehlung: DNS kann Zoneninhalte komplett transferieren. Mit AXFR (Vollabzug) oder IXFR (Änderungen) kann ein Resolver präventiv die komplette Zone ein lernen und braucht nie wieder die Quell-Server mit konkreten Fragen zu belästigen. Die Root-Zone unterstützt das Modell, es ist für jeden Nutzer, der Wert auf Privatsphäre legt, zu empfehlen.
Die meisten Top-Level-Domains unterstützen den Zonentransfer nicht, meist aus markenrechtlichen Überlegungen. Hier würden also zumindest ein Teil der Anfragen aufschlagen. Es gibt seit eingen Jahren jedoch auch Resolver, die gerade bei den TLDs nur nach der delegierten Zone fragen und so die Privatsphäre der Anwender schützen.
Auch für private oder Firmen-Zonen ist ein offenes AXFR meist sinnvoll. Nicht nur, dass man wichtige Server so wesentlich stabiler betreibt, man gestattet so auch seinen Nutzern eine höhere Privatsphäre. Selbstverständlich darf man ins DNS keine ernsthaften Geheimnisse rein schreiben, aber das macht man ja sowieso nicht. Mit beliebig vielen Versuchen kann man die Namen immer automatisiert herausbekommen.
Fazit
Zusammengefasst kann man sagen: DNS ist gereift, es kann mit den Bedrohungen der Überwachung und Zensur umgehen. Alles was man tun muss, ist einen eigenen, validieren Resolver zu betreiben, wenn möglich mit einer Kopie der Root-Zone. Bis auf DNSSEC (gegen Zensur) sind das alles Empfehlungen aus den Frühzeiten des DNS.
Wenn ein Protokoll alt wird, stirbt mangels Nutzung einfach aus. Protokolle wie DNS überleben jedoch, indem sie sich an geänderte Anforderungen anpassen oder flexibel genug eingesetzt werden können.
Mein persönlicher Vorwurf an die Protagonisten von DoH ist folgender: Wer ein verteiltes System zugunsten einer Handvoll großer Anbieter aufgibt, dabei aktive Nutzungsfälle wie Split-DNS sabotiert und auf lokale Validierung verzichtet, der bekommt zentrale Überwachungs- und Zensursysteme. Es ist von einem technischen Redakteur unverantwortlich, seine Leser derartig in die Irre zu führen und sie damit in Gefahr zu bringen.
Das Internet basiert auf zwei grundsätzlichen Prinzipien: Dezentraliät und Interoperabilität. Internet ist das genaue Gegenteil von großen, zentralen Plattformen. Es ist die große, weite Landschaft, nicht der eingezäunte Garten.
2018102900 ; serial
1800 ; refresh (30 minutes)
900 ; retry (15 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
;; Query time: 219 msec
;; SERVER: 2001:500:2f::f#53(2001:500:2f::f)
;; WHEN: Mon Oct 29 16:56:10 2018
;; XFR size: 22470 records (messages 111, bytes 1328893)
Die komplette Root-Zone braucht ca. 2,5 MByte Hauptspeicher (für aufbereitete Strukturen). Dafür spart man sämtliche Anfragen in diese Richtung. Alle 30 min gibt es *eine* Anfrage ob's was neues gibt an einen Root-Server. Mehr ist nicht.
Ich hab' das fast überall schon lange ausgerollt:
auth-zone:
name: "."
for-downstream: no # do not use zone data for direct answers
for-upstream: yes # use them as exernal source, validate before handing out
fallback-enabled: yes
master: f.root-servers.net
master: b.root-servers.net
master: c.root-servers.net
master: e.root-servers.net
master: g.root-servers.net
master: k.root-servers.net
Ein Zonentransfer für donnerhacke.de sind knapp 9k. Wie mag das erst bei Amazon der Cloudflare werden? (Wenn sie DNSSEC mal machen sollten)
Auch wenn danach nur noch IXFR gemacht wird.
Und wie groß muß der Speicher auf den Endgeräten sein, um die kompletten Zonen zu cachen? Wenn ich da an die ganzen CDNs denke, kommen mir Zweifel.
Von DoT hatte ich bis vor kurzem noch nie was gehört.
4 Kommentare