Internet-Spezifikationen: IETF streitet um Fortentwicklung der DNS-Auflösung

Inhaltsverzeichnis

Sollen verschlüsselnde DNS-Abfragen interne Belange ignorieren und nur öffentliche Domain Name Server (DNS) befragen, oder die nur im internen Netz vorhandenen Domains über einen internen DNS-Resolver auflösen? Darüber sind sich die Experten der Internet Engineering Task Force (IETF) uneins.

Split-DNS ist ein dehnbarer Begriff. Für manche bedeutet er nicht weniger als Hijacking von Domainnamen in internen Netzen, für andere handelt es sich um legitimen Hausgebrauch. Manche sehen es gar als alternativlose Praxis in modernen Unternehmensnetzen. Der Knackpunkt ist: Haben die gespaltenen DNS-Informationen noch Platz in der Welt des verschlüsselten DNS?

Die ersten Spezifikationen, die Nutzern die Auswahl eines verschlüsselnden DNS-Resolvers ermöglichen sollen, sind fast fertig. Gestritten wird jetzt darüber, ob die neuen Methoden Split-DNS-Umgebungen berücksichtigen sollen.

Kurzer Rückblick: Seit Edward Snowden enthüllt hat, dass die NSA Nutzerbewegungen im Internet unter anderem anhand unverschlüsselter DNS-Anfragen im großen Stil protokolliert hat, arbeiten die DNS-Entwickler der IETF an verschlüsselnden Verfahren. Herausgekommen sind unter anderem DNS-over-TLS (DoT), DNS-over-HTTPS (DoH) und Oblivious DNS-over-HTTPS.

User müssen passende Domain Name Server finden

Zuletzt hat die IETF an Methoden zum automatischen Auffinden verschlüsselnder Resolver gearbeitet. Das sollte verhindern, dass Browser-Hersteller den DNS-Verkehr im großen Stil zu einzelnen Resolver-Betreibern verschieben. Denn Nutzer wollen zwar gerne mehr Privatsphäre und setzen dafür auch gerne DNS-over-HTTPS ein.

Doch weil die Suche nach DoH-Resolvern aufwendig ist, nehmen sie oft einfach einen von denen, die Mozilla im Firefox-Browser vorschlägt. Das ist bequem, muss nicht unbedingt zu dem aus Nutzersicht geeignetsten Domain Name Server führen. Daher will die IETF-Arbeitsgruppe Adaptive DNS Discovery (ADD) zwei Varianten zur automatischen Resolver-Discovery abschließen, sodass Browser automatisch geeignete Resolver finden und zur Auswahl anbieten.

Zankapfel Split-DNS

Bleibt die Frage, ob das Konzept Split-DNS in der neuen verschlüsselten DNS-Welt abgebildet werden soll. Diese Frage haben kürzlich drei IETF-Arbeitsgruppen auf einem Minigipfel diskutiert: Adaptive DNS Discovery (ADD), DNS Privacy (DPRIVE) und DNS Operations (DNSOP).

Dabei wurde beim virtuellen Treffen schon über die Definitionen des Split-DNS-Begriffs gestritten. Im Grundsatz beschreibe man mit Split-DNS Szenarien, bei denen ein interner Resolver andere Antworten auf dieselben DNS-Anfragen gibt, als ein externer Resolver, erläuterte Ben Schwartz von Google.

Im einfachsten Fall kommt Split-DNS zum Einsatz, damit interne Clients überhaupt interne Server ansprechen können. Denn viele interne Server sollen privat bleiben und nicht im öffentlichen DNS verzeichnet sein. Dann gibt es die Fälle, in denen Server sowohl intern als auch extern erreichbar sind. Interne Clients sollen in der Regel den direkten Weg im Firmennetz nehmen, nicht über das öffentliche Internet – um die Leitung zu entlasen, und aus Gründen der Sicherheit und Vertraulichkeit.

Zu Problemen kommt es beispielsweise, wenn intern Domains verwendet werden, die auch im öffentlichen Internet eingetragen sind. DNS-Squatting nennen das manche und rümpfen darüber die Nase. Beispielsweise liegt bei Fritzbox-Routern eine Namenskollision vor, weil sie intern die Domain .box verwenden, die seit einigen Jahren als Top-Level-Domain registriert ist.

