Tag Archives: nameserver

DNS-Umleitung bei großen Providern – Zensur oder Zielgruppenwerbung?

Posted on by

Seit einiger Zeit leiten einige Provider DNS-Anfragen für nicht existente Domains auf ihre eigenen Suchportale um. Das witzige daran ist, wer nun versucht einen anderen DNS-Server einzutragen, wird (zum Beispiel) als Telekom-Kunde gezwungen auch deren Server zu verwenden. Wie das geht? Nun, der Provider kann einfach am Gateway alle Anfragen zu Port 53 an die eigenen DNS-Server umleiten. Nun ist es völlig egal welche Nameserver man auf seinem System konfiguriert. Für mich ist das der Anfang eines auf die Bedürfnisse des Providers zugeschnittenen Internets und hat nichts mehr mit freiem Zugang zu Medien zu tun. Diese Umleitung ist, etwas übertrieben gesprochen, der Anfang einer Zensur durch den Provider. Würde dieser hier, wie es zum Beispiel das OpenDNS Projekt anbietet, dem Nutzer ermöglichen selbst zu entscheiden, ob umgeleitet oder gesperrt weden soll, ließe sich hier ein Filter für besorgte Eltern, Schulen oder Firmen auf DNS-Basis einbauen. Unter gewissen Umständen ist die Sperrung bestimmter Seiten auch tatsächlich gerechtfertigt.

Aber nun zurück zur DNS-Umleitung. Normalerweise antworten DNS-Server, wenn ein DNS-Name nicht existiert, mit “NXDOMAIN”. Das steht für Non Existent Domain und sagt dem DNS-Client, diese Domain existiert nicht. Der Webbrowser zeigt hier eine Fehlermeldung “Server nicht gefunden” oder, wenn der Benutzer es wünscht, eine Suchseite wie Yahoo oder Bing an. Provider mit dieser Umleitung antworten hier mit den IP-Adressen des eigenen Suchportals, der Webbrowser öffnet mit der Anfrage “Gib mit startseite domain.de” eine Verbindung zu diesen IP-Adressen und verarbeitet die Antwort.

Das interessante daran ist, der Provider weiß dann, User Max Müller, aus Berlin hat am 01.01.2001 um 22:13 Uhr Domain xyz gesucht. Da der Provider ja auch über die Anschrift des Nutzers in seiner Datenbank verfügt, lassen sich aus den Protokollen des Suchseiten-Servers diverse Daten ableiten. Dies kann man nun dazu nutzen, Werbung für eine bestimmte Zielgruppen auf Basis der Kundendaten zu schalten. In der realen Welt würde das mit personenbezogener Werbung in Schaufenstern gleichkommen. Istdas nicht schön wenn man so an 20 Schaufenstern vorbeiläuft und jedes einzelne Hallo Herr xy, sie haben doch neulich … gesucht. Wir haben für Sie …. Mit einem rfid-Tag in Produkten und Leseschleifen vor dem Laden könnte der Ladenbesitzer aus der Kundendatenbank die Daten des Käufers laden und genau so etwas realisieren. Würde er allerdings so etwas machen, würden sich alle Datenschützer aufregen. Komischerweise darf es im Internet ohne Probleme so ablaufen.

Ob große Provider solche Methoden anwenden, ist nicht ganz klar. Um das zu prüfen, müssten möglichst viele Menschen unterschiedlicher Ziel-/Altersgruppen absichtlich exakt die gleichen falschen Domains eingeben und die Ausgabe der Providersuchseite auswerten. Sind hier Muster erkennbar, die auf Zielgruppenwerbung schließen lassen, verwendet der Provider auf jeden Fall Daten aus der Kundendatenbank für die Suchseiten. Ist die Suchseite allerdings bei jedem gleich oder ähnlich, würde das gegen eine solche Verwendung sprechen.

Wie kann man das aber verhindern? Nun, da alle Anfragen an Port 53 auf die DNS-Server des Anbieters umgeleitet werden, muss ein alternativer DNS-Server mit einem nicht Standard Port verwendet werden. Ein sehr guter Anlaufpunkt für genau diese Probleme ist die deutsche Privacy Foundation. Diese betreibt neben Tor Endpoints auch eigene, unmodifizierte Nameserver auf alternativen Ports.

Wie lange das allerdings noch klappt ist fraglich. Theoretisch könnte der Anbieter mit einem L7 Filter alle DNS-Anfragen umleiten. Hier hilft dann wirklich nur noch ein verschlüsselter Tunnel.

Weitere Links zum Thema:
Artikel bei Heise Netze
Artikel über Internetzensur des Chaos Computer Club

Bind9 DNS Server: Views

Posted on by

Views sind eine ganz praktische Sache, um bestimmte DNS-Zonen nur für einzelne Quell-Netze zur Verfügung zu stellen. So ist es möglich, auf ein und dem selben DNS-Server unkompliziert öffentliche und intern DNS-Zonen zu betreiben. Auch ist es ganz nützlich, um Kunden (die ja üblicherweise in einem Gast-Netz isoliert sind), Internetzugriff über einen Nameserver zu ermöglichen ohne die eigenen internen DNS-Zonen zu preiszugeben oder einen zweiten DNS-Server zu installieren.

