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

Ein nslookup liefert nichts zurück.

nslookup hi-bauprojekt.de
Server: srv
Address: 127.0.0.1
*** hi-bauprojekt.de wurde von srv nicht gefunden: Non-existent domain

Genau das gleiche passiert über Web DNS-Query Tools.

Mal abwarten ob der .de Namespace komplett zusammenbricht oder es einfach nur wieder funktioniert

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.

… und der Link im Profil.

Das Übliche. Sperren und Ignorieren.

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.

Domänenliste:
kernel.org
anb-networkz.de
anb-networkz.net
Die Software generiert daraus Absender und Zieladressen, je nach Konfiguration dynamisch. Dies sieht dann wie folgt aus:
info [at] kernel.org
info [at] anb-networkz.net
...
Anschließend versendet die Software die Nachrichten über einen offenen Mailserver (OpenRelay). Dieser versucht die Nachrichten dann an das Zielsystem zuzustellen. Normalerweise sind solche Spam-Server im Internet bekannt und werden in DNS Blacklisten (DNSBL) zusammengefasst. Das Zielsystem sollte nun anhand einer solchen DNSBL prüfen, ob der Quellserver gelistet ist und bei einem Treffer die Verbindung abweisen. Das grundlegende Problem bei dieser Technik ist, dass die Blacklisten niemals alle Server enthalten. Auch sind sie nicht Aktuell, da offene Server ja erst entdeckt und eingetragen werden müssen.
Um genau dies zu umgehen, gibt es SPF. Das Sender Policy Framework, kurz SPF funktioniert wie folgt:

1. Der Eigentümer einer Domain hinterlegt einen Eintrag im DNS, in welchem die Mailserver für diese Domäne Autorisiert werden.
2. Der empfangende Mailserver prüft mit einer DNS-Abfrage, ob ein SPF-Eintrag in der Domain des Absenders vorhanden ist.
3. Ist ein SPF vorhanden,kann der Empfangende Mailserver prüfen ob die IP des Sendenden Mailservers berechtigt ist, unter dieser Absender-Domain Nachrichten zu verschicken.
4. Ist der sendende Server nicht berechtigt, wird die Nachricht bereits bei der Annahme verworfen oder als “Risiko” eingestuft.
5. Ist kein SPF vorhanden oder der Mailserver berechtigt Nachrichten unter dieser Domäne zu verschicken, wird die Nachricht normal zugestellt.
6. Wurde die Nachricht Angenommen aber als Risiko eingestuft, können spätere Filter die Nachricht als Spam markieren.

Es ist mit dieser Technik nicht mehr möglich, Nachrichten unter dem Absender einer Domain über offene Relays an Server mit aktivierter SPF-Prüfung zu verschicken. Ein SPF Eintrag selbst kann im DNS als SPF oder TXT Record angelegt werden. Die meisten Provider bieten die Möglichkeit SPF-Einträge entweder auf Anfrage anzulegen oder bieten eine entsprechende Oberfläche zur Konfiguration.

Mehr dazu gibt es unter http://www.openspf.org

Details findet ihr hier:
http://www.isc.org/sw/bind/docs/Vulnerability_Discussion.pdf