AdGuard DNS unterstützt jetzt Structured DNS Errors. Was bedeutet das?

Das Release AdGuard DNS v2.10 ist vom Umfang her vergleichbar mit der DNS-over-QUIC-Implementierung — wieder einmal ist AdGuard DNS der weltweit erste öffentliche DNS-Resolver, der eine neue Funktion implementiert, bevor diese zum offiziellen Standard wird. Diesmal handelt es sich um Structured DNS Errors.

Im Folgenden wird genauer erklärt, was das ist und warum es so wichtig ist. Aber wenn Sie wenig Zeit haben, hier die Zusammenfassung:

• Wenn eine Website auf DNS-Ebene blockiert wird, sehen die Nutzer in den meisten Fällen nur die Fehlermeldung „Diese Website ist nicht erreichbar“, ohne eine Erklärung, was eigentlich passiert ist.
• Um dieses Problem zu lösen, könnten DNS-Server die Benutzer auf ihre eigene Seite mit einer Erklärung umleiten. Für HTTPS-Websites (die die Mehrheit der Websites ausmachen) wäre jedoch ein eigenes Zertifikat erforderlich.
• Es gibt eine einfachere Lösung: Structured DNS Errors (SDE). Sie ermöglichen es, zusätzliche Informationen (wie den Grund für die Sperrung, die verantwortliche Stelle und Kontaktinformationen) in der DNS-Antwort zu senden, so dass der Browser sie lesen und an den Benutzer weitergeben kann. Dies verbessert die Transparenz der Kommunikation erheblich.
• Damit dieses System funktioniert, müssen die Browser SDE unterstützen. Dafür setzen wir uns ein.

Structured DNS Errors: Ein detaillierter Blick

Filterung auf DNS-Ebene ist weit verbreitet. Allein AdGuard DNS hat mehr als 100 Millionen Nutzer. Die Menschen nutzen die DNS-Filterung, um Werbung und Tracker zu blockieren oder ihre Kinder zu schützen. Selbst wenn ein Nutzer DNS nicht selbst eingerichtet hat, wird er dennoch mit DNS-Filterung konfrontiert — aufgrund der Richtlinien seines Landes oder Unternehmens. Man kann davon ausgehen, dass die Zahl der Menschen, die bereits auf DNS-blockierte Websites gestoßen sind, fast so hoch ist wie die Zahl der Internetnutzer insgesamt.

Die Blockierung auf DNS-Ebene verhindert den Zugriff auf eine ganze Domain. Ein Benutzer versucht, https://example.com aufzurufen, sein Browser stellt eine DNS-Anfrage. Der DNS-Server antwortet, dass die Domäne example.com blockiert ist, und der Browser zeigt „Diese Website ist nicht erreichbar“ oder „Keine Internetverbindung“.

Wenn der Benutzer diese Domain nicht manuell blockiert hat, versteht er vielleicht nicht, warum er die Seite nicht öffnen kann. Er könnte sich fragen:

• Stimmt etwas nicht? Soll ich die Seite neu laden?
• Das hat nicht geholfen. Ist die Internetverbindung gestört?
• Die Verbindung ist in Ordnung. Ist die Seite blockiert? Ja, aber warum?
• Vielleicht ist mein DNS-Dienst ausgefallen. Ich sollte es melden.

Die fehlende Kommunikation zwischen dem DNS-Dienst und dem Benutzer ist ein Problem. DNS-Dienste können und wollen dieses Problem lösen — zum Beispiel, indem sie den Benutzer auf eine Seite mit einer ausführlicheren Erklärung weiterleiten, damit er weiß, was passiert ist und an wen er sich wenden kann.
Warum nicht einfach so?

Die Sache hat aber einen Haken:

• Handelt es sich um eine HTTP-Website, d. h. ist die Verbindung nicht verschlüsselt, kann der DNS-Server den Benutzer sicher auf eine unverschlüsselte Seite weiterleiten.
• Handelt es sich um eine HTTPS-Website, führt der Browser eine Zertifikatsauthentifizierung durch und erwartet, dass ein gültiges Zertifikat für https://example.com angezeigt wird. Wenn AdGuard DNS auf seine eigene Seite umleitet, zeigt der Browser einen Fehler bei der Zertifikatsvalidierung an.

