Dieses Dokument beschreibt Datenschutzüberlegungen die mit der Nutzung des DNS durch des DNS durch Internet-Nutzer verbunden sind. Es enthält allgemeine Beobachtungen über typische aktuelle Datenschutzpraktiken. Es soll eine Analyse der gegenwärtigen Situation sein der gegenwärtigen Situation und schreibt keine Lösungen vor.

Inhaltsverzeichnis

1. Einführung
2. Geltungsbereich
3. Risiken
4. Risiken in den DNS-Daten
4.1. Der öffentliche Charakter von DNS-Daten
4.2. Daten in der DNS-Anfrage
4.2.1. Daten in der DNS-Nutzlast
4.3. Cache-Snooping
5. Risiken auf dem Draht
5.1. Unverschlüsselte Transporte
5.2. Verschlüsselte Transporte
6. Risiken auf den Servern
6.1. In den rekursiven Resolvern
6.1.1. Auswahl des Resolvers
6.1.2. Aktive Angriffe auf die Resolver-Konfiguration
6.1.3. Blockierung von DNS-Auflösungsdiensten
6.1.4. Verschlüsselte Transporte und rekursive Resolver
6.2. In den autoritativen Nameservern
7. Andere Risiken
7.1. Re-Identifizierung und andere Rückschlüsse
7.2. Weitere Informationen
8. Tatsächliche „Angriffe“
9. Rechtliche Aspekte
10. Sicherheitserwägungen

Verwendete [Referenzen] werden nicht direkt im Dokument verlinkt stehen aber natürlich öffentlich zur Verfügung: https://datatracker.ietf.org/

DNS Leak Test

1. Einleitung

Dieses Dokument ist eine Analyse der DNS-Datenschutzproblematik, im Sinne von
von Abschnitt 8 von [RFC6973].

Das Domain Name System (DNS) ist in [RFC1034], [RFC1035],
und vielen späteren RFCs beschrieben, die nie konsolidiert wurden. Es ist eine
eine der wichtigsten Infrastrukturkomponenten des Internets und wird
wird von Internet-Benutzern (und sogar von vielen Fachleuten) oft ignoriert oder missverstanden.
Fachleuten). Fast jede Aktivität im Internet beginnt mit einer
DNS-Abfrage (und oft mehreren). Seine Nutzung hat viele Auswirkungen auf die
und dieses Dokument ist ein Versuch einer umfassenden und genauen
genauen Liste.

Beginnen wir mit einer vereinfachten Erinnerung daran, wie das DNS funktioniert (siehe
auch [RFC8499]). Ein Client, der Stub-Resolver, stellt eine DNS-Anfrage an
einen Server, den rekursiven Resolver (auch Caching Resolver genannt,
Full Resolver oder rekursiver Nameserver). Verwenden wir die Abfrage „Wie lauten die
sind die AAAA-Einträge für www.example.com?“ als Beispiel. AAAA ist
der QTYPE (Abfragetyp), und www.example.com ist der QNAME (Abfrage
Name). (Die folgende Beschreibung geht von einem kalten Cache aus, zum Beispiel
weil der Server gerade erst gestartet wurde.) Der rekursive Resolver
fragt zunächst die Root-Nameserver ab. In den meisten Fällen werden die Root-Name-Server
Server einen Verweis. In diesem Beispiel lautet der Verweis
an die .com-Nameserver. Der Resolver wiederholt die Anfrage an einen der
den .com-Nameservern. Die .com-Nameserver verweisen ihrerseits auf
die Nameserver von example.com. Die example.com-Nameserver geben dann
die Antworten zurück. Die Root-Nameserver, die Nameserver von .com,
und die Nameserver von example.com werden als autoritative Nameserver
Server genannt. Bei der Analyse der Datenschutzproblematik ist es wichtig, dass
zu bedenken, dass die an alle diese Nameserver gestellte Frage immer die
die ursprüngliche Frage ist, nicht eine abgeleitete Frage. Die Frage, die an die
die Root-Nameserver gerichtet ist, lautet: „Wie lauten die AAAA-Einträge für
www.example.com?“, nicht „Welches sind die Nameserver von .com?“. Durch
Wiederholung der vollständigen Frage, statt nur des relevanten Teils der Frage
Frage an den nächsten in der Reihe, liefert das DNS dem Nameserver mehr Informationen als
mehr Informationen als nötig an den Nameserver. In dieser vereinfachten Beschreibung,
rekursive Resolver nicht die QNAME-Minimierung wie in [RFC7816] beschrieben
wie in [RFC7816] beschrieben, die nur den relevanten Teil der Frage
an den vorgelagerten Nameserver senden.

DNS stützt sich stark auf die Zwischenspeicherung, daher ist der oben beschriebene Algorithmus
etwas komplizierter, und nicht alle Fragen werden an die
die autoritativen Nameserver gesendet. Wenn der Stub-Resolver den
rekursiven Resolver ein paar Sekunden später: „Wie lauten die SRV-Einträge von
_xmpp-server._tcp.example.com?“, wird sich der rekursive Resolver daran erinnern
dass er die Nameserver von example.com kennt und wird sie einfach abfragen
ab und umgeht dabei die Wurzel und .com. Da es typischerweise kein
Zwischenspeicherung im Stub-Resolver gibt, sieht der rekursive Resolver, anders als die
autoritativen Servern, den gesamten DNS-Verkehr. (Anwendungen, wie
Webbrowser, können eine Form der Zwischenspeicherung haben, die nicht den DNS
Regeln folgen, weil sie zum Beispiel die TTL ignorieren können. Daher sieht der
rekursive Resolver sieht also nicht alle Aktivitäten zur Namensauflösung).

Es ist zu beachten, dass rekursive DNS-Auflöser manchmal
Anfragen an andere rekursive Resolver weiterleiten, in der Regel größere Rechner,
mit einem größeren und gemeinsam genutzten Cache (und die Abfragehierarchie kann
noch tiefer sein, mit mehr als zwei Ebenen rekursiver Resolver). Unter
dem Gesichtspunkt des Datenschutzes sind diese Forwarder wie Resolver
mit dem Unterschied, dass sie nicht alle Anfragen sehen, die gestellt werden (aufgrund der
Caching im ersten Resolver).

Zum Zeitpunkt der Erstellung dieses Berichts wird fast der gesamte DNS-Verkehr
unverschlüsselt. Es wird jedoch zunehmend DNS über TLS eingesetzt
(DoT) [RFC7858] und DNS over HTTPS (DoH) [RFC8484], insbesondere in
mobilen Geräten, Browsern und von Anbietern von rekursiven Anycast-DNS
Auflösungsdiensten. Es gibt einige wenige Fälle, in denen es eine
alternative Kanalverschlüsselung, zum Beispiel in einem IPsec-VPN-Tunnel,
zumindest zwischen dem Stub Resolver und dem Resolver. Einige neuere
Analysen zur Dienstqualität von verschlüsseltem DNS-Verkehr finden sich
in [dns-over-encryption].

Heutzutage werden fast alle DNS-Anfragen über UDP gesendet [thomas-ditl-tcp].
Dies hat praktische Konsequenzen, wenn man die Verschlüsselung des
Datenverkehrs als eine mögliche Technik zum Schutz der Privatsphäre. Einige Verschlüsselungslösungen
sind nur für TCP und nicht für UDP konzipiert, obwohl neue Lösungen immer noch
entstehen [RFC9000] [DPRIVE-DNSOQUIC].