Das ganze ist schnell eingerichtet. Zuerst benötigt man eine ACL in der die Clients definiert werden, für die dieser view verwendet werden soll. In meinem Beispiel sollen alle Clients aus dem Bereich 192.168.0.0/24 nur Einträge aus der Zone pub.anb-networkz.net auflösen können. Alle Clients aus 10.0.0.0/8 sollen priv.anb-networkz.net und pub.anb-networkz.net auflösen können. Die RR’s liegen in den Zonefiles pub.anb-networkz.zone und priv.anb-networkz.zone. Zusätzlich dürfen die Clients aus dem view “priv” keine Rekursiven Anfragen stellen. Nun erst einmal die relevanten Konfigurationsparameter:


# ACL fuer externe Benutzer (Gaeste)
acl "pub" { 192.168.0.0/24; };
# ACL fuer interne Benutzer, duerfen keine Internetadressen aufloesen
acl "priv" { 10.0.0.0/8; };
# Definition des Views fuer interne Benutzer
view "priv" {
match-clients { priv; }; # Trifft bei Anfragen von Intern
allow-query { priv; }; # Anfragen nur von Intern erlauben
allow-recursion { none; }; # Rekursion verbieten
# START Zonendefinition fuer interne Zone
zone "priv.anb-networkz.net" {
type master;
file "priv.anb-networkz.zone";
}
# ENDE Zonendefinition fuer interne Zone
};
# ENDE definition View fuer interne Benutzer
# START definition View fuer Gaeste
view "pub" {
match-clients { pub; }; # Triffe auf Clients der ACL pub
allow-query { pub; ]; # erlaube Anfragen von Clients der ACL pub
allow-query-cache {pub; }; # erlaubt Cache-Anfragen von Clients der ACL pub
allow-recursion { pub; }; # Erlaubt Rekursive Anfragen von Clients der ACL pub
# DNS-Zone fuer Gaeste
zone "pub.anb-networkz.net" {
type master;
file "pub.anb-networkz.zone;
}
# ENDE DNS-Zone fuer Gaeste
};
# ENDE definition View fuer Gaeste

Mit View bieten sicn nahezu unbegrenzte Möglichkeiten DNS-Server für mehrere Kunden oder Netze zu konfigurieren. Es ist problemlos möglich, Zonen mehrerer Kunden nur für die Netze dieser Kunden zugänglich zu machen aber dennoch nur einen Server zu verwenden. Vie Spaß beim ausprobieren.

Nameserver Probleme bei der Telekom?

Posted on by

Seit einigen Tagen musste ich feststellen, dass mein Internet-Anschluss extrem langsam reagiert. Zuerst dachte ich an ein lokales Problem mit meinem Router, DNS-Cache oder ähnlichem. Doch vermehrt habe ich diese Aussage auch von anderen bekommen. Seiten mit vielen externen Inhalten, also vielen DNS-Anfragen waren sind langsam. Gestern habe ich etwas mit Firestats gespielt und dafür eine neue Subdomain unter anb-networkz.net angelegt. Gestern hat alles sauber funktioniert und Anfragen waren einigermaßen schnell. Als ich heute Morgen  Firestats erneut aufrufen wollte, meldete mein Browser „Seite nicht gefunden“.  Daraufhin habe ich eine Konsole geöffnet und per nslookup versucht die Domain aufzulösen. Antwort des Servers „DNS request timed out“. Also nichts. Ein Webbasierendes nslookup über network-tools.com/nslook/ konnte die Domain jedoch problemlos auflösen. Also habe ich nun einige DNS-Server der Telekom direkt angesprochen, überall dasselbe Ergebnis. Entweder Timeout oder „Server failed“.

Hier einige Tests mit nslookup. Zwischen den tests lagen ca. 5 Minuten.
1. Versuch mit resolv-F (gescheitert)

> firestats.anb-networkz.net
Server: resolv-F.DTAG.DE
Address: 194.25.0.68
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an resolv-F.DTAG.DE

2. Versuch mit resolv-F (gescheitert)

> firestats.anb-networkz.net
Server: resolv-F.DTAG.DE
Address: 194.25.0.68
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an resolv-F.DTAG.DE

3. Versuch mit resolv-L (gescheitert)

> firestats.anb-networkz.net
Server: resolv-L.DTAG.DE
Address: 194.25.0.52
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an resolv-L.DTAG.DE

4. Versuch mit resolv-L (erfolgreich)

> firestats.anb-networkz.net
Server: resolv-L.DTAG.DE
Address: 194.25.0.52
Nicht autorisierte Antwort:
Name: firestats.anb-networkz.net
Address: 85.13.134.22

5. Versuch mit resolv-F (gescheitert)

> firestats.anb-networkz.net
Server: resolv-F.DTAG.DE
Address: 194.25.0.68
*** firestats.anb-networkz.net wurde von resolv-F.DTAG.DE nicht gefunden: Server
failed

6. Versuch erneut mit resolv-F (erfolgreich)

> firestats.anb-networkz.net
Server: resolv-F.DTAG.DE
Address: 194.25.0.68
Nicht autorisierte Antwort:
Name: firestats.anb-networkz.net
Address: 85.13.134.22

Wenn ein Nameserver eine Anfrage erst nach 3 Versuchen und 15 Minuten beantworten kann, liegt definitiv ein Problem vor. Bleibt abzuwarten ob wir jemals die Ursachen erfahren.