Eine Lösung besteht darin, ein spezielles Zertifikat auf dem Gerät des Nutzers zu installieren. Dies ist jedoch nicht immer möglich oder sicher. Es gibt einen viel einfacheren Weg — mehr Informationen in der DNS-Antwort zu senden.

Zu diesem Zweck wurde der 2020-Standard „Extended DNS Errors“ eingeführt, der es ermöglicht, dass DNS-Antworten einen Fehlercode zusammen mit einem EXTRA-TEXT-Feld für weitere Details enthalten. Der Entwurf „Structured DNS Errors“ schlägt außerdem vor, das EXTRA-TEXT-Feld um I-JSON-Dateien (ein eingeschränktes Profil von JSON) zu ergänzen, die von Browsern leicht gelesen und in einem benutzerfreundlichen Format angezeigt werden können.

Was würden diese I-JSON-Dateien enthalten?

• Grund für die Blockierung
• Kontaktinformationen für Rückfragen, falls die Seite versehentlich blockiert wurde
• Organisation, die in diesem Fall für die DNS-Filterung verantwortlich ist (optional)
• Sonstige optionale Informationen

Das ist wirklich praktisch. Ein solches System erhöht die Transparenz zwischen DNS-Diensten und Nutzern und sorgt für die Sicherheit der Nutzer. Wenn sie verstehen, warum eine Website blockiert wird, ist die Wahrscheinlichkeit geringer, dass sie einen sicheren DNS-Server für einen unverschlüsselten aufgeben.

Was wird benötigt, um Extended DNS Errors und Structured DNS Errors zu implementieren?

Die Browser müssen sie unterstützen. Schließlich bestimmen sie, welche Informationen der Benutzer sieht — ob es nur ein Verbindungsfehler ist oder eine detaillierte Erklärung, warum die Website blockiert ist und was als nächstes zu tun ist.

Wir fordern daher die Browserhersteller auf, die Unterstützung für RFC8914 und idealerweise für dessen vorgeschlagene Aktualisierung hinzuzufügen. Diese Änderung wird dazu beitragen, das Internet für Milliarden von Menschen transparenter und benutzerfreundlicher zu machen.

Wie es in AdGuard DNS aussieht

Wir haben eine Demo-Erweiterung erstellt, die zeigt, wie Structured DNS Errors funktionieren könnten, wenn Browser sie unterstützen würden. Wenn man mit dieser Erweiterung versucht, eine Website zu besuchen, die von AdGuard DNS blockiert wird, liest der Browser die über SDE gesendeten Informationen und zeigt eine nette Erklärungsseite an. Viel einfacher zu verstehen als die Beispiele oben, oder?

Sie können die Erweiterung aus dem Chrome Web Store oder von GitHub installieren.

Weitere Verbesserungen: Persönlichere Erfahrung für Nutzer und Organisationen

Zu unserer Zielgruppe gehören sowohl Einzelpersonen, die DNS für ihr Zuhause einrichten, als auch große Unternehmen. Sie haben unterschiedliche Bedürfnisse und Erfahrungen: Einige müssen 10 Geräte verbinden und sind mit der manuellen Einrichtung zufrieden, andere müssen 1.000 Geräte einrichten und bevorzugen die Automatisierung. Um die Bedürfnisse der einzelnen Benutzer besser zu verstehen, haben wir eine Onboarding-Umfrage hinzugefügt, um Informationen über die Ziele und die erwartete Anzahl von Geräten zu sammeln.

Dies wird uns helfen, DNS in Zukunft individueller zu gestalten, indem wir beispielsweise mehr Informationen über Automatisierungsoptionen für diejenigen bereitstellen, die sie benötigen.

Wir freuen uns auf Ihre Meinung

Wie immer möchten wir Sie ermutigen, uns Ihr Feedback und Ihre Ideen auf X oder auf GitHub mitzuteilen.