Internet-Filter: Endlich klare Fehlermeldungen

Inhaltsverzeichnis

Von der politischen Agenda, etwa in der EU, sind Filterideen für allerlei Inhalte nicht mehr wegzudenken. Für DNS-Filter zieht die Technik nun nach. Die Internet Engineering Task Force (IETF) will versuchen, den Grund für gescheiterte DNS-Anfragen transparenter zu machen. Dafür hat die Organisation eine neue RFC-Spezifikation aufgelegt (Request For Comment). Im nächsten Schritt will eine kleine Gruppe noch einen Schritt weitergehen und die Möglichkeit vorsehen, die filternde Institution mittels einer eigenen URI anzuzeigen.

Die Liste der Gründe, aus denen eine DNS-Anfrage scheitern kann und weshalb bestimmte Seiten im Netz nicht erreichbar sind, ist lang. So lang, dass die allgemeine Fehlermeldung "ServFail" alles mögliche bedeuten kann, vom ausgelaufenen oder falschen DNSSEC-Schlüssel oder einem nicht unterstützten DNSSEC-Kryptoalgoritmus, über Probleme des DNS-Servers, der für eine Domain zuständig ist (autoritativer DNS-Server) bis hin zu den aus verschiedenen Gründen absichtlich blockierten Inhalten.

Insgesamt 24 neue Fehlercodes führt der neue RFC 8914 ein und obendrein einen für "andere Fehler", DNS Error Code 0. Fein differenziert wird bei den Fehlercodes zwischen blockierten Domainanfragen, zensierten Domains, gefilterten Domains und verbotenen Domains.

Eindeutige Fehlermeldungen

Unter "geblockt" verstehen die Autoren Domains, die der Betreiber des DNS-Resolvers oder -Forwarders auf seine schwarze Liste gesetzt hat, etwa wegen eigener Sicherheitsrichtlinien. Bei einer "zensierten" Domain erfolgt die Blockade wegen Bestimmungen Dritter, etwa wegen staatlicher Filterlisten oder spezifischer gerichtlicher Anordnungen. Als "gefiltert" sind Domains bezeichnet, die auf Wunsch des Nutzers auf einer Blacklist stehen. Solche Meldungen erhalten Nutzer zum Beispiel, wenn sie Kinderschutzfilter eingerichtet haben.

Ein Vorteil der genaueren Fehlermeldungen leuchtet umgehend ein: Technisch begründete Fehler lassen sich leichter als solche erkennen und an die dafür Verantwortlichen melden. Möglicherweise genügt das aber noch nicht, meint eine Gruppe von Autoren von McAfee, Citrix und OpenXchange. Beim jüngsten Treffen der IETF legte die Gruppe daher einen weiteren Vorschlag vor.

Zutritt verboten

Zwar sieht der RFC 8914 schon ein eigenes Textfeld für Anmerkungen vor, die auch eine URI enthalten könnte. Aber die Feldlänge ist begrenzt. Allzu lang darf so ein Feld aber auch nicht sein, weil zu lange Anmerkungen die Obergrenze von DNS-Paketen überschreiten und so zur unerwünschten Fragmentierung der Antwortpakete führen kann, erklärt Vittorio Bertola von OpenXChange das Motiv für den neuen Vorschlag.

Ein ergänzender RFC mit dem Arbeitstitel DNS Access Denied spezifiziert daher einen zusätzlichen Resource Record für eine extra versandte URI. Dieses zusätzliche DNS-Datenbankelement soll dem Anfragenden verraten, was und wer hinter der Blockade steckt. Nutzern könnten auf der aufgefundenen Webseite zudem verschiedene Beschwerdeoptionen angeboten werden. So könnte man etwa melden, wenn man der Ansicht ist, dass eine Seite zu Unrecht geblockt wird. Die Extra-URI erlaube auch, die hinterlegten Informationen leichter dynamisch zu verändern, sagt Bertola.

Haken und Ösen

Doch die Idee vom transparenten Filtern hat generell einen technischen Haken. Die erweiterten Fehlermeldungen und noch mehr die angepappten URIs könnten von Angreifern als Einfallstor für Phishing oder andere Attacken genutzt werden. Chrome-Entwickler hätten daher bereits angekündigt, das RFC 8914 nur bei verschlüsselter DNS-Abfrage zu akzeptieren, erklärt Bertola.

Nur durch konsequente Verschlüsselung könne verhindert werden, dass die Surfer "falsche Umleitungsschilder" von den korrekten Wegen zu ihren Webseiten abbringen. Solche Vorsichtsmaßnahmen versprach McAfee-Entwickler Tirumaleswar Reddy auch für den neuen URI-Vorschlag "Access Denied“. Verschlüsseltes DNS soll dabei verpflichtend sein und eine URI ohne HTTPS-Schutz soll verworfen werden. Angesichts der langen Liste von Einschränkungen könnte der Anwendungsbereich des Konzepts eingeschränkt sein, monierten Teilnehmer der Working Group DNS Operations. Sie raten, zunächst die Akzeptanz des RFC 8914 abzuwarten.

Geofiltering

Auch Facebook hat einen Vorschlag zum Thema DNS. Dem Entwurf zufolge sollen die DNS-Datenströme von rekursiven Resolvern besser sortiert werden. Per TXT- oder HTTPS-Eintrag sollen die rekursiven Resolver mitteilen, welche IP-Präfixe sie verwenden und wo sie geographisch sitzen. Dadurch könnten Latenzen in großen Netzen Latenzen kürzer ausfallen, sagte Manu Bretelle, DNS-Entwickler bei Facebook. Könnte diese Spezifikation nebenbei unterschiedliche Beantwortungen von DNS-Anfragen in unterschiedlichen Ländern erleichtern?

Es könne schon sein, räumt Bertola ein, dass manche dieser Ideen so etwas wie Grenzen im Internet errichten helfen, beziehungsweise nationale Policy-Präferenzen fördern. Sofern aber das Pendel nicht zu weit in Richtung "Nationalismus" ausschlage, könnte die Entwicklung positiv sein. "Wir brauchen einen vernünftigen Mittelweg zwischen 'keine Regeln' und 'zu viel Fragmentierung' als Ergebnis inkompatibler Regeln", meint Bertola. Die Arbeitsgruppe grübelt noch, ob sie die letzten Vorschläge zur IETF-Spezifikationen machen soll. (dz)