Ein weiterer wichtiger Punkt, den man bei der Analyse des Datenschutzes im Auge behalten muss
DNS-Problematik ist die Tatsache, dass DNS-Anfragen, die ein Server erhält, aus
aus unterschiedlichen Gründen ausgelöst werden. Nehmen wir an, ein Lauscher möchte
wissen, welche Webseite von einem Benutzer aufgerufen wird. Für eine typische Webseite,
gibt es drei Arten von DNS-Anfragen, die gestellt werden:

Primäre Anfrage:
Dies ist der Domänenname in der URL, den der Benutzer eingegeben, aus einem Lesezeichen ausgewählt
aus einem Lesezeichen oder durch Klicken auf einen Hyperlink ausgewählt hat. Vermutlich,
ist dies das, was für den Lauscher von Interesse ist.

Sekundäre Anfragen:
Dies sind die zusätzlichen Anfragen, die vom User Agent
(hier der Webbrowser) ohne direkte Beteiligung oder Wissen des
Wissen des Benutzers durchgeführt werden. Im Web werden sie ausgelöst durch
eingebettete Inhalte, Cascading Style Sheets (CSS), JavaScript-Code,
eingebettete Bilder, usw. In einigen Fällen kann es Dutzende von
Domänennamen in verschiedenen Kontexten auf einer einzigen Webseite geben.

Tertiäre Anfragen:
Dies sind die zusätzlichen Anfragen, die vom DNS-Dienst
selbst durchgeführt werden. Wenn zum Beispiel die Antwort auf eine Abfrage eine Verweisung auf eine
Nameserver ist und die Glue Records nicht zurückgegeben werden, muss der
Resolver zusätzliche Anfragen senden, um die Namen der Nameserver in
Namen der Nameserver in IP-Adressen umzuwandeln. Auch wenn Glue Records
zurückgegeben werden, sendet ein sorgfältiger rekursiver Server tertiäre
Anfragen, um die IP-Adressen dieser Datensätze zu überprüfen.

Es kann auch festgestellt werden, dass im Falle eines typischen Webbrowsers mehr
DNS-Anfragen mehr als unbedingt nötig gesendet werden, zum Beispiel, um
Ressourcen vorzuholen, die der Benutzer später abfragen kann, oder wenn
automatische Vervollständigung der URL in der Adressleiste. Beides ist ein erhebliches
Datenschutzproblem, da sie Informationen über nicht explizite
explizite Aktionen. So kann zum Beispiel das bloße Lesen einer lokalen HTML-Seite, auch
ohne Auswahl der Hyperlinks, DNS-Anfragen auslösen.

Die datenschutzbezogene Terminologie stammt aus [RFC6973]. Dieses Dokument
macht [RFC7626] überflüssig.

2. Anwendungsbereich

Dieses Dokument konzentriert sich hauptsächlich auf die Untersuchung der Risiken für die Privatsphäre des
Endbenutzer (derjenige, der DNS-Anfragen stellt). Die Risiken der allgegenwärtigen
Überwachung [RFC7258] werden ebenso betrachtet wie die Risiken, die sich aus einer
gezielteren Überwachung. In diesem Dokument wird der Begriff „Endbenutzer“
gemäß der Definition in [RFC8890] verwendet.

In diesem Dokument wird nicht versucht, einen Vergleich der spezifischen
Schutzmaßnahmen einzelner Netze oder Organisationen zu vergleichen; es
Es werden nur allgemeine Beobachtungen über typische aktuelle Praktiken gemacht.

Datenschutzrisiken für den Inhaber einer Zone (das Risiko, dass jemand
die Daten) werden in [RFC5155] und [RFC5936] diskutiert.

Datenschutzrisiken für rekursive Betreiber (einschließlich Zugangsanbieter und
Betreiber in Unternehmensnetzen), wie z. B. das Bekanntwerden von privaten
Namespaces oder Blocklists sind nicht Gegenstand dieses Dokuments.

Risiken, die nicht die Privatsphäre betreffen (z. B. sicherheitsbezogene Überlegungen wie
Cache Poisoning) sind ebenfalls nicht Gegenstand dieses Dokuments.

Die Risiken für den Schutz der Privatsphäre im Zusammenhang mit der Verwendung anderer Protokolle, die
DNS-Informationen nutzen, werden hier nicht berücksichtigt.

3. Risiken