Split-DNS wird zudem für lokales Filtern eingesetzt, wie BIND-Guru und Farsight-Security-Gründer Paul Vixie bei der Sitzung hervorgehoben hat. Manche Unternehmen, Universitäten oder Schulen nutzen ihre internen Resolver, um Zugriffe auf Malware-Seiten oder bestimmte Inhalte zu blockieren, so Vixie. Und manche Firmen unterbinden Zugriffe auf Facebook mit dem Hinweis, dass das während der Arbeitszeit nicht gestattet sei, so ein Teilnehmer.

Grundsatzstreit

Das Problem, dass sich lokale Filter mittels verschlüsselnder Clients umgehen lassen, hat bereits im Verlauf der Standardisierung für heftige Reaktionen der Politik gesorgt – sogar britische Lords haben schon über empfundene Gefährdung durch DoH diskutiert.

Google-Entwickler Schwartz ist dagegen, möglichst viele Split-DNS-Szenarien im verschlüsselnden DNS abzubilden. Manche könnten von der neuen Architektur nicht mehr unterstützt werden, meint er, und verweist auf transparente HTTP-Proxies. In den 90ern ganz selbstverständlich genutzt, um Anfragen der User ressourcensparend lokal zu beantworten, seien sie mit der Verbreitung des HTTPS-Verkehrs verschwunden. Eine ähnliche Entwicklung erwarte er für manche Split-DNS-Szenarien.

"Wenn mein Google Chromecast eine Adresse und ein Gateway von meinem DHCP-Server zugeteilt erhält, und die auch nutzt, meinen lokalen DNS-Server aber ignoriert und einfach alle DNS-Anfragen an (Googles DNS-Server unter der IP-Adresse) 8.8.8.8 schickt, ist das eine fragwürdige Praxis", sagte Schwartz, "So etwas dürften alle Security Experten klar ablehnen.“

Vixie pocht stattdessen darauf, Nutzer bei der Entscheidung, welcher Resolver ihre DNS-Anfragen beantwortet, nicht zu übergehen. Wenn eine App DNS-Anfragen an einen externen Resolver schicken will, müsse sie den Nutzer um Erlaubnis fragen. Googles Weg, DNS-Anfragen selbst zu beantworten, sei zwar aufgrund vieler Probleme mit "schlechtem DNS" nachvollziehbar. Aber es bedeute für Nutzer rund um den Globus auch einen Eingriff in die Vertraulichkeit.

Lösungsvorschläge

Geht es nach Schwartz und seine Mitautoren, soll sich die IETF auf eine kleine Lösung für die Verheiratung von verschlüsseltem und Split-DNS beschränken. Ein dafür authentifizierter DNS-Server soll die lokal aufzulösenden Domains auflisten. DNSSEC oder eine Authentifizierung über den normalen DNS-Kanal, etwa per Zertifikatslösung, sollen Hijacking vermeiden. Dies könnte auch eine Lösung für VPNs sein, so die Experten. Und Namen, die im öffentlichen DNS nicht eingetragen sind, etwa lokal genutzte .corp-Namen, soll die IETF-Spezifikation gar nicht erst berücksichtigen.

Wenn man sich beschränke, könne man bestimmte Split DNS-Anwendungen sicherer und besser machen, findet Schwartz. Mehr sei nicht drin. Damit werde die Mehrzahl von Split-DNS-Deployments links liegen gelassen, bemängelt hingegen Google-Kollege Warren Kumari.

So kommen die beiden Lager wohl nicht zusammen.

Um eine Einigung können die drei DNS-Arbeitsgruppen bald wieder auf der kommenden IETF-Konferenz im März in Wien ringen. Diese soll erstmals seit dem Ausbruch des SARS-Cov-2-Virus wieder hybrid abgehalten werden. Dort wird die ADD-Arbeitsgrupe erneut vor der Frage stehen, ob sie das von Schwartz vorgestellte Split-DNS-Discovery als offiziellen Standardentwurf akzeptiert. Bislang gab es dagegen noch zu viel Widerstand.

(dz)