Die folgenden vier Abschnitte skizzieren die Überlegungen zum Datenschutz
die mit verschiedenen Aspekten des DNS für den Endbenutzer verbunden sind. Beim
dieser Abschnitte ist zu bedenken, dass viele der Überlegungen (z. B. rekursiver
Überlegungen (z. B. rekursiver Resolver und Transport
(z. B. rekursiver Resolver und Transportprotokoll) spezifisch für den Netzkontext sein können, den ein Gerät
zu einem bestimmten Zeitpunkt verwendet. Ein Benutzer kann viele Geräte haben, und
jedes Gerät kann über einen bestimmten Zeitraum viele verschiedene Netze nutzen (z. B. zu Hause, am Arbeitsplatz,
öffentliche Netze oder Mobilfunknetze) über einen bestimmten Zeitraum oder sogar gleichzeitig nutzen. Eine
erschöpfende Analyse der Überlegungen zum Datenschutz für einen einzelnen
Nutzer müsste die Menge der verwendeten Geräte und die verschiedenen
mehreren dynamischen Kontexten der einzelnen Geräte berücksichtigen. In diesem Dokument wird nicht
versucht nicht, eine solche komplexe Analyse durchzuführen; stattdessen wird ein Überblick über
Überblick über die verschiedenen Überlegungen, die die Grundlage einer solchen
Analyse bilden könnten.

4. Risiken in den DNS-Daten

4.1. Der öffentliche Charakter von DNS-Daten

Es wurde festgestellt, dass „die Daten im DNS öffentlich sind“. Dieser
Satz macht Sinn für ein internetweites Nachschlagewerk, und es gibt
Daten und Metadaten haben viele Facetten, die eine genauere Betrachtung verdienen.
genauere Betrachtung verdienen. Erstens: Ungeachtet der Zugangskontrolllisten (ACLs) und privaten
Namespaces ungeachtet, arbeitet das DNS unter der Annahme
dass die öffentlich zugänglichen autoritativen Namensserver auf „normale“
DNS-Anfragen für jede Zone, für die sie autoritativ sind, ohne weitere
Authentifizierung oder Autorisierung des Clients (Resolvers). Aufgrund der
fehlenden Suchfunktionen werden nur bei einem bestimmten QNAME die
Ressourcendatensätze, die mit diesem Namen verbunden sind (oder die
Nichtvorhandensein). Mit anderen Worten: Man muss wissen, wonach man fragen muss, um
um eine Antwort zu erhalten. Es gibt viele Wege, auf denen vermeintlich
„private“ Ressourcen derzeit durchsickern. Ein paar Beispiele sind DNSSEC NSEC
Zone Walking [RFC4470], passive DNS-Dienste [passive-dns], usw. Die
Zonentransfer QTYPE [RFC5936] wird oft blockiert oder auf
authentifizierten/autorisierten Zugriff gesperrt oder beschränkt, um diesen Unterschied durchzusetzen (und vielleicht
aus anderen Gründen).

Ein weiterer Unterschied zwischen den DNS-Daten und einer bestimmten DNS
Transaktion (d. h. einer DNS-Namenssuche): DNS-Daten und die Ergebnisse einer
DNS-Abfrage sind öffentlich, innerhalb der oben beschriebenen Grenzen, und dürfen
keine Vertraulichkeitsanforderungen haben. Das Gleiche gilt jedoch nicht
gilt jedoch nicht für eine einzelne Transaktion oder eine Folge von Transaktionen; diese
Transaktionen sind nicht bzw. sollten nicht öffentlich sein. Eine einzelne Transaktion
offenbart sowohl den Absender der Abfrage als auch den Inhalt der Abfrage; dies
möglicherweise sensible Informationen über einen bestimmten Nutzer preisgeben. A
typisches Beispiel außerhalb der DNS-Welt ist, dass die Website der
Anonymen Alkoholiker öffentlich ist, aber die Tatsache, dass Sie sie besuchen, sollte
nicht sein. Außerdem gibt die Möglichkeit, Abfragen zu verknüpfen, Informationen
über individuelle Nutzungsmuster.

4.2. Daten in der DNS-Anfrage

Die DNS-Anfrage enthält viele Felder, aber zwei davon scheinen
besonders relevant für den Datenschutz: der QNAME und die
Quell-IP-Adresse. „Quell-IP-Adresse“ wird in einem lockeren Sinne von
„Quell-IP-Adresse + vielleicht Quell-Port-Nummer“, da die Port-Nummer
Portnummer ist auch in der Anfrage enthalten und kann zur Unterscheidung zwischen
zwischen mehreren Benutzern, die sich eine IP-Adresse teilen (zum Beispiel hinter einem Carrier-Grade
NAT (CGN), zum Beispiel [RFC6269]).

Der QNAME ist der vollständige Name, der vom Benutzer gesendet wird. Er gibt Informationen
darüber, was der Benutzer tut („Was sind die MX-Einträge von example.net?“
bedeutet, dass er wahrscheinlich eine E-Mail an jemanden unter example.net senden möchte,
was eine Domäne sein kann, die nur von wenigen Personen genutzt wird und daher
sehr aufschlussreich über Kommunikationsbeziehungen). Einige QNAMEs sind
sensibler als andere. Zum Beispiel verrät die Abfrage des A-Eintrags einer
bekannten Webstatistik-Domain sehr wenig auf (jeder
besucht Websites, die diesen Analysedienst nutzen), aber die Abfrage des A
Datensatzes von www.verybad.example, wobei verybad.example die Domäne einer Organisation ist
einer Organisation ist, die manche Leute als anstößig oder verwerflich empfinden, kann
mehr Probleme für den Benutzer verursachen. Außerdem enthält der QNAME manchmal die
die verwendete Software ein, was ein Problem für den Datenschutz darstellen könnte (z. B.,
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
Es gibt auch einige BitTorrent-Clients, die einen SRV-Eintrag abfragen für
_bittorrent-tracker._tcp.domain.example.

Ein weiterer wichtiger Punkt in Bezug auf die Privatsphäre des QNAME ist die zukünftige
Verwendungen. Heutzutage ist der Mangel an Privatsphäre ein Hindernis für die Speicherung
potenziell sensible oder persönlich identifizierbare Daten im DNS zu speichern. Unter
Momentan könnte Ihr DNS-Verkehr zeigen, dass Sie E-Mails austauschen
E-Mails austauschen, aber nicht mit wem. Wenn Ihr Mail User Agent (MUA) beginnt
Pretty Good Privacy (PGP)-Schlüssel im DNS [RFC7929] nachzuschlagen, wird
wird der Datenschutz sehr viel wichtiger. Und E-Mail ist nur ein Beispiel;
Es gäbe noch andere interessante Anwendungen für ein datenschutzfreundlicheres
freundlichen DNS.

Für die Kommunikation zwischen dem Stub-Resolver und dem rekursiven
Resolver ist die Quell-IP-Adresse die Adresse des Rechners des Benutzers.
Daher gelten alle Probleme und Warnungen bezüglich der Sammlung von IP
Adressen gelten hier. Für die Kommunikation zwischen dem rekursiven
Resolver und den autoritativen Nameservern hat die Quell-IP-Adresse
eine andere Bedeutung; sie hat nicht den gleichen Status wie die
Quelladresse bei einer HTTP-Verbindung. Normalerweise ist es die IP-Adresse
des rekursiven Resolvers, die in gewisser Weise den tatsächlichen Benutzer „versteckt“.
Das Verstecken funktioniert jedoch nicht immer. Die edns-client-subnet (ECS)
EDNS0-Option [RFC7871] wird manchmal verwendet (siehe eine Datenschutzanalyse in
[denis-edns-client-subnet]). Manchmal hat der Endbenutzer einen persönlichen
rekursiven Resolver auf seinem Rechner. In beiden Fällen wird die IP-Adresse
die Anfragen an den autoritativen Server stellt, genauso sensibel wie
wie bei HTTP [sidn-entrada].

Ein Hinweis zu IP-Adressen: Es gibt derzeit kein IETF-Dokument, das
das alle Fragen des Datenschutzes im Zusammenhang mit IP-Adressen im Detail beschreibt
allgemein beschreibt, obwohl [RFC7721] Überlegungen zum Datenschutz für
IPv6-Adressgenerierungsmechanismen. In der Zwischenzeit soll die Diskussion
hier sowohl IPv4- als auch IPv6-Quelladressen. Aus
einer Reihe von Gründen sind ihre Zuweisungs- und Nutzungseigenschaften
unterschiedlich, was sich auf die Einzelheiten des Informationsverlusts
Informationslecks im Zusammenhang mit der Sammlung von Quelladressen haben kann. (Zum
(So ist es beispielsweise weniger wahrscheinlich, dass eine bestimmte IPv6-Quelladresse, die im öffentlichen Internet
ist es weniger wahrscheinlich als eine IPv4-Adresse, dass sie hinter einem Adress-Sharing
Sharing-Schema stammt.) Sowohl für IPv4- als auch für IPv6-Adressen ist es jedoch
zu beachten, dass die Quelladressen bei Abfragen über die
über die ECS-Option weitergegeben werden und Metadaten über den Host, den Benutzer oder die
Anwendung enthalten, von der sie stammen.

4.2.1. Daten in der DNS-Nutzlast

Zum Zeitpunkt der Erstellung dieses Berichts gibt es keine standardisierten Client-Identifikatoren
in der DNS-Nutzlast selbst enthalten (ECS, wie in [RFC7871] beschrieben,
ist weit verbreitet; allerdings ist [RFC7871] nur ein Informational RFC).

DNS Cookies [RFC7873] sind ein leichtgewichtiger DNS-Transaktionssicherheitsmechanismus
Transaktionssicherheitsmechanismus, der einen begrenzten Schutz gegen eine Reihe von
zunehmend verbreiteten Denial-of-Service- und Amplifikations-/Fälschungs- oder
Cache-Poisoning-Angriffe durch Off-Path-Angreifer. Es wird jedoch darauf hingewiesen,
dass sie nur für die Überprüfung von IP-Adressen ausgelegt sind (und sich ändern sollten
ändern, sobald sich die IP-Adresse eines Kunden ändert), aber sie sind nicht dazu gedacht
Benutzer aktiv zu verfolgen (wie HTTP-Cookies).

Es gibt vereinzelte Berichte über Media Access Control (MAC)-Adressen
(https://lists.dns-oarc.net/pipermail/dns-
operations/2016-January/014143.html) und sogar Benutzernamen, die
in nicht standardmäßige EDNS(0)-Optionen [RFC6891] für Stub-to
Resolver-Kommunikation eingefügt werden, um proprietäre Funktionen zu unterstützen
die im Resolver implementiert sind (z. B. elterliche Filterung).

4.3. Cache-Snooping

Der Inhalt der Caches von rekursiven Resolvern kann Daten über die
Clients offenbaren (die Risiken für die Privatsphäre hängen von der Anzahl der Clients ab).
Diese Informationen können manchmal durch Senden von DNS-Anfragen untersucht werden
mit RD=0 gesendet werden, um den Cache-Inhalt zu untersuchen, insbesondere die DNS
TTLs [grangeia.snooping]. Da es sich hierbei auch um eine Aufklärungs
für spätere Cache-Poisoning-Angriffe ist, wurden bereits einige
wurden bereits einige Gegenmaßnahmen entwickelt und implementiert
[cache-snooping-defence].

5. Risiken auf dem Draht

5.1. Unverschlüsselte Transporte

Bei unverschlüsselten Übertragungen kann der DNS-Verkehr von einem
Lauscher wie jeder andere Verkehr gesehen werden. (DNSSEC, spezifiziert in
[RFC4033] spezifiziert, schließt Vertraulichkeit ausdrücklich von seinen Zielen aus.) Also,
Wenn ein Initiator eine HTTPS-Kommunikation mit einem Empfänger startet, wird der
HTTP-Verkehr verschlüsselt, der DNS-Austausch davor jedoch nicht.
nicht. Wenn andere Protokolle immer datenschutzfreundlicher werden und
gegen Überwachung geschützt werden (z. B. [RFC8446], [RFC9000]), wird die Verwendung von
unverschlüsselter Transporte für DNS zum „schwächsten Glied“ in der
Privatsphäre werden. Es wird darauf hingewiesen, dass zum Zeitpunkt der Erstellung dieses Berichts
Arbeiten zur Verschlüsselung der Server Name Identification (SNI) im
TLS-Handshake [RFC8744] zu verschlüsseln, der eine der letzten verbliebenen nicht
DNS-Klartext-Identifikatoren eines Verbindungsziels.

Eine wichtige Besonderheit des DNS-Verkehrs ist, dass er einen
einen anderen Weg nehmen kann als die Kommunikation zwischen dem Initiator und dem
Empfänger. So kann ein Lauscher beispielsweise die Leitung zwischen Initiator und Empfänger nicht abhören.
Leitung zwischen dem Initiator und dem Empfänger abhören, hat aber Zugang zu
die Leitung, die zum rekursiven Resolver oder zu den autoritativen Namensservern
Servern.

Der beste Ort zum Abhören ist aus der Sicht eines Abhörers
eindeutig zwischen den Stub-Resolvern und den rekursiven Resolvern,
da der Datenverkehr nicht durch DNS-Caching eingeschränkt wird.

Die Angriffsfläche zwischen dem Stub-Resolver und dem Rest der Welt
Welt kann sehr unterschiedlich sein, je nachdem, wie das Gerät des Endbenutzers
konfiguriert ist. In der Reihenfolge der zunehmenden Angriffsfläche:

Der rekursive Resolver kann sich auf dem Gerät des Endbenutzers befinden. Unter
einer (derzeit) geringen Anzahl von Fällen können Einzelpersonen
ihren eigenen DNS-Auflöser auf ihrem lokalen Rechner zu betreiben. In diesem
Fall ist die Angriffsfläche für die Verbindung zwischen dem Stub
Resolver und dem Caching-Resolver auf diesen einen Rechner beschränkt.
Rechner beschränkt. Der rekursive Resolver gibt Daten an autoritative
Resolver, wie in Abschnitt 6.2 beschrieben.
Der rekursive Resolver kann sich am lokalen Netzwerkrand befinden. Für
viele/meiste Unternehmensnetze und einige private Netze,
kann sich der Caching-Resolver auf einem Server am Rande des
lokalen Netzwerks. In diesem Fall ist die Angriffsfläche das lokale
Netzwerk. Beachten Sie, dass in großen Unternehmensnetzen der DNS-Auflöser
nicht am Rande des lokalen Netzwerks, sondern am Rande des
sondern am Rande des gesamten Unternehmensnetzes. In diesem Fall kann das
Unternehmensnetzwerk ähnlich wie das Netzwerk des Internet
Access Provider (IAP)-Netzwerk, auf das weiter unten verwiesen wird.
Der rekursive Resolver kann sich im IAP-Netz befinden. Für die meisten
privaten Netzen und möglicherweise auch anderen Netzen ist der typische
Fall, dass das Gerät des Benutzers konfiguriert wird (normalerweise
automatisch über DHCP- oder Relay-Agent-Optionen) mit den
Adressen des DNS-Proxys im Customer Premises Equipment
(CPE) konfiguriert wird, der wiederum auf die rekursiven DNS-Auflöser am
IAP VERWEIST. Die Angriffsfläche für drahtgebundene Angriffe reicht daher vom
dem Endbenutzersystem über das lokale Netzwerk und über das IAP
Netzwerk zu den rekursiven Resolvern des IAP.
Der rekursive Resolver kann ein öffentlicher DNS-Dienst sein (oder ein privater
(oder ein privat betriebener DNS-Auflöser, der im öffentlichen Internet gehostet wird). Einige Rechner
können so konfiguriert sein, dass sie öffentliche DNS-Auflöser verwenden, wie z. B. die
die von Google Public DNS oder OpenDNS betrieben werden. Der Benutzer hat möglicherweise
seinen Rechner für die Verwendung dieser rekursiven DNS-Auflöser konfiguriert
oder sein IAP hat sich für die Verwendung der öffentlichen DNS
Resolver zu verwenden, anstatt seine eigenen Resolver zu betreiben. In diesem
Fall ist die Angriffsfläche das gesamte öffentliche Internet zwischen der
der Verbindung des Benutzers und dem öffentlichen DNS-Dienst. Es ist zu beachten
dass, wenn der Benutzer einen einzigen Resolver mit einer kleinen Anzahl von Clients
Client-Population auswählt (selbst wenn er einen verschlüsselten Transport verwendet), kann dies
die Verfolgung des Benutzers bei der Bewegung durch verschiedene
Netzwerkumgebungen.

Es wird auch darauf hingewiesen, dass ein Gerät, das _nur_ mit einem
modernen Mobilfunknetz verbunden ist

direkt nur mit den rekursiven Auflösern des IAP konfiguriert ist
und
einen gewissen Schutz gegen einige Arten des Abhörens
Abhörmaßnahmen für den gesamten Datenverkehr (einschließlich DNS-Verkehr) aufgrund der
Verschlüsselung auf der Verbindungsebene des Mobilfunknetzes.

Die Angriffsfläche für dieses spezielle Szenario wird hier nicht betrachtet.

5.2. Verschlüsselte Transporte

Die Verwendung verschlüsselter Transporte mindert direkt die passive
Überwachung der DNS-Nutzdaten; dennoch sind einige Angriffe auf die
noch möglich. In diesem Abschnitt werden die verbleibenden Risiken für die Privatsphäre aufgezählt
für einen Endbenutzer, wenn ein Angreifer verschlüsselte DNS-Verkehrsströme auf der Leitung passiv überwachen
Verkehr auf der Leitung passiv überwachen kann.

Dies sind Fälle, in denen die Identifizierung von Benutzern, Fingerabdrücke oder
Korrelationen aufgrund der Verwendung bestimmter Transportschichten oder
Transportschichten oder Klartext/beobachtbare Merkmale möglich sind. Diese Probleme sind nicht
sind nicht spezifisch für DNS, aber DNS-Verkehr ist anfällig für diese Angriffe, wenn
wenn bestimmte Transporte verwendet werden.

Es gibt einige allgemeine Beispiele; so wird in einigen Studien hervorgehoben
dass die OS-Fingerprint-Werte (http://netres.ec/?b=11B99BD) von IPv4
TTL, IPv6 Hop Limit oder TCP Window size verwendet werden können, um Fingerabdrücke
Client-Betriebssysteme verwendet werden können oder dass verschiedene Techniken verwendet werden können, um DNS-Anfragen zu de-NAT
Abfragen [dns-de-nat].

Beachten Sie, dass selbst bei der Verwendung verschlüsselter Transporte die Verwendung von Klartext
Transportoptionen zur Verringerung der Latenz eine Korrelation der Verbindungen eines
Verbindungen eines Benutzers ermöglichen, z. B. mit TCP Fast Open [RFC7413].

Implementierungen, die verschlüsselte Transporte unterstützen, verwenden häufig auch
Verbindungen für mehrere DNS-Abfragen wieder, um die Leistung zu optimieren (z. B.,
über DNS-Pipelining oder HTTPS-Multiplexing). Die Standardkonfiguration
Optionen für verschlüsselte Transporte könnten im Prinzip einen Fingerabdruck einer
bestimmte Client-Anwendung identifizieren. Zum Beispiel:

Auswahl der TLS-Version oder Cipher-Suite
Wiederaufnahme von Sitzungen
die maximale Anzahl der zu sendenden Nachrichten und
eine maximale Verbindungszeit vor dem Schließen einer Verbindung und
Wiedereröffnung.

Wenn Bibliotheken oder Anwendungen eine Benutzerkonfiguration solcher Optionen anbieten
(z. B. [getdns]), dann könnten sie im Prinzip helfen, einen
bestimmten Benutzer zu identifizieren. Um dieses Problem zu vermeiden, sollten die Benutzer vielleicht nur die Standardeinstellungen verwenden.
Problem zu vermeiden.

Es gibt zwar bekannte Angriffe auf ältere Versionen von TLS, aber die neuesten
jüngsten Empfehlungen [RFC7525] und die Entwicklung von TLS 1.3
[RFC8446] entschärfen diese weitgehend.

Eine Verkehrsanalyse des ungepolsterten verschlüsselten Verkehrs ist ebenfalls möglich
[pitfalls-of-dns-encryption], da die Größe und der Zeitpunkt von
verschlüsselten DNS-Anfragen und -Antworten mit unverschlüsselten DNS-Anfragen korreliert werden können
DNS-Anfragen vor einem rekursiven Resolver korreliert werden können.

6. Risiken bei den Servern

Unter Verwendung der Terminologie von [RFC6973] sind die DNS-Server (rekursive
Resolver und autoritative Server) als „Enabler“: „Sie erleichtern
Kommunikation zwischen einem Initiator und einem Empfänger, ohne sich
direkt im Kommunikationspfad zu sein“. Infolgedessen werden sie oft
in der Risikoanalyse vergessen. Aber, um noch einmal [RFC6973] zu zitieren, „Obwohl
[…] Enabler im Allgemeinen nicht als Angreifer betrachtet werden, können sie
können sie alle eine Bedrohung für die Privatsphäre darstellen (je nach Kontext), da sie
in der Lage sind, datenschutzrelevante Daten zu beobachten, zu sammeln, zu verarbeiten und zu übertragen
Daten“. In der [RFC6973]-Sprache werden Befähiger zu Beobachtern, wenn sie
beginnen, Daten zu sammeln.

Es gibt viele Programme zum Sammeln und Analysieren von DNS-Daten auf den Servern —
vom „Query Log“ einiger Programme wie BIND über tcpdump bis hin zu
anspruchsvolleren Programmen wie PacketQ [packetq] und DNSmezzo
[dnsmezzo]. Die Organisation, die den DNS-Server verwaltet, kann diese
Daten selbst nutzen, oder sie kann Teil eines Überwachungsprogramms wie PRISM
[prism] sein und Daten an einen externen Beobachter weitergeben.

Manchmal werden diese Daten für lange Zeit aufbewahrt und/oder an
Dritte zu Forschungszwecken [ditl] [day-at-root], für Sicherheitsanalysen
Analysen oder Überwachungsaufgaben. Diese Verwendungen erfolgen manchmal im Rahmen einer Art
einer Art Vertrag mit verschiedenen Beschränkungen, zum Beispiel für
Weiterverbreitung, da es sich um sensible Daten handelt. Außerdem gibt es
gibt es Beobachtungspunkte im Netz, die DNS-Daten sammeln und sie dann
zu Forschungs- oder Sicherheitszwecken an Dritte weitergeben
(„passives DNS“ [passive-dns]).

6.1. Bei den rekursiven Resolvern

Rekursive Resolver sehen den gesamten Datenverkehr, da ihnen in der Regel kein
Caching vor ihnen gibt. Zusammengefasst: Ihr rekursiver Resolver weiß eine
viel über Sie. Der Resolver eines großen IAP, oder ein großer öffentlicher
Resolvers, kann Daten von vielen Benutzern sammeln.

6.1.1. Auswahl des Resolvers

In Anbetracht all dieser Überlegungen hat die Wahl des rekursiven Resolvers
unmittelbare Auswirkungen auf den Datenschutz der Endnutzer. In der Vergangenheit haben End
Endnutzergeräte den von DHCP bereitgestellten rekursiven Resolver für das lokale Netz
Auflöser. Die Entscheidung eines Benutzers, sich einem bestimmten Netz anzuschließen (z. B.,
durch physisches Einstecken eines Kabels oder Auswahl eines Netzwerks in einem OS
Dialog) aktualisiert in der Regel eine Reihe von Systemressourcen – dazu können
Dazu gehören IP-Adressen, die Verfügbarkeit von IPv4/IPv6, DHCP-Server und
DNS-Auflöser. Diese einzelnen Änderungen, einschließlich der Änderung des DNS
Resolver, werden dem Benutzer normalerweise nicht direkt vom Betriebssystem mitgeteilt
Betriebssystem dem Benutzer nicht direkt mitgeteilt, wenn das Netzwerk verbunden wird. Die Wahl des Netzwerks hat
die Auswahl des DNS-Auflösers für das Standardsystem bestimmt;
Die beiden sind in diesem Modell direkt miteinander verbunden.

Die große Mehrheit der Benutzer ändert ihre Standard-DNS-Einstellungen nicht
Einstellungen nicht und akzeptieren daher implizit die Netzwerkeinstellungen für das DNS.
Die Netzwerk-Resolver sind daher seit jeher das einzige
Ziel für alle DNS-Anfragen von einem Gerät. Diese
Resolver können je nach Netzwerk unterschiedliche Datenschutzrichtlinien haben.
Datenschutzrichtlinien für diese Server können verfügbar sein oder auch nicht, und
Benutzer müssen sich bewusst sein, dass die Datenschutzgarantien je nach
Netzwerk variieren.

Alle wichtigen Betriebssysteme legen die DNS-Systemeinstellungen offen und ermöglichen es den Benutzern
sie auf Wunsch manuell zu überschreiben.

In jüngerer Zeit haben sich einige Netze und Benutzer aktiv für die Verwendung eines
großen öffentlichen Resolver, z. B. Google Public DNS
(https://developers.google.com/speed/public-dns), Cloudflare
(https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/), oder
Quad9 (https://www.quad9.net). Dafür kann es viele Gründe geben: Kosten
Kostenerwägungen für Netzbetreiber, bessere Zuverlässigkeit oder Anti
Zensurüberlegungen sind nur einige davon. Solche Dienste bieten in der Regel
eine Datenschutzerklärung, und der Nutzer kann sich ein Bild von den Daten machen
über die von solchen Betreibern gesammelten Daten machen, indem er eine solche Erklärung liest, z. B. Google Public DNS –
Ihre Privatsphäre (https://developers.google.com/speed/public-dns/
Datenschutz).

Wie bei vielen anderen Protokollen gibt es auch bei DNS Probleme mit der
Zentralisierung auch bei DNS auf. Das Bild ist fließend und
mehreren konkurrierenden Faktoren, die auch je nach geografischer Region
je nach geografischer Region variieren können. Dazu gehören:

Auslagerung von ISP, auch an Dritte und öffentliche Resolver
regionale Marktbeherrschung durch einen oder nur wenige ISP
Anwendungen, die den DNS-Verkehr standardmäßig an eine begrenzte Gruppe von
von Resolvern leiten (siehe Abschnitt 6.1.1.2)

Ein größerer Anteil des weltweiten DNS-Auflösungsverkehrs, der von
Auflösungsverkehrs durch nur wenige Stellen bedeutet, dass die Datenschutzerwägungen
für die Nutzer in hohem Maße von den Datenschutzrichtlinien und -praktiken
dieser Entitäten abhängen. Viele der Probleme im Zusammenhang mit der Zentralisierung werden
in [centralisation-and-data-sovereignty] erörtert.

6.1.1.1. Dynamische Entdeckung von DoH und Strict DoT

Während die Unterstützung für opportunistisches DoT durch das Abfragen eines
Resolver auf Port 853 festgestellt werden kann, gibt es derzeit keinen standardisierten
Erkennungsmechanismus für DoH- und Strict DoT-Server.

Das bedeutet, dass Clients, die solche verschlüsselten Dienste dynamisch erkennen wollen
verschlüsselte Dienste dynamisch finden wollen, und wo die Benutzer bereit sind, solchen
Dienste zu vertrauen, nicht in der Lage sind, dies zu tun. Zum Zeitpunkt der Erstellung dieses Dokuments sind die Bemühungen
standardisierte Signalisierungsmechanismen zu schaffen, um die von lokalen
die von lokalen Resolvern angeboten werden, sind in Arbeit [DNSOP-RESOLVER]. Beachten Sie
dass eine wachsende Zahl von ISPs verschlüsselte DNS einsetzt; siehe
siehe beispielsweise die Encrypted DNS Deployment Initiative [EDDI].

6.1.1.2. Anwendungsspezifische Resolver-Auswahl

Eine wachsende Zahl von Anwendungen bietet anwendungs
spezifische Einstellungen für die verschlüsselte DNS-Auflösung an, anstatt standardmäßig
nur den Systemresolver zu verwenden. Eine Vielzahl von Heuristiken und
Resolver sind in verschiedenen Anwendungen verfügbar, einschließlich
kodierte Listen von erkannten DoH/DoT-Servern.

Im Allgemeinen sind den Benutzern die anwendungsspezifischen DNS-Einstellungen nicht bekannt
und haben möglicherweise keine Kontrolle über diese Einstellungen. Um diese
Benutzer nur dann Kenntnis von solchen Einstellungen haben und diese kontrollieren können
Kontrolle über diese Einstellungen haben, wenn die Anwendungen folgende
Funktionen bieten:

eindeutige Mitteilung der Änderung an die Benutzer, wenn der Standard
Anwendungsauflöser vom Systemauflöser abweicht
Bereitstellung von Konfigurationsoptionen zur Änderung des Standardauflösers der Anwendung
Auflöser zu ändern, einschließlich der Möglichkeit, immer den Systemauflöser zu verwenden
Bereitstellung von Mechanismen, mit denen Benutzer Abfragen lokal prüfen, selektiv
Weiterleitung und Filterung von Anfragen (entweder über die Anwendung selbst oder
Verwendung des Systemresolvers)

Anwendungsspezifische Änderungen der Standardziele für DNS-Anfragen der Benutzer
Abfragen können den Schutz der Privatsphäre des Benutzers erhöhen oder verringern; dies ist in hohem Maße
hängt stark vom Netzwerkkontext und der anwendungsspezifischen
Voreinstellung. Dies ist ein aktiver Diskussionspunkt, und die IETF arbeitet
an einer Reihe von Fragen im Zusammenhang mit anwendungsspezifischen DNS-Einstellungen.

6.1.2. Aktive Angriffe auf die Resolver-Konfiguration

Im vorigen Abschnitt wurde die DNS-Privatsphäre unter der Annahme erörtert, dass der gesamte
Datenverkehr zu den vorgesehenen Servern geleitet wird (d. h. zu denen, die
die in Abwesenheit eines aktiven Angriffs verwendet würden) und dass der potenzielle
Angreifer rein passiv war. In der Realität kann es jedoch aktive
Angreifer im Netz sein.

Das Internet-Bedrohungsmodell, wie in [RFC3552] beschrieben, geht davon aus, dass
der Angreifer das Netzwerk kontrolliert. Ein solcher Angreifer kann vollständig
jede unsichere DNS-Auflösung vollständig kontrollieren, indem er sowohl passiv die
Abfragen und Antworten überwachen und seine eigenen Antworten ersetzen. Selbst wenn
verschlüsseltes DNS wie DoH oder DoT verwendet wird, sofern der Client nicht
Identität des Servers konfiguriert wurde, kann ein aktiver Angreifer
Angreifer den Server als solchen ausgeben. Dies bedeutet, dass opportunistische
Modi von DoH/DoT sowie Modi, bei denen der Client den DoH/
DoT-Server über netzinterne Mechanismen wie DHCP erfährt, anfällig für
angreifbar. Wenn der Client kompromittiert ist, kann der Angreifer außerdem
die DNS-Konfiguration durch eine beliebige ersetzen.

6.1.3. Blockierung von DNS-Auflösungsdiensten

Die Privatsphäre der Benutzer kann auch gefährdet sein, wenn der Zugang zu folgenden Diensten blockiert wird
entfernten rekursiven Servern, die verschlüsselte Transporte anbieten, blockiert wird, z. B. wenn
der lokale Resolver keine Verschlüsselung anbietet und/oder sehr schlechte
Datenschutzrichtlinien hat. Beispielsweise könnte die aktive Sperrung von Port 853 für DoT
oder die Sperrung bestimmter IP-Adressen die dem Nutzer zur Verfügung stehenden Resolver
die dem Nutzer zur Verfügung stehen. Das Ausmaß des Risikos für die Privatsphäre des Nutzers ist
hängt stark vom jeweiligen Netz und vom Benutzerkontext ab; ein Benutzer in
einem Netz, von dem bekannt ist, dass es überwacht wird, wäre gefährdet
wäre gefährdet, wenn er nicht auf solche Dienste zugreifen könnte, während ein Benutzer in einem vertrauenswürdigen
vertrauenswürdigen Netzes kein Interesse an der Wahrung der Privatsphäre haben könnte.

Einige rekursive Resolver verwenden ihre Position im
im Abfragepfad, um selektiv den Zugang zu bestimmten DNS-Einträgen zu sperren.
Dies ist eine Form des rendezvousbasierten Blockierens, wie es in
Abschnitt 4.3 von [RFC7754] beschrieben. Solche Sperrlisten enthalten oft Server
von denen bekannt ist, dass sie für Malware, Bots oder andere Sicherheitsrisiken genutzt werden. Unter
Um die Umgehung ihrer Blockierungsrichtlinien zu verhindern, sperren einige
Netze auch den Zugang zu Resolvern mit inkompatiblen Richtlinien.

Es wird auch darauf hingewiesen, dass Angriffe auf entfernte Resolverdienste, z. B.,
DDoS, die Nutzer dazu zwingen könnten, auf andere Dienste auszuweichen, die keine
verschlüsselte Transporte für DNS anbieten.

6.1.4. Verschlüsselte Transporte und rekursive Resolver

6.1.4.1. DoT und DoH

Die Verwendung von verschlüsselten Transporten reduziert nicht die Daten, die im
rekursiven Resolver verfügbaren Daten nicht und kann ironischerweise sogar mehr
Informationen über die Benutzer an die Betreiber weitergeben. Wie in Abschnitt 5.2. beschrieben
kann die Verwendung von sitzungsbasierten verschlüsselten Transporten (TCP/TLS)
Korrelationsdaten über Benutzer aufdecken.

6.1.4.2. DoH-spezifische Erwägungen

DoH erbt die vollständigen Vertraulichkeitseigenschaften des HTTPS-Stacks und
Folglich ergeben sich neue Überlegungen zum Datenschutz im Vergleich zu
DNS über UDP, TCP oder TLS [RFC7858]. Abschnitt 8.2 von [RFC8484]
beschreibt die Überlegungen zum Datenschutz im Server des DoH
Protokolls.

Eine kurze Zusammenfassung einiger der Probleme umfasst das Folgende:

HTTPS stellt neue Überlegungen zur Korrelation an, wie z. B.
explizite HTTP-Cookies und implizites Fingerprinting der eindeutigen
Satz und Reihenfolge der HTTP-Anfrage-Header-Felder.
Die Header-Felder „User-Agent“ und „Accept-Language“ enthalten oft
übermitteln häufig spezifische Informationen über die Client-Version oder das Gebietsschema.
Durch die Nutzung aller HTTP-Funktionen ist DoH mehr als ein
mehr als ein HTTP-Tunnel zu sein, allerdings um den Preis der Öffnung der
Implementierungen für alle Datenschutzaspekte von HTTP zu öffnen.
Den Implementierungen wird empfohlen, den minimalen Satz von Daten offenzulegen
um den gewünschten Funktionsumfang zu erreichen.

In [RFC8484] wird die Wahl zwischen HTTPS-Funktionalität und
Privatsphäre eine Entscheidung der Implementierung. Im Extremfall kann es sein, dass
Implementierungen geben, die versuchen, aus Sicht des Datenschutzes die Gleichwertigkeit mit DoT zu
Gleichheit mit DoT aus Sicht des Datenschutzes zu erreichen, und zwar um den Preis, dass keine identifizierbaren HTTP
Header zu verwenden, und es könnte andere geben, die funktionsreiche Datenströme anbieten
Datenflüsse bieten, bei denen die Herkunft der DNS-Abfrage auf niedriger Ebene leicht
identifizierbar ist. Einige Implementierungen haben in der Tat beschlossen, die
die Verwendung des User-Agent-Headers zu beschränken, so dass Resolver-Betreiber nicht
die spezifische Anwendung, von der die DNS-Abfrage stammt, nicht identifizieren
Abfragen.

Benutzer, die Wert auf Datenschutz legen, sollten sich über das Potenzial für zusätzliche
Client-Identifikatoren in DoH im Vergleich zu DoT bewusst sein und sollten nur
DoH-Client-Implementierungen verwenden, die klare Hinweise darauf geben, welche
Identifikatoren sie hinzufügen.

6.2. In den autoritativen Namensservern

Anders als bei den rekursiven Resolvern sind die Beobachtungsmöglichkeiten
die Beobachtungsmöglichkeiten der autoritativen Nameserver durch das Caching begrenzt;
Sie sehen nur die Anfragen, für die sich die Antwort nicht im Cache befand.
Für aggregierte Statistiken („Wie hoch ist der Prozentsatz der LOC-Anfragen?“),
ist dies ausreichend, aber es verhindert, dass ein Beobachter alles sieht.
alles zu sehen. Ähnlich verhält es sich mit dem zunehmenden Einsatz von QNAME
Minimierung [ripe-qname-measurements] die Daten, die auf dem
der autoritativen Nameserver. Dennoch sehen die autoritativen Nameserver
einen Teil des Datenverkehrs, und diese Teilmenge kann ausreichend sein, um
um einige Erwartungen an die Privatsphäre zu verletzen.

Außerdem hat der Nutzer oft eine rechtliche/vertragliche Bindung an den
rekursiven Resolver (er hat den IAP gewählt, oder er hat sich für die
einen bestimmten öffentlichen Resolver zu verwenden), während er keine Kontrolle und vielleicht kein
über die Rolle der autoritativen Nameserver und deren
Beobachtungsmöglichkeiten.

Wie bereits erwähnt, verringert die Verwendung eines lokalen Resolvers oder eines Resolvers in der Nähe des
Rechner die Angriffsfläche für einen Abhörspezialisten.
Aber es kann die Privatsphäre gegenüber einem Beobachter auf einem
autoritativen Nameserver befindet. Dieser autoritative Nameserver sieht
die IP-Adresse des Endkunden und nicht die Adresse eines großen
rekursiven Resolvers, der von vielen Benutzern gemeinsam genutzt wird.

Dieser „Schutz“ ist bei der Verwendung eines großen Resolvers mit vielen Clients
nicht mehr gegeben, wenn ECS [RFC7871] verwendet wird, da in diesem Fall der
autoritative Nameserver die ursprüngliche IP-Adresse (oder das Präfix) sieht,
abhängig von der Konfiguration).

Gegenwärtig erhalten alle Instanzen eines Root-Nameservers, L-root,
zusammen etwa 50.000 Anfragen pro Sekunde. Während das meiste davon
„Müll“ ist (Fehler beim Namen der Top-Level-Domain (TLD)), gibt es einen
eine Vorstellung von der Menge an Big Data, die auf die Nameserver einströmen. (Und
(Und selbst „Müll“ kann Informationen preisgeben; wenn zum Beispiel ein Tippfehler
Tippfehler in der TLD, sendet der Nutzer Daten an eine TLD, die nicht die
üblichen.)

Viele Domänen, auch TLDs, werden teilweise von Servern Dritter gehostet
Servern gehostet, manchmal in einem anderen Land. Die Verträge zwischen dem
Domainverwalter und diesen Servern können den Datenschutz berücksichtigen oder auch nicht.
berücksichtigen. Wie auch immer der Vertrag aussieht, der Drittanbieter kann
in jedem Fall muss er sich an die lokalen Gesetze halten.
Zum Beispiel können Anfragen an eine bestimmte ccTLD an Server gehen, die von
Organisationen außerhalb des Landes, in dem die ccTLD registriert ist, verwaltet werden. Die Benutzer können
nicht vorhersehen, wenn sie eine Sicherheitsanalyse durchführen.

Außerdem scheint es (siehe die in [aeris-dns] beschriebene Umfrage), dass es
dass es eine starke Konzentration von autoritativen Nameservern unter
„beliebten“ Domänen (wie die Alexa Top N-Liste). Zum Beispiel,
unter den Alexa Top 100K (https://www.alexa.com/topsites), ein DNS
Anbieter heute 10 % der Domänen beherbergt. Die zehn wichtigsten DNS
Anbieter hosten zusammen ein Drittel aller Domains. Mit der Kontrolle
(oder der Fähigkeit, den Datenverkehr auszuschnüffeln) einiger weniger Nameserver kann man
eine Menge Informationen sammeln.

7. Andere Risiken

7.1. Re-Identifizierung und andere Rückschlüsse

Ein Beobachter hat nicht nur Zugang zu den Daten, die er direkt sammelt, sondern
sondern auch auf die Ergebnisse verschiedener Rückschlüsse auf diese Daten. Der Begriff
„Beobachter“ wird hier sehr allgemein verwendet; der Beobachter
passiv den DNS-Klartextverkehr beobachten oder sich in dem Netzwerk befinden
das den Benutzer aktiv angreift, indem es die DNS-Auflösung umleitet, oder
es kann sich um einen lokalen oder entfernten Resolver-Betreiber handeln.

Ein Benutzer kann zum Beispiel über DNS-Abfragen neu identifiziert werden. Wenn der
Identität eines Benutzers kennt und dessen DNS-Abfragen eine Zeit lang beobachten kann, kann
beobachten, kann derselbe Angreifer den Benutzer allein anhand seines
Nutzer allein aufgrund des Musters seiner DNS-Abfragen zu einem späteren Zeitpunkt
unabhängig von dem Ort, von dem aus der Benutzer diese Abfragen stellt. Für
eine Studie [herrmann-reidentification] heraus, dass eine solche Re
Identifizierung möglich ist, so dass „73,1 % aller täglichen Verbindungen
korrekt hergestellt wurden, d.h. der Benutzer u wurde entweder wieder identifiziert
eindeutig (1) oder der Klassifikator meldete korrekt, dass u am Tag t + 1 nicht mehr anwesend war
am Tag t + 1 nicht mehr anwesend war (2)“. Während sich diese Studie auf das Web
Web-Browsing-Verhalten bezog, können ebenso charakteristische Muster
auch in der Maschine-zu-Maschine-Kommunikation oder ohne dass ein Benutzer
ohne dass der Nutzer bestimmte Handlungen vornimmt, z. B. beim Neustart des Geräts, wenn eine Reihe
Dienste von dem Gerät aufgerufen werden.

Man könnte sich zum Beispiel vorstellen, dass ein Nachrichtendienst
Personen identifiziert, die eine Website besuchen, indem er einen sehr langen DNS-Namen eingibt
eingibt und nach Abfragen mit einer bestimmten Länge sucht. Eine solche Verkehrsanalyse
könnte einige Datenschutzlösungen schwächen.

Das IAB Privacy and Security Program hat auch ein Dokument [RFC7624]
das solche inferenzbasierten Angriffe in einem allgemeineren
Rahmen betrachtet.

7.2. Weitere Informationen

Nützliche Hintergrundinformationen finden sich auch in [tor-leak]
(in Bezug auf das Risiko von Lecks in der Privatsphäre durch DNS) und in ein paar
akademischen Arbeiten: [yanbin-tsudik], [castillo-garcia],
[fangming-hori-sakurai], und [federrath-fuchs-herrmann-piosecny].

8. Tatsächliche „Angriffe“

Eine sehr schnelle Untersuchung des DNS-Verkehrs kann zu dem falschen
Schlussfolgerung führen, dass es schwierig ist, die Nadel aus dem Heuhaufen zu ziehen.
„Interessante“ primäre DNS-Anfragen mischen sich mit (für den Lauscher) nutzlosen sekundären
(für den Lauscher) nutzlosen sekundären und tertiären Anfragen (siehe die Terminologie in
Abschnitt 1). Im Zeitalter der „Big Data“-Verarbeitung gibt es jedoch leistungsfähige
gibt es jetzt leistungsfähige Techniken, um von den Rohdaten zu dem zu gelangen, was den
Lauscher tatsächlich interessiert ist.

Viele Forschungsarbeiten über die Erkennung von Malware verwenden DNS-Datenverkehr, um
um „abnormales“ Verhalten zu erkennen, das auf die Aktivität von Malware
Malware auf infizierten Rechnern zurückführen lassen. Ja, diese Forschung wurde für das
dem Allgemeinwohl, aber technisch gesehen ist es ein Angriff auf die Privatsphäre und
und zeigt, wie mächtig die Beobachtung des DNS-Verkehrs ist. Siehe
[dns-footprint], [dagon-malware], und [darkreading-dns].

Passive DNS-Dienste [passive-dns] ermöglichen die Rekonstruktion der Daten
von manchmal einer ganzen Zone. Bekannte passive DNS-Dienste speichern
nur die DNS-Antworten und nicht die Quell-IP-Adresse des Clients,
und zwar aus Gründen des Datenschutzes. Andere passive DNS-Dienste sind möglicherweise nicht
nicht so sorgfältig. Und es gibt immer noch potenzielle Probleme mit der Offenlegung von
QNAMEs.

Die Enthüllungen aus den Edward-Snowden-Dokumenten, die der National Security Agency (NSA)
von der National Security Agency (NSA) durchgesickert sind, liefern Beweise für den Einsatz
des DNS bei Massenüberwachungsmaßnahmen [morecowbell]. Unter
Das MORECOWBELL-Überwachungsprogramm beispielsweise nutzt eine spezielle verdeckte
Überwachungsinfrastruktur, um aktiv DNS-Server abzufragen und
HTTP-Anfragen durchzuführen, um Metainformationen über Dienste zu erhalten und deren
ihre Verfügbarkeit zu prüfen. Auch das Programm QUANTUMTHEORY
(https://theintercept.com/document/2014/03/12/nsa-gchqs-
quantumtheory-hacking-tactics/), das die Erkennung von
Abfragen bestimmter Adressen und das Einschleusen gefälschter Antworten ist ein weiteres
gutes Beispiel dafür, dass der fehlende Schutz der Privatsphäre im DNS
aktiv ausgenutzt wird.

9. Rechtliche Aspekte

Unseres Wissens gibt es in keinem Land spezielle Datenschutzgesetze für DNS-Daten.
keinem Land. Die Auslegung allgemeiner Datenschutzgesetze, wie der
Union [Datenschutzrichtlinie] oder GDPR (https://gdpr.eu/tag/
gdpr/), im Zusammenhang mit DNS-Verkehrsdaten ist keine leichte Aufgabe, und
es gibt keinen bekannten Präzedenzfall. Siehe eine interessante Analyse in
[sidn-entrada].

10. Sicherheitsüberlegungen

In diesem Dokument geht es ausschließlich um die Sicherheit, genauer gesagt, um die Privatsphäre.
Es legt lediglich das Problem dar; es versucht nicht, Anforderungen festzulegen
(mit den damit verbundenen Entscheidungen und Kompromissen) festzulegen, geschweige denn
Lösungen. Mögliche Lösungen für die hier beschriebenen Probleme werden
werden in anderen Dokumenten erörtert (derzeit zu viele, um sie alle
zu erwähnen)

Verwendete [Referenzen] werden nicht direkt im Dokument verlinkt stehen aber natürlich öffentlich zur Verfügung: https://datatracker.ietf.org/

DNS Leak Test

Erstellt am: 16. Januar 2022