DNS-Technologien im Überblick

Das altehrwürdige Domain Name System ist seit mittlerweile fast vierzig Jahren einer der Grundpfeiler des Internets. Daneben erblicken neue Technologien rund um das DNS das Licht der Welt und entsprechende Unterstützung zieht in die Betriebssysteme ein.

Einleitung

Damit Pakete für das Internetprotokoll in Version 4 und 6 durch das Internet versendet werden können, sind Endpunkte, wie Clients und Server, mit Adressen versehen.

Über diese Adressen können die Dienste eines Servers abgerufen werden, so z. B. der Aufruf einer Webseite. Während IPv4-Adressen wie 192.168.15.15 noch übersichtlich scheinen, sieht es bei IPv6-Adressen wie der Adresse 2001:0db8:3c4d:0015:0000:1507:1503:1a2b anders aus.

Menschen sind nicht sonderlich gut darin, sich Zahlen zu merken, sodass eine andere Adressierung für die entsprechenden Endpunkte geschaffen werden musste. Gelöst wurde das Problem durch das Domain Name System, welches gerne als Telefonbuch des Internets bezeichnet wird.

Damit können Domains wie example.org auf eine entsprechende IP-Adresse abgebildet werden. Durch dieses Mapping vereinfacht sich die Nutzung und Adressierung im Internet.

Hierarchie im System

Wird eine Domain wie example.org aufgerufen, so wird ein DNS-Server abgefragt, der einem daraufhin den Domainnamen zu einer IP-Adresse auflöst.

Das gesamte Domain Name System ist hierarchisch aufgebaut. Auf der obersten Ebene befinden sich die autoritativen Nameserver für die Root-Zone. Diese sind dreizehn an der Zahl und tragen die Namen A bis M. Sie liefern die entsprechende Root-Zone aus, bei welcher es sich um einen knapp 2 MB großen Datenblob handelt.

In diesem enthalten ist eine Liste der autoritativen Nameserver für jede Top-Level-Domain. Damit verweist die Root-Zone auf DNS-Server, welche für einzelne Top-Level-Domains wie .de, .org oder .net zuständig sind.

Die Hierarchie im Domain Name System

Die Nameserver für die einzelnen Top-Level-Domains verweisen für eine angefragte Domain wiederum auf autoritative Nameserver, welche für diese Domain zuständig sind. In der Theorie kann diese Hierarchie mit jeder Ebene einer Domain, wie z. B. Subdomains, fortgesetzt werden.

Autoritative und cachende Nameserver

Besagte autoritative Nameserver sind dafür verantwortlich, verbindliche Aussagen zu einer Zone, wie einer Domäne oder einer ganzen Top-Level-Domain zu treffen. Was der autoritative Nameserver mitteilt, ist die objektive Wahrheit im Domain Name System.

Da es aus Gesichtspunkten wie der Lastverteilung und der Antwortgeschwindigkeit eher unpraktikabel ist, alle Anfragen zu einer bestimmten Zone nur von den autoritativen Nameservern beantwortet zu lassen, existieren cachende Nameserver.

Diese Nameserver, stehen z. B. beim Internet Service Provider und beantworten die DNS-Anfragen der Kunden. Kann eine solche DNS-Anfrage nicht aus dem Cache beantwortet werden, so wird wiederum der autoritative Nameserver angefragt und das Ergebnis für weitere Anfragen im Cache gehalten.

Nach Ablauf der Time to Live (TTL), welche in der Zone definiert ist, wird der Cache invalidiert und bei der nächsten Anfrage wieder der autoritative Nameserver befragt.

Zonen im Detail

In einer Zone können unterschiedlichste sogenannte Resource Records, kurz Records angelegt werden. Eine Zone, welche die entsprechende Konfiguration enthält, könnte wie folgt aussehen:

$ORIGIN example.org.
$TTL 3600
; SOA Records
@		IN	SOA	dns.example.org. 2022061900 86400 10800 3600000 3600
; NS Records
@		IN	NS	ns-1.example.org.
@		IN	NS	ns-2.example.org.
@		IN	NS	ns-3.example.org.
; MX Records
@		IN	MX	10 mail.example.org.
; A Records
@		IN	A	10.1.1.1
; AAAA Records
@		IN	AAAA	2001:db8:123:4567::1
; CNAME Records
api		IN	CNAME	www
www		IN	CNAME	example.org.

In der Zonen-Datei sind eine Reihe von Resource Record-Typen definiert, welche bestimmten Zwecken dienen. Von diesen Typen ist eine größere Anzahl definiert, von denen hier ein auszugsweiser Überblick gegeben werden soll.

A

Der A-Record definiert die IPv4-Adresse des Hosts. Mit diesem wird der Hostname schlussendlich der entsprechenden IPv4-Adresse zugeordnet.

AAAA

Wie beim A-Record ordnet auch der AAAA-Record dem Host eine IP-Adresse zu. In diesem Fall wird allerdings eine IPv6-Adresse zugeordnet.

CNAME

Bei CNAME handelt es sich um die Abkürzung für Canonical Name record. Mit diesem Record kann einer Domain ein weiterer Name zugeordnet werden. Dies kann genutzt werden, um Subdomains wie api.example.org anzulegen.

In einer beispielhaften Konfiguration würde dies dann wie folgt aussehen:

$ORIGIN example.org.
info    IN	CNAME	www
www		IN	A	192.168.1.1
www		IN	AAAA	2a01:4f8:262:5103::1

Hier wird die Subdomain info.example.org per CNAME auf die Subdomain www.example.org verwiesen, welche wiederum per A- und AAAA-Record auf die entsprechenden IP-Adressen des Hosts verweist.

MX

Der MX-Record ist ein wichtiger Record-Typ im Domain Name System, weil er dafür sorgt, dass E-Mails den entsprechenden Empfänger erreichen. Dazu definiert er den entsprechenden Mailserver, welcher für eine Domain zuständig ist:

; MX Records
@		IN	MX	10 mail.example.org.

Damit kann per DNS ermittelt werden, wie der Mailserver erreichbar ist und die entsprechende E-Mail zugestellt werden.

NS

Der NS-Record bzw. die NS-Records definieren die für die Domain zuständigen Nameserver. Bei einem bei Hetzner gehosteten Server, könnte das Ganze wie folgt aussehen:

; NS Records
@		IN	NS	helium.ns.hetzner.de.
@		IN	NS	hydrogen.ns.hetzner.com.
@		IN	NS	oxygen.ns.hetzner.com.

Die dort angegebenen Server sind die autoritativen Nameserver, da die entsprechenden Auskünfte, die diese Server erteilen, für die konfigurierte Domain verbindlich sind.

PTR

Ein PTR-Record, kurz für Pointer record, dient dazu, ein Reverse DNS Lookup zu ermöglichen. Das bedeutet, dass zu einer IP-Adresse der entsprechende DNS-Name ermittelt wird.

Wichtig ist diese Art der Konfiguration unter anderem bei der Bereitstellung von Mailservern.

SOA

SOA-Records, welche ein Kürzel für Start Of Authority darstellen, dienen der Darstellung bestimmter Informationen wie der primären Nameserver oder der Bereitstellung von Informationen, wie der TTL, für andere DNS-Server.

; SOA Records
@		IN	SOA	hydrogen.ns.hetzner.com. dns.hetzner.com. 2022121602 86400 10800 3600000 3600

TXT

Der TXT-Record ist ein relativ universeller Record im Domain Name System, mit welchem maschinenlesbare Daten im DNS hinterlegt werden können:

; TXT Records
@		IN	TXT	"v=spf1 redirect=example.org"

Genutzt wird diese Möglichkeit für unterschiedliche Techniken, wie im E-Mail-System mit DMARC oder dem Sender Policy Framework (SPF).

Probleme im Domain Name System

Das Domain Name System funktioniert in den Grundzügen, so wie es seit 1983 definiert wurde. Allerdings wirft diese Architektur auch einige Probleme auf.

In der klassischen DNS-Variante über UDP oder TCP, findet die komplette Kommunikation unverschlüsselt statt und stellt somit auch aus Sicht des Datenschutzes bzw. der Privatsphäre ein Problem dar.

Daneben sind die DNS-Responses nicht vor Änderungen geschützt und können somit ohne Wissen des Empfängers manipuliert werden.

Auch DDoS-Attacken in Form einer DNS Amplification Attack lassen sich bedingt durch die Gegebenheiten im Domain Name System durchführen. Hierbei wird die Zieladresse mit Datenverkehr von DNS-Servern belastet. Dies funktioniert, da der Angreifer eine DNS-Anfrage mit einer gefälschten IP-Adresse stellt und die Antwort somit beim eigentlichen Ziel der Attacke aufläuft. Der Angreifer benötigt in einem solchen Fall wenig Bandbreite, da die Antwort des DNS-Servers meist wesentlich größer ausfällt, als die Anfrage.

Ein weiteres Problem sind sogenannte Broken Resolvers. Dies ist insbesondere bei einigen Internet Service Providern der Fall, bei denen Dinge wie die TTL, also die Gültigkeit einer DNS-Antwort nicht berücksichtigt werden. Daneben existieren auch solche Resolver, die bei nicht vorhanden Domains nicht mit NXDOMAIN antworten, sondern stattdessen auf eine eigene Webseite umleiten.

Dieses Problem kann schon mit dem ursprünglichen Domain Name System verhindert, werden, indem alternative DNS-Server genutzt werden. Grundsätzlich erschweren solche Broken Resolvers die Fehlerfindung und beeinflussen die Funktionalität des Domain Name System.

Eine Fehlermeldung in Chrome, welche auf Probleme mit der DNS-Konfiguration hinweist

Interessant ist hier die Unterstützung durch Browser, wie Chrome, welcher bei Inkonsistenzen mit dem DNS-Server entsprechende Hinweise in Form einer spezifischen Fehlermeldung gibt.

Verbesserungen am System

Die Schwächen des Domain Name Systems sind nicht unberücksichtigt geblieben und so gab es im Laufe der Zeit immer wieder Verbesserungen, um das eine oder andere Problem zu beseitigen und das Domain Name System zu verbessern.

Dies fing schon in der Frühzeit des DNS an, als neben der ursprünglichen Möglichkeit per UDP Anfragen zu stellen, dies auch per TCP abgewickelt werden sollte. Hintergrund war es hier unter anderem DNS-Responses, welche größer als 512 Byte sind, versenden zu können.

Daneben wurde zur Erweiterung der DNS-Responses über UDP der Extension Mechanismus for DNS, kurz EDNS, definiert. Über diesen Mechanismus ist es möglich, mehr als 512 Byte per UDP zu übertragen. Genutzt wird dies unter anderem bei DNSSEC.

Bei der gewöhnlichen Nutzung wird in den meisten Fällen, aufgrund des geringeren Overheads, UDP genutzt. Nur in Fällen, in denen z. B. größere Datenmengen im Spiel sind, wird TCP genutzt.

TSIG und DNSSEC

Eine Sicherheitstechnologie in Bezug auf DNS ist TSIG, welches mit der RFC 2845 spezifiziert wurde. Das Kürzel steht für Transaction Signatures und ist ein Verfahren zur Absicherung von DNS-Updates z. B. bei dynamischem DNS.

Eine weitere Erweiterung des DNS sind die Domain Name System Security Extensions kurz DNSSEC. Mittels DNSSEC soll die Authentizität und Integrität von DNS-Daten gewährleistet werden.

Das bedeutet bei DNSSEC, dass die Übertragung selbst nicht verschlüsselt ist, sondern nur sichergestellt wird, dass die enthaltenden Daten korrekt und unverändert sind. Die Verbreitung von DNSSEC hat dabei in den vergangenen Jahren zugenommen.

Technologien für neue Anforderungen

Während Technologien wie DNSSEC und TSIG, bestimmte Anwendungszwecke im Auge haben, ist das Bewusstsein für Datenschutz und Privatsphäre im Laufe der letzten Jahre und Jahrzehnte gewachsen, sodass Lösungen entwickelt wurden, welche unverschlüsseltes DNS ersetzen oder ergänzen sollen.

Die neu entwickelten Protokolle und Technologien, welche in den vergangenen Jahren entwickelt wurden, hören auf so illustre Kürzel wie DoT, DoH oder DoQ.

Die unterschiedlichen DNS-Varianten im Laufe der Zeit

Interessant ist hier ein kurzer Rückblick auf die Geschichte des DNS-Protokolls. Als dieses ursprünglich zum Einsatz kam, setzte das Protokoll auf UDP auf, sodass die erste DNS-Version als DNS over UDP bezeichnet werden kann.

Mit der RFC 1123 aus dem Jahre 1989 wurde schließlich begonnen TCP für DNS-Anfragen zu nutzen, sodass DNS over TCP geboren war. Sowohl die UDP als auch die TCP Variante nutzen den Port 53.

DNS over TLS

DNS over TLS, kurz DoT, wurde im Mai 2016 im Rahmen der RFC 7858 standardisiert und wird genutzt, um DNS-Abfragen mittels TLS zu verschlüsseln. Es handelt sich hierbei nur um eine Transport- und um keine Ende-zu-Ende-Verschlüsselung.

DNS über TLS

Bei DoT wird zu dem DNS-Server eine Verbindung über TCP aufgebaut und diese mittels TLS abgesichert. Bedingt durch die Transportverschlüsselung können die DNS-Einträge nicht mehr zwischen den Knoten manipuliert werden. Der standardmäßig vorgesehene Port für DoT ist 853.

Wie auch bei DNS over HTTPS, werden bei dieser Variante DNS-Verstärkungsangriffe weitestgehend unterbunden.

Gegenüber unverschlüsseltem DNS erzeugt die Verschlüsslung per TLS einen gewissen Overhead, welcher sich auf die Geschwindigkeit der DNS-Anfrage auswirkt.

Im Gegensatz zu DNS über HTTPS soll diese Variante in der Praxis schneller sein. Allerdings gibt es je nach Implementierung unter Umständen Probleme, die meist von einem nicht korrekt implementierten Standard herrühren.

Bedingt durch den fest definierten Standardport für DoT (853), lässt sich dieses Protokoll relativ einfach blockieren. In einem solchen Fall kann auf andere DNS-Protokolle geschwenkt oder alternativ auf unverschlüsseltes DNS gesetzt werden.

DNS over HTTPS

Eine weitere Variante, welche ähnlich dem DNS over TLS funktioniert, ist DNS over HTTPS. Dieses wurde in der RFC 8484 standardisiert.

DNS über HTTPS

DoH läuft über den gleichen Port, wie gewöhnliches HTTPS, den Port 443. Damit kann von Außen keine Unterscheidung getroffen werden, ob es sich um DNS-Anfragen oder normalen HTTPS-Datenverkehr handeln.

Der Grund hierfür ist darin zu suchen, dass der Datenverkehr bzw. die Informationen der DNS-Abfrage über das Hypertext Transfer Protocol gesendet werden.

Damit wird eine Blockierung entsprechender DNS-Abfragen über dieses Verfahren erschwert. Allerdings leidet auch hier wieder die Performanz im Vergleich zu gewöhnlichem unverschlüsselten DNS.

Eine Spielart von DNS over HTTPS ist das relativ neue DNS-over-HTTP/3 kurz DoH3, welches wie HTTP/3 als Transportprotokoll QUIC anstatt von TCP nutzt. Dies darf allerdings nicht mit DNS over QUIC verwechselt werden.

DNS over QUIC

Zu den neueren Ideen bzw. Technologien bei der DNS-Abfrage gehört DNS over QUIC. Ziel von DoQ ist es, die Latenzen zu verringern, bei gleichzeitiger Nutzung einer verschlüsselten Verbindung.

DNS über QUIC

Definiert ist DoQ in der RFC 9250. Grundlage für das Protokoll ist QUIC, welches als Transportschicht TCP ersetzt und in dieser Form auch bei HTTP/3 genutzt wird.

Ziel von DoQ ist, dass dieses Protokoll auch für autoritative Nameserver verwendet werden kann. Damit soll eine möglichst breite Anzahl an Nutzungsmöglichkeiten im Zusammenhang, mit dem Domain Name System abgebildet werden können.

Da DoQ über den zugewiesenen Port 853 läuft, ist auch hier technisch gesehen eine einfache Blockierung möglich. Allerdings definiert die RFC hier im Abschnitt Port Selection:

In the stub to recursive scenario, the use of port 443 as a mutually agreed alternative port can be operationally beneficial, since port 443 is used by many services using QUIC and HTTP-3 and is thus less likely to be blocked than other ports

Unterstützung auf Serverseite

Damit DNS-Dienste, über welche Protokolle auch immer, im Internet genutzt werden können, muss die entsprechende Server-Software die gewünschten Protokolle unterstützen.

Neben BIND, dem Platzhirsch unter den DNS-Server, existieren noch weitere DNS-Server von denen bezüglich ihrer Fähigkeiten noch Unbound und der Windows Server kurz beleuchtet werden sollen.

DNS over TLS DNS over HTTPS DNS over QUIC
BIND ab Version 9.17 ab Version 9.17
Unbound ab Version 1.7.3 ab Version 1.12.0
Windows Server (DNS) ab Windows Server 2022

Bei BIND zogen mit der Version 9.17, welche im Jahr 2020 erschien, der Support für DoT und DoH (in einer experimentellen Version) ein. Eine Unterstützung für DNS over QUIC, steht im Moment noch aus.

Unbound liefert seit der im Juni 2018 erschienen Version 1.7.3 eine Unterstützung für DNS over TLS aus. Mit der im Oktober 2020 erschienen Version 1.12.0 wurde die Unterstützung für DNS over HTTPS implementiert. An der Umsetzung von DNS over QUIC in Unbound wird im Moment noch gearbeitet.

Ab dem Windows Server 2022 wird DNS over HTTPS offiziell unterstützt. Bei DNS over TLS und DNS over QUIC ist bisher keine Unterstützung im Windows Server vorhanden.

Linux

Neben der Unterstützung auf Serverseite ist auch die Unterstützung auf Client-Seite, in Form von Betriebssystemen auf dem Desktop, als auch im Bereich der mobilen Betriebssysteme wichtig.

In den meisten Linux-Distributionen, welche Systemd nutzen, kann dies über systemd-resolved erledigt werden. Dieser unterstützt ab der Version 239 opportunistisches DNS over TLS und ab der Version 243 striktes DNS over TLS.

Hier kann z. B. unter Ubuntu in der Konsole die entsprechende Konfigurationsdatei editiert werden:

nano /etc/systemd/resolved.conf

Dort sollte die Einstellung:

DNSOverTLS=yes

hinzugefügt werden. Anschließend können über den normalen Netzwerkdialog, DoT-fähige DNS-Server eingetragen werden:

9.9.9.9, 149.112.112.112

In diesem Fall sind es die DNS-Server von Quad9. Anschließend laufen die DNS-Abfragen per DoT über die gewählten DNS-Server.

macOS

Seit macOS 11, welches mit dem Namen Big Sur auf den Markt kam, unterstützt macOS neben DNS over TLS auch DNS over HTTPS.

Aktiviert werden können die gewünschten Einstellungen über Konfigurationsprofile. Dazu muss ein entsprechendes Profil heruntergeladen und anschließend installiert werden.

Das Profil unter macOS

Die Konfigurationsprofile befinden sich in den Systemeinstellungen unter macOS. Nach der Aktivierung kann über das Terminal überprüft werden, ob die entsprechenden Einstellungen aktiv sind:

sudo tcpdump -i any "port 853 and host 9.9.9.9 or host 149.112.112.112"

Bei der Nutzung von DoH sollte der Port im Befehl auf 443 geändert werden. Nachdem der Befehl abgesetzt wurde, sollte Netzwerkverkehr zu dem Quad9-DNS-Server im Dump auftauchen.

Windows

Unter Windows 10 wird, seit dem Build 19628, DNS over HTTPS unterstützt. Dazu muss in der Registry der Pfad:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

aufgerufen werden und dort ein Parameter vom Typ DWORD erstellt werden. Dieser trägt den Namen EnableAutoDoh sowie den Wert 2. Anschließend sollte ein Neustart des Rechners durchgeführt werden.

Die Einstellungen im Registrierungs-Editor

Nun können in den Einstellungen für den jeweiligen Netzwerkadapter die passenden DNS-Server mit einer entsprechenden Unterstützung für DoH eingestellt werden:

9.9.9.9, 149.112.112.112

Unter Windows 11 können die Einstellungen für DoH bequem über die Netzwerkeinstellungen eingestellt werden, nachdem dort die passenden DNS-Server hinterlegt sind, kann dort unter DNS over HTTPS das Feature aktiviert werden.

Neben DoH unterstützt Windows 11 auch DNS over TLS. Dazu werden in den Netzwerkeinstellungen die entsprechenden DNS-Server hinterlegt und das DNS over HTTPS-Feature deaktiviert.

Nun muss die Kommandozeile geöffnet werden und dort müssen die Befehle:

netsh dns add global dot=yes​
netsh dns add encryption server=9.9.9.9 dothost=: autoupgrade=yes
netsh dns add encryption server=149.112.112.112 dothost=: autoupgrade=yes

eingegeben werden. Das Kommando:

netsh dns add encryption

muss hierbei für jeden DNS-Server für die IPv4- und IPv6-Adresse wiederholt werden. Abgeschlossen wird das Prozedere mittels:

ipconfig /flushdns
netsh dns show global

Der letztere Befehl zeigt an, ob die Einstellungen für DNS over TLS aktiviert wurden. DNS over QUIC wird unter Windows vom System selbst bisher noch nicht unterstützt.

Android

Während seit Android 9 (Pie) DNS over TLS bereits verfügbar ist, ist DNS over HTTPS ab Android 11 enthalten und teilweise auch auf einigen Geräten mit Android 10 verfügbar.

Die teilweise Verfügbarkeit unter Android 10 erklärt sich dadurch, dass das entsprechende DNS Resolver Modul unter Android 10 noch optional, aber unter Android 11 verpflichtend zum System dazu gehört. Installiert werden diese Änderungen über ein Google Play-Systemupdate.

In den Einstellungen kann DoT bzw. DoH aktiviert werden

Zur Aktivierung unter Android genügt es in den Systemeinstellungen, die Netzwerkeinstellungen aufzurufen und dort im Punkt Privates DNS, die entsprechenden DNS-Server zu hinterlegen. Hierbei wird, je nach Android-Version, DNS over HTTPS (in der Variante DoH3) gegenüber DNS over TLS bevorzugt, zumindest bei den dem System bekannten DNS-Servern.

iOS

Seit iOS 14, also knapp 2 Jahre später als unter Android, zog in iOS die Unterstützung für DNS over TLS ein. Ebenfalls ab iOS 14 wird DNS over HTTPS unterstützt.

Wie unter macOS, kann die Einstellung über entsprechende Konfigurationsprofile vorgenommen werden. Dazu muss ein Profil auf dem iOS-Gerät heruntergeladen und installiert werden.

Die Installation des Profils erfolgt über die Einstellungen unter iOS

Nachdem das Profil bestätigt und installiert worden ist, wird der DNS-Server in der im Profil hinterlegten Konfiguration genutzt.

Unter iOS existiert die Besonderheit, dass DNS-Abfragen für den Appstore und die Terminalbefehle dig und nslookup per Design nicht über die im Profil hinterlegten DNS-Server abgefragt werden.

Das Profil kommt nicht immer zur Anwendung

Auch gelten die Einstellungen nicht, wenn z. B. iCloud Privat Relay oder eine VPN-Verbindung aktiv sind.

Browser

Neben der betriebssystemseitigen Unterstützung liefern auch die meisten Browser mittlerweile eine Unterstützung für DNS over HTTPS aus. Diese Unterstützung ist unabhängig vom darunterliegenden Betriebssystem.

Die Einstellungen für DNS over HTTPS im Firefox

Im Firefox kann DNS over HTTPS in den Einstellungen unter Allgemein und dort in den Verbindungs-Einstellungen aktiviert werden. Dort kann dann der Punkt DNS über HTTPS aktiviert mitsamt eines Servers ausgewählt werden.

Die Einstellungen zu DoH unter Chrome

Unter Chrome kann DoH über die Einstellungen unter dem Punkt Datenschutz und Sicherheit aktiviert werden. Dort findet sich unter dem Unterpunkt Sicherheit der Punkt Sicheres DNS verwenden.

Router

Auch Router bieten in vielen Fällen Funktionalitäten zur besseren Absicherung von DNS-Abfragen.

So können in der FRITZ!Box entsprechende DNS-Server, welche DoT unterstützen hinterlegt werden. Auf Wunsch kann die FRITZ!Box auch einen Fallback auf unverschlüsseltes DNS durchführen, falls die entsprechenden DoT-Server nicht erreicht werden können. Dies kann zum Beispiel durch entsprechende Firewalls oder beim technischen Ausfall der Server passieren.

Andere Verfahren

Neben den oben beschriebenen Varianten existieren noch weitere DNS-Varianten wie Oblivious DNS bzw. Oblivious DoH, DNS over TOR und DNSCrypt, welche allerdings im weiträumigen Praxiseinsatz eher seltener zu finden sind.

Nachteile der neuen Lösungen

Bei den neuen Lösungen, wie DoT, DoH und DNS over QUIC, existieren eine Reihe von Problemen bzw. Kritikpunkten.

Viele beziehen sich dabei auf gewünschte Eigenschaften der Verfahren, wie die Verschlüsselung, welche es unter anderem erschwert, den DNS-Verkehr zu überwachen. Genutzt wird eine solche Überwachung z. B. in Kinderschutzsoftware, oder im geschäftlichen Umfeld, um den Netzwerkverkehr zu überwachen und entsprechende Policen durchzusetzen.

Je nach Lösung wird dann versucht, die neueren Verfahren zu deaktivieren bzw. dessen Nutzung nicht zuzulassen oder aber eigene Server für die entsprechenden Protokolle zu betreiben, welche wiederum die entsprechen Sperrmöglichkeiten anbieten.

Auch sind die, bei den Verfahren wie DoT oder DoH genutzten, meist zentralen DNS-Server von Google, Cloudflare oder Quad9 ein Problem, da sich dort ein Großteil des DNS-Verkehrs sammelt und dies Begehrlichkeiten wecken oder der Profilbildung dienen kann.

Daneben sollte beachtet werden, dass je nach Implementation bzw. Betriebssystem die Nutzung der verschlüsselten DNS-Varianten nicht immer garantiert ist. Sei es durch ungewollte Downgrades auf unverschlüsseltes DNS oder aber Applikationen wie der Appstore unter iOS, welcher von den DNS-Einstellungen des Systems unabhängig funktioniert. Daneben gibt es in bestimmten Versionen von Android den Fall, dass die Private-DNS-Einstellungen nach dem Aufwachen des Gerätes erst wieder nach einigen Sekunden angewendet werden.

Fazit

DNS-Abfragen müssen heute nicht mehr unverschlüsselt erfolgen, da es eine Reihe von neuen Ideen und Transportprotokollen gibt, welche neben der jeweiligen Vorteile teilweise auch spezifische Nachteile haben.

Mittlerweile findet sich für die Verfahren DNS over TLS und DNS over HTTPS eine breitere Unterstützung in den Betriebssystemen. Dort, wo diese noch nicht verfügbar ist, kann auf DNS-Proxies oder im Spezialfall Browser auf dessen Möglichkeiten zurückgegriffen werden.

DNS over TLS DNS over HTTPS DNS over QUIC
Linux über systemd-resolved (ab Version 239 bzw. 243)
macOS ab macOS 11 (Big Sur) ab macOS 11 (Big Sur)
Windows ab Windows 11 (Build 25158) ab Windows 10 (Build 19628), Windows 11
Android ab Android 9 (Pie) ab Android 11
iOS ab iOS 14 ab iOS 14

Neben der gewöhnlichen DNS Auflösung haben aktuell vorwiegend die Technologien DoT und DoH eine größere Verbreitung erlangt. Spannend wird in Zukunft auch die Entwicklung von DoQ, welches zumindest das Potenzial hat, bestehende Technologien rundum DNS-Abfragen abzulösen.

Allerdings stellt sich bei vielen dieser Protokolle die Frage, welchen DNS-Servern vertraut werden soll, denn das bestehende DNS-System ist ein dezentrales System ohne übermächtige Gatekeeper, während bei Diensten wie DoT und DoH eine Zentralisierung zu beobachten ist.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Kommunikation von A nach B

Im Internet existieren eine Reihe von Diensten und Applikationen. Eine der wichtigsten Dienste, wenn nicht die Killerapplikation des Internets als es noch das ARPANET war, ist E-Mail. Zeit, ein wenig auf die Hintergründe dieses Systems zu blicken.

Einleitung

Zur Kommunikation existieren unterschiedlichste Dienste, welche das Internet nutzen, um Nachrichten von A nach B zu übermitteln. So sind im privaten Umfeld Messenger wie WhatsApp und Co nicht mehr wegzudenken. Daneben ist einer der wichtigsten Dienste für die Kommunikation die klassische E-Mail.

Der durchschnittliche Nutzer wird meist ein E-Mail-Programm auf dem Rechner, dem Mobilgerät oder ein Web-Mailer im Browser nutzen. Für den Nutzer ist es nicht wichtig wie das System funktioniert, allerdings lohnt es sich einen Blick hinter die Kulissen zu werfen und zu sehen, wie das System funktioniert und welche Herausforderungen der Betrieb eines E-Mail-Servers in der heutigen Zeit mit sich bringt.

Geschichte

Die Idee Nachrichten von A nach B zu verschicken gab es schon in der Frühzeit der Computertechnik, sogar noch früher, wenn elektrische Telegrafen einbezogen werden. So gab es ab dem Jahr 1962 mit dem Automatic Digital Network des US-Militärs bereits ein System, um Nachrichten an unterschiedlichste Standorte zu verteilen.

1968, mit der Erfindung des ARPANET, einem Forschungsprojekt im Auftrag des US-Militärs, wurden nicht nur die Grundlagen für unsere heutige Internetarchitektur geschaffen, sondern einige Jahre später, im Jahr 1971, die erste E-Mail versendet. Wobei hier der Terminus Network Mail genutzt wurde.

Für den Transfer der E-Mail wurde das Programm SNDMSG genutzt, welches es ermöglichte Nachrichten bzw. E-Mails von einem Nutzer zu einem anderen Nutzer auf dem gleichen System zu schicken.

Technisch war eine Mailbox nicht mehr als eine Datei, welche nur vom berechtigten Nutzer gelesen werden konnte, aber von unterschiedlichen Nutzern über SNDMSG geschrieben werden konnte.

Die Neuerung war nun die Idee, SNDMSG so zu erweitern, dass es E-Mails auch zu anderen Hosts senden konnte. Dafür wurde das At-Zeichen als Trennzeichen gewählt, um den eigentlichen Nutzer vom entsprechenden Host zu trennen. Daneben wurde READMAIL zum Lesen der Mails genutzt. Beide Programme, SNDMSG und READMAIL, wurden damals mit dem Betriebssystem TENEX genutzt.

Parallel zur ARPANET-Implementation und Vorstellung von Network Mail entstanden im Laufe der Zeit einige kommerzielle E-Mail-Systeme, sowie der X.400-Standard, welche bereitstanden, die Vorherrschaft der E-Mail-Systeme anzunehmen.

Bedingt durch die Öffnung des Internets gegenüber der kommerziellen Nutzung, genauer gesagt der Aufhebung der Restriktionen im Jahr 1995, mauserten sich SMTP, POP3 und IMAP zu den vorherrschenden Protokollen für das Senden und Abfragen von E-Mails.

Vorher war die kommerzielle Nutzung der damals im Rahmen des National Science Foundation Network-Programmes bereitgestellten Netzwerke durch entsprechende Richtlinien stark eingeschränkt. Grundsätzliche sollten diese Netzwerke hauptsächlich der Forschung und Lehre genutzt werden.

Auch wenn es heutzutage noch einige Bereiche gibt, in denen andere Standards genutzt werden, wie der X.400-Standard bei der Rufnummernportierung, hat sich der aktuelle E-Mail-Standard durchgesetzt.

Damit die Systeme trotzdem miteinander verbunden sein können, gab und gibt es unterschiedlichste Gateways, welche andere Netzwerke und E-Mail-Systeme miteinander verbinden.

Trennzeichen gesucht

Die Idee Nachrichten über Rechnergrenzen hinweg zu versenden führte zu dem Problem, dass diese Rechner adressiert werden müssen. Als Trennzeichen wurde das At-Zeichen (@) gewählt, welches nicht nur von der Bedeutung ideal war, sondern auch das Zeichen als solches war größtenteils ungenutzt. Damit war der Weg zu Adressen nach dem Schema nutzer@host frei.

Auf heutigen Tastaturen ist das At-Zeichen selbstverständlich

Bei der Auswahl des Zeichens war das Kriterium, dass das Zeichen auf den damaligen Tastaturen vorhanden war, aber auf keinen Fall ein Bestandteil eines Namens sein dürfte.

Der Erfinder der E-Mail, Ray Tomlinson sagte dazu selbst:

The primary reason was that it made sense. at signs didn’t appear in names so there would be no ambiguity about where the separation between login name and host name occurred. (Of course, this last notion is now refuted by the proliferation of products, services, slogans, etc. incorporating the at sign.) The at sign also had no significance in any editors that ran on TENEX. I was later reminded that the Multics time-sharing system used the at sign as its line-erase character. This caused a fair amount of grief in that community of users. Multics used IBM 2741 terminals which used EBCDIC character coding. They did not have a „control“ modifier key and didn’t have many (any?) non-printing characters beyond space, backspace, tab, and return. The designers of Multics were constrained to using printing characters for line-editing.

Während das Zeichen zuvor hauptsächlich zur Trennung von Mengen und Preisen genutzt wurde, hielt das Zeichen damit Stück für Stück Einzug in die moderne Welt und wurde praktisch zu einem unverkennbaren Zeichen der vernetzten Welt.

E-Mail, email, Mail?

Neben der eigentlichen Technik hinter dem E-Mail-System wurden im Laufe der Zeit auch andere Dinge, wie die Terminologie und Schreibweise, verhandelt. Während die Schreibweise im Deutschen als E-Mail definiert ist, sind im englischen Formen wie email, e-mail, E-mail, EMAIL und weitere Schreibweisen bekannt. Gebräuchlich ist hier meist die Schreibweise email bzw. e-mail. Bei RFCs hingegen wird im Author’s Adressblock die historisch bedingte Form EMail genutzt.

Dezentral wie das Netz

Das E-Mail-System an sich ist als dezentrales System für asynchrone Kommunikation konzipiert.

Das bedeutet, dass es nicht ein großer Betreiber existiert, welcher für alle E-Mail-Adressen der Welt zuständig ist. In der Theorie kann jeder Nutzer eines Rechners, welcher mit dem Internet verbunden ist, einen solchen E-Mail-Server betreiben.

Die Asynchronität definiert unter anderem dadurch, dass E-Mails abgeschickt werden können, ohne dass der Mail-Server des Empfängers erreichbar sein muss.

Systeme mit drei Buchstaben

Wer sich näher mit dem E-Mail-System auseinandersetzt, wird feststellen, dass es den E-Mail-Server an sich nicht gibt, sondern es sich um eine Ansammlung von Systemen, Diensten oder Programmen handelt.

Diese tragen überwiegend Abkürzungen bestehend aus drei Buchstaben wie MUA, MSA, MTA und MDA. Ordnung lässt sich in die Begriffe bringen, wenn der Weg einer E-Mail vom Sender zum Empfänger verfolgt wird.

Grundsätzlich geht es darum, eine E-Mail bzw. eine Nachricht von einem Rechner zu einem anderen Rechner zu transferieren und sie dort in der Mailbox des entsprechenden Nutzers zu hinterlegen.

Eine E-Mail wird in einem E-Mail-Client geschrieben

Wird eine E-Mail geschrieben, so geschieht das in einem E-Mail-Client, welcher im Kontext der Architektur des E-Mail-Systems als Mail User Agent (MUA) bezeichnet wird.

Manchmal wird das Wort Mail in den entsprechenden Begrifflichkeiten durch Message ersetzt. Je nach RFC findet sich eine unterschiedliche Terminologie in dieser. Die Begriffe werden dabei synonym verwendet. So bezeichnen beispielhaft Mail User Agent und Message User Agent das Gleiche.

Nachdem die Mail fertig geschrieben und ein Empfänger eingetragen wurde, kann die E-Mail versandt werden. Je nach Konfiguration sind hier unterschiedliche Wege denkbar.

Vom MUA zum MSA

So kann die entsprechende Mail per Simple Mail Protocol (SMTP) an den sogenannten Mail Submission Agent (MSA) gesendet werden. Gewöhnlich geschieht dies über den Port 587. Die Idee hinter dem Mail Submission Agent ist, dass dieser die E-Mails vom Endbenutzer entgegennimmt und diese an den Mail Transfer Agent (MTA) weiterleitet.

Damit stellt er in der Theorie die Schnittstelle zwischen dem Mail User Agent und dem Mail Transfer Agent dar. Im Gegensatz zum Mail Transfer Agent darf der Mail Submission Agent die eingelieferte E-Mail noch bearbeiten. So kann das E-Mail-Format überprüft und gegebenenfalls repariert sowie unvollständige E-Mail-Adressen vervollständigt werden. Dies ist z. B. dann der Fall, wenn die Domain des Absenders nicht voll qualifiziert angegeben wurde.

In der Theorie kann ein Mail User Agent ergo das E-Mail-Programm E-Mails auch direkt an einen Mail Transfer Agent senden. Allerdings nimmt dieser keine der obigen Prüfungen vor.

Mail Transfer Agent

Nachdem die E-Mail an den Mail Transfer Agent weitergeleitet wurde, entscheidet dieser, was mit der E-Mail geschieht. Im Grunde ist der MTA ist dafür zuständig, die E-Mail zum Ziel zu transportieren und die Nachricht schlussendlich an den Mail Delivery Agent (MDA) zu übergeben.

Eine Möglichkeit wie eine E-Mail zum Empfänger übertragen wird

Der Mail Transfer Agent führt in seiner Konfiguration eine Liste von Domains bzw. Hosts, für die er lokal zuständig ist. E-Mails, welche zu diesen Domains führen, werden direkt über den Mail Delivery Agent zugestellt.

Der MTA verändert die Mail beim Transfer im Grundsatz nicht, außer dass einige Headerfelder wie Received oder Return-Path, welche laut der entsprechenden RFC benötigt werden, hinzugefügt werden.

In der Frühzeit des E-Mail-Systems waren die meisten MTAs als sogenannte offene Relays (Open Relays) konfiguriert. Das bedeutete, dass sie von beliebigen Clients entsprechende E-Mails entgegennahmen und weiterleiten.

Diese Funktionalität konnte z. B. von Systemen genutzt werden, welche nur sporadisch am Netz waren und somit ihre E-Mail an ein Relay weiterleiten konnten, welches sich anschließend um die Zustellung kümmerte.

Dies führte schlussendlich zum Problem des Spams, da diese Relays missbraucht wurden, um Empfänger mit unerwünschten Mails zu belästigen. Infolgedessen finden sich heutzutage nur noch wenige offene Relays im Internet. Meist handelt es sich dabei um Fehlkonfigurationen. Ein MTA sollte in der heutigen Zeit nur nach einer entsprechenden Authentifizierung E-Mails entgegennehmen.

Auf Linux-Systemen wird gerne Postfix für diesen Teil des E-Mail-Systems genutzt. Je nach Konfiguration kann Postfix hier sowohl als MSA als auch als MTA verwendet werden.

Von MTA zu MTA

Ist die Empfänger-Domain nicht im Einflussbereich des Absender-MTAs, so wird die Mail an den zuständigen MTA gesendet.

Hierzu wird die Domain per DNS aufgelöst und es werden die entsprechenden MX-Records ausgewertet. In diesen sind die für die Domain zuständigen Mail Transfer Agents hinterlegt.

Ein solcher MX-Record könnte wie folgt aussehen:

	@		IN	MX	10 mail.example.org.

Es können pro Domain mehrere MX-Records angelegt werden. Der MTA, versucht diese nun nacheinander, sortiert nach ihrer Priorität, zu erreichen und die entsprechende E-Mail auf dem MTA der Empfänger-Domain einzuliefern.

Kann die E-Mail nach einer gewissen Zeit nicht eingeliefert werden oder erhält der MTA eine entsprechende Fehlermeldung, wird der ursprüngliche Absender der E-Mail informiert, damit dieser darauf reagieren kann.

Ist die Einlieferung der E-Mail hingegen erfolgreich gewesen, leitet der MTA der Empfänger-Domain die Mail an den Mail Delivery Agent weiter. Der MDA hat die Aufgabe, die E-Mails an die jeweiligen Nutzerkonten bzw. Mailboxen weiterzuleiten.

Beispiele für einen solchen MDA ist die Software Dovecot unter Linux. Daneben bietet Dovecot die Funktionalität mittels der Protokolle IMAP und POP3 auf die Mails der jeweiligen Nutzer über ein Netzwerk zuzugreifen.

Über diesen Weg können die E-Mails von den Nutzern vom Server geladen und gelesen werden. Damit landen die E-Mails beim Nutzer im Mail User Agent, dem E-Mail-Programm auf dem Endgerät des Empfängers.

Mailboxen

Die Mailboxen der Nutzer können auf dem Server in unterschiedlichen Formaten gespeichert werden. Die bekanntesten und am häufigsten genutzten Formate sind Maildir und Mbox.

Beim Speicherverfahren Maildir wird jede Mail in einer separaten Datei, innerhalb der durch Maildir festgelegten Verzeichnisstruktur, abgelegt. Beim Verfahren Mbox hingegen, befinden sich die Mails in einer großen Datei und werden in dieser Datei nacheinander gespeichert.

Anatomie einer E-Mail

Damit ist geklärt, wie eine Mail ihren Weg vom Absender zum Empfänger findet. Doch wie sieht eine solche E-Mail eigentlich aus? Dies definiert die RFC 5322. Eine simple E-Mail, gemäß der RFC, könnte wie folgt aussehen:

Return-Path: <>
Delivered-To: 
Received: by mail.example.org (Postfix, from userid 33)
        id 81FC87EE09FD; Sat,  1 Jan 2022 00:19:10 +0100 (CET)
From:  (Cron Daemon)
To: 
Subject: Update cronjob successfully
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env: 
X-Cron-Env: 
X-Cron-Env: 
X-Cron-Env: 
Message-Id: <>
Date: Sat,  1 Jan 2022 00:19:10 +0100 (CET)

Update cronjob successfully executed.

Im Groben besteht eine E-Mail aus einem Header, in welchem sich unterschiedlichste Header-Felder befinden, welche Auskunft darüber geben, woher die E-Mail kam, wohin sie gehen soll und welche MTAs sie empfangen haben.

Daneben befinden sich weitere Informationen in der E-Mail, einige davon wie Subject, oder Date werden für die Anzeige der E-Mail im E-Mail-Programm herangezogen. Anschließend folgt der Message Body, in welchem die eigentliche Nachricht kodiert ist.

Da E-Mails an sich nur 7-Bit-ASCII-Zeichen unterstützen, müssen andere Zeichen und Typen von Inhalten wie Binärdateien erst umkodiert werden. Dazu wurden unter anderem die Multipurpose Internet Mail Extensions definiert, welche regeln, wie die entsprechenden Codierungen auszusehen haben.

Protokolle

Während sich bis zum Jahr 1980, innerhalb des ARPANET und dem dortigen E-Mail-System Protokolle wie SNDMSG und FTP mail hielten, haben sich im Laufe der Zeit einige Standardprotokolle herauskristallisiert, welche bis zur heutigen Zeit, mit einigen Erweiterungen genutzt werden.

Es handelt sich um die Protokolle SMTP, POP3 und IMAP. Während SMTP dem Transfer der E-Mail vom E-Mail-Client zum MSA bzw. dem Weiterversand von E-Mails von einem MTA zum nächsten dient, werden die Protokolle POP3 und IMAP zur Kommunikation des E-Mail-Servers mit dem E-Mail-Client genutzt.

SMTP

Das Simple Mail Transfer Protocol kurz SMTP nimmt beim E-Mail-System eine gehobene Stellung ein.

Während die E-Mails, welche auf dem eigenen E-Mail-Server empfangen wurden, theoretisch mit einem entsprechenden Shellzugriff direkt auf dem Server gelesen werden können, wird ein Protokoll benötigt, welches die E-Mails von einem Mail Transfer Agent zum nächsten MTA transportiert.

Hierfür wurde SMTP in der RFC 821 im August 1982 spezifiziert. Diese Version kam noch ohne Authentifizierung aus, sodass jedermann eine E-Mail bei einem MTA einliefern konnte, was im Laufe der Zeit zu einem Spam-Problem führte.

Deshalb wurde SMTP mit der RFC 1869 so erweitert, dass das Protokoll über einen Mechanismus verfügte, über welchen der Server den Client informieren konnte, über welche Service extensions der Server verfügt.

Dies ermöglichte es Authentifizierung und Verschlüsselungen über Erweiterungen wie STARTTLS durchzuführen und somit neben der Authentifizierung auch die Verschlüsselung zu gewährleisten.

Heutzutage sollten SMTP allerdings nicht mehr über STARTTLS, sondern direkt über TLS durchgeführt werden, da Technologien wie STARTTLS gegenüber Man-in-the-Middle-Angriffen anfällig sind.

POP3

Nachdem die E-Mails auf dem E-Mail-Server gelandet sind, wird ein Protokoll benötigt, um diese vonseiten des meist externen E-Mail-Clients wieder abzuholen.

Mit dem Post Office Protocol, welches in der aktuellen Version als POP3 abgekürzt wird, können die entsprechenden Mails vom E-Mail-Server heruntergeladen und vom Server gelöscht werden.

Mit POP4 sollte eine Weiterentwicklung des Protokolls verbunden sein, allerdings scheint diese seit 2003 nicht mehr gepflegt zu werden.

IMAP

Während sich POP3 gut dafür eignet, E-Mails vom Server zu holen, um die Postfächer im eigenen E-Mail-Client lokal zu verwalten, eignet sich das Internet Message Access Protocol kurz IMAP dazu, die entsprechenden E-Mails direkt auf dem Server zu verwalten.

IMAP unterstützt Funktionalitäten wie unterschiedliche Verzeichnisstrukturen oder die Benachrichtigung über neue E-Mails per Push-Verfahren.

Wie bei POP3 müssen auch bei IMAP zwei Protokolle unterstützt werden, da das Senden der Mails wiederum über SMTP erfolgt. Mit dem Simple Mail Access Protocol gab es Ansätze dies zu ändern, allerdings hat sich dieses bisher nicht durchgesetzt.

Ausfallsicherheit

Während wir heute daran gewöhnt sind, dass eine E-Mail meist innerhalb weniger Minuten beim Empfänger ankommt, war dies historisch gesehen nicht immer so. So konnte es schon einmal Tage dauern, bis eine entsprechende E-Mail schlussendlich beim Empfänger ankam.

Dies war unter anderem dadurch bedingt, dass nicht alle E-Mail-Server immer eine permanente Verbindung zum Internet hatten und es auch vorkommen konnte, dass Server für einige Zeit nicht verfügbar waren.

Das zeigt aber auch auf, wie resilient das E-Mail-System gestaltet wurde. Wenn ein MTA auf Empfängerseite nicht verfügbar ist, versuchen die sendenden MTAs die E-Mail später zuzustellen. Meist wird eine E-Mail erst nach einiger Zeit z. B. 48 Stunden als unzustellbar angesehen und der Absender entsprechend informiert.

Das bedeutet, wenn der eigene E-Mail-Server einmal ausfällt, so ist dies im ersten Moment kein dramatisches Ereignis, weil im Idealfall trotzdem alle E-Mails zugestellt werden.

Einen E-Mail-Server aufsetzen

Wer seine Domain bei einem Webhoster untergestellt hat, bekommt meist einen entsprechenden, vom Anbieter gewarteten E-Mail-Server dazu.

Interessanter wird es, wenn ein solcher E-Mail-Server selbst aufgesetzt werden soll. In einem solchen Fall muss ein MTA und MDA ausgewählt werden. Unter Linux ist eine beliebte Kombination für diese Funktionalitäten Postfix und Dovecot.

Grundsätzlich ist der Markt an Server-Anwendungen breit gestreut. Neben den Linux-Varianten und Servern wie Postfix und Dovecot existieren auch proprietäre Lösungen wie der Microsoft Exchange Server.

Nachdem die passende Lösung gewählt wurde, sollte diese für den jeweiligen Anwendungsfall konfiguriert oder entsprechend vorkonfektionierte Pakete genutzt werden.

Betrieb des Servers

Ist der E-Mail-Server aufgesetzt, fangen die eigentlichen Probleme an. Dies fängt damit an, dass es praktisch unmöglich ist, einen E-Mail-Server zu Hause zu betreiben. Die Einlieferung von E-Mails von Servern, welche in dynamischen DSL-IP-Adressbereichen unterwegs sind, wird von den meisten Betreibern von E-Mail-Servern unterbunden, meist um Spam zu verhindern.

Damit bleibt als Lösung der Betrieb eines Servers in einem Rechenzentrum, mit entsprechend fixer IP-Adressen oder entsprechenden Tarifen im gewerblichen Umfeld.

Ist der E-Mail-Server eingerichtet, der MX-Record korrekt gesetzt und sind die entsprechenden Nutzer angelegt, kann der Nutzer in der Theorie Mails senden und empfangen.

Neben dem Setzen des MX-Records ist es mittlerweile auch hilfreich, die DNS-Records für die automatische Erkennung durch E-Mail-Clients zu konfigurieren. Geregelt wird das Verfahren in der RFC 6186. Dies ermöglicht es den Clients, die Konfiguration für den E-Mail-Server schnell und unkompliziert vorzunehmen.

In der Praxis ist das erfolgreiche Senden von E-Mails eine kleine Herausforderung. So müssen entsprechende PTR-Records für die Auflösung der IP-Adresse zur entsprechenden Domain hinterlegt werden.

Andere E-Mail-Server überprüfen, ob der Name der IP-Adresse (Reverse DNS) zum eigenen E-Mail-Server passt. Wird etwa die IP-Adresse 192.168.10.1 genutzt und deren Reverse DNS-Name lau­tet mail.example.com, so muss auch der Host­name mail.example.com in der Konfiguration des Mailservers dementsprechend konfiguriert sein.

Sendet der Server die E-Mails auch per IPv6, so muss überprüft werden, dass ein entsprechender PTR-Record für die Adresse gesetzt ist, ansonsten kann es zu solchen Meldungen im E-Mail-Verkehr kommen:

host mail.example.com[2001:db8:a0b:abf0::1]
said: 550-Inconsistent/Missing DNS PTR record (RFC 1912 2.1)
(example.org) 550 [2001:db8:a0b:12f0::1]:34865 (in reply to RCPT TO command)

Selbst wenn der Eintrag zur Auflösung der IP-Adresse (Reverse DNS) korrekt gesetzt ist, kann es passieren, dass bei der Nutzung von IPv6 diese Meldung erscheint. Hintergrund ist meist, dass der entsprechende Server ein IPv6-Subnetz erhält und z. B. Postfix dann eine beliebige Adresse aus diesem Subnetz zum Senden benutzt. Hier bietet es sich an, die entsprechende Interface-Adresse für den Server fest zu definieren.

E-Mails sinnvoll zuzustellen ist insbesondere bei größeren Anbietern wie Gmail problematisch, weil eine Reihe von Voraussetzungen erfüllt sein müssen.

Hier ist es neben den normalen Maßnahmen wie dem korrekten Setzen der DNS-Einträge (Forward und Reverse), meist auch notwendig Verfahren wie SPF, DKIM und DMARC zu implementieren, welche die Komplexität für den entsprechenden E-Mail-Server steigen lassen.

SPF

Mit dem Sender Policy Framework (SPF), wurde ein Verfahren geschaffen, welches sicherstellen sollte, dass E-Mails mit bestimmten Absendern nur von berechtigten E-Mail-Server versendet werden können.

SPF wird auf der Empfängerseite geprüft

Dazu wird bei SPF im DNS eine entsprechende Konfiguration hinterlegt, welche festlegt, welche Server berechtigt sind, für die Absender-Domain E-Mails zu versenden. Die entsprechend notwendigen DNS-Records können über unterschiedlichste Tools erzeugt werden, z. B. über die Webseite spf-record.de.

DKIM

Bei DomainKeys Identified Mail (DKIM) wird die jeweilige E-Mail um eine Signatur ergänzt, über welche der empfangende MTA feststellen kann, ob die E-Mail wirklich vom MTA der Absender-Domain stammt.

Dazu wird über einen im DNS hinterlegten öffentlichen Schlüssel für die Absender-Domain überprüft, ob die Signatur in der E-Mail valide ist.

DMARC

Aufbauend auf SPF und DKIM existiert mit Domain-based Message Authentication, Reporting and Conformance (DMARC) eine Spezifikation, mit welcher festgelegt wird, wie mit entsprechenden E-Mails, welche durch die SPF- und DKIM-Prüfung durchgefallen sind, reagiert werden soll.

Auch hier werden DNS-Records der Absender-Domain genutzt, um entsprechende Informationen für die Richtlinie zu hinterlegen.

Eine Besonderheit bei DMARC ist, dass der im DNS-Record hinterlegte DMARC-Admin über fehlgeschlagene DMARC-Prüfungen informiert werden kann und somit erfährt, dass die entsprechende Domain für Spam missbraucht wird.

Klein anfangen

Bei kleinen E-Mail-Servern, mit geringen Volumen an E-Mails, reicht es meist aus SPF zu aktivieren. Spätestens bei der Nutzung von IPv6 müssen einige Maßnahmen wie SPF eingerichtet werden, um E-Mails sicher versenden können. Andernfalls kann es vorkommen, dass solche E-Mails abgelehnt werden.

Auch ist es nicht ratsam sofort mit großen E-Mail-Volumina auf die Server von Google zu feuern, hier wird ein langsames Ansteigen der Last über einen längeren Zeitraum bevorzugt, um nicht von eventuellen Anti-Spam-Maßnahmen betroffen zu sein.

Dann gibt es auch noch speziellere Fälle, wie bei T-Online, in deren Dokumentation sich folgender Abschnitt findet:

Insbesondere empfehlen wir, den Hostnamen so zu wählen, dass seine Nutzung als Mailserver für Außenstehende erkennbar ist (z. B. mail.example.com), und sicherzustellen, dass die Domain zu einer Website führt, die eine Anbieterkennzeichnung mit sämtlichen Kontaktdaten beinhaltet.

Bei solchen Regeln ist es damit praktisch unmöglich einen reinen E-Mail-Server zu konfigurieren, da zumindest ein Webserver mit dem Impressum vorhanden sein muss. Ansonsten erhält der Betreiber des E-Mail-Servers entsprechende Meldungen im Log:

Dec  6 19:07:26 host42 postfix/smtp[3017216]: ED2DA7EE0104: to=<>, relay=mx00.t-online.de[194.25.134.8]:25, delay=0.33, delays=0.16/0.02/0.14/0, dsn=4.0.0, status=deferred (host mx00.t-online.de[194.25.134.8] refused to talk to me: 554 IP=192.168.9.1 - A problem occurred. (Ask your postmaster for help or to contact  to clarify.))

Spam, Spam, Spam

Monty Python schenkte uns nicht nur Silly Walks, sondern auch Spam. Der berühmte Sketch führte schlussendlich dazu, dass wir ungewollte E-Mails als Spam bezeichnen. Das Problem selbst wurde relativ früh erkannt und in die RFC 706, welche den schönen Titel On the Junk Mail Problem trägt, gegossen.

Spam ist in unserer heutigen Zeit allgegenwärtig und wird leider massenhaft versendet. Ohne zumindest minimale Maßnahmen, um Spam zu unterdrücken, sollte ein E-Mail-Server nicht betrieben werden. Hier muss auch immer die Abwägung getroffen werden zwischen der Filterung unerwünschter Mails und dem Abweisen von legitimen Mails, welche fälschlicherweise als Spam erkannt worden sind.

Greylisting

Eine der einfachsten und effektivsten Maßnahmen gegen Spam ist das sogenannte Greylisting. Beim Greylisting wird eine Mail von einem unbekannten Absender im ersten Schritt nicht angenommen und stattdessen ein technischer Fehler kommuniziert.

Sep  4 09:12:26 lexa postfix/smtpd[2761177]: NOQUEUE: reject: RCPT from unknown[213.209.159.56]: 450 4.2.0 <>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/example.org.html; from=<> to=<> proto=ESMTP helo=

Standardkonforme E-Mail-Server senden eine solch zurückgewiesene E-Mail nach einer Wartezeit noch einmal. Ist die eingestellte Greylisting-Zeit abgelaufen, wird die E-Mail anschließend angenommen.

Bei einer Spamnachricht, welche an viele Millionen Empfänger gesendet wird, findet dieses abermaliges Versenden der E-Mail in den meisten Fällen nicht statt. Damit kann mittels Greylisting ein Großteil von Spam-E-Mails gefahrlos aussortiert werden.

Problematisch wird Greylisting dann, wenn z. B. Zwei-Faktor-Authentifizierungscodes empfangen werden sollen, welche nur eine gewisse Zeit gültig sind und durch die Verzögerung beim Greylisting ihre Gültigkeit verlieren.

Weitere Filter

Neben dem Greylisting, gibt es eine Reihe von kleineren Überprüfungen, welche vorgenommen werden können, bevor eine E-Mail angenommen wird. Je nach eingesetzter Software können diese Direkten aktiviert werden und somit E-Mails, welche den Direktiven widersprechen, abzuweisen.

So existiert unter Postfix z. B. die Direktive reject_unknown_sender_domain. Diese Direktive weist E-Mails zurück, welche Adressen nutzen, für welche kein MX- oder A-Record vergeben wurde. Dies ist dann der Fall, wenn entsprechender Spam von Adressen versendet wird, welche in Wirklichkeit nicht existieren oder von Servern kommen, welche nicht als E-Mail-Server konfiguriert sind.

In einer Postfix-Konfiguration werden diese Direktiven nacheinander abgearbeitet:

smtpd_relay_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  defer_unauth_destination
  reject_unknown_sender_domain
  reject_unknown_reverse_client_hostname
  reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]
  reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99]
  reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99]
  reject_rhsbl_reverse_client dbl.spamhaus.org=127.0.1.[2..99]
  warn_if_reject reject_rbl_client zen.spamhaus.org=127.255.255.[1..255]
  check_policy_service inet:127.0.0.1:10023

Durch diese Direktiven, welche gewisse Prüfungen auf Standardkonformität durchführen, wird idealerweise ein Großteil des Spams abgewiesen.

DNS-based blocklists

Daneben sind zur Bekämpfung von Spam auch DNS basierte Blocklisten in Gebrauch. Bei einer solchen Liste wird die IP-Adresse des Senders per DNS gegenüber dem Anbieter der Blockliste aufgelöst. Über den Rückgabecode kann damit ermittelt werden, ob das entsprechende sendende System als Spam eingestuft wird und die entsprechende Mail zurückgewiesen werden.

Auf dem Markt sind einige größere Listen verfügbar, z. B. von Spamhaus. Für den eigenen E-Mail-Server, sollte hier eine sinnvolle Abwägung getroffen werden, welche Liste(n) zur Prüfung hinterlegt werden sollen, da diese Listen im schlimmsten Fall darüber entscheiden ob eine E-Mail abgewiesen wird.

E-Mail-Server goes Cloud

Wer diesen Aufwand nicht treiben möchte, kann seine eigene Domain mit einem E-Mail-Server aus der Cloud versorgen. Unter anderem Google unterstützt dies.

So kann mit Google Workspace eine eigene Domain für die Nutzung von Gmail eingerichtet werden. Damit wird das E-Mail-System von Google benutzt und in der Theorie hält sich der Wartungs- und Verwaltungsaufwand in Grenzen.

Problematisch ist allerdings, dass sich in eine entsprechende Abhängigkeit begeben wird und auch datenschutzrechtliche Aspekte eine Rolle spielen, was z. B. den Transfer von Daten in das Nicht-EU-Ausland angeht.

Technisch realisiert wird dies so, dass die entsprechenden MX-Records für die eigene Domain auf die E-Mail-Server von Google zeigen und somit die offiziellen E-Mail-Server für die Domain sind.

Rechtliche und weitere Anforderungen

Neben den technischen Anforderungen kommen je nach Größe des E-Mail-Servers noch weitere rechtliche Anforderungen hinzu. So müssen ab einer bestimmten Nutzeranzahl unter Umständen Abhörschnittstellen eingerichtet werden, was sich aus der Telekommunikations-Überwachungsverordnung ergibt.

Auch ist es sinnvoll bestimmte E-Mail-Adressen, wie sie in der RFC 2142 definiert werden, bereitzuhalten. Daneben sollten auch Prozesse eingerichtet werden, um Anfragen an diese E-Mail-Adressen, wie. z. B. Abuse-Adressen, zu bearbeiten.

Re­sü­mee

Auch wenn der Betrieb eines E-Mail-Servers mit gewissen Anforderungen verbunden ist, bietet er durchaus Vorteile. So können private Daten auf der eigenen Infrastruktur gehalten und verarbeitet werden und es löst Abhängigkeiten von großen Infrastrukturanbietern.

Außerdem trägt ein solcher Server zum Grundgedanken des E-Mail-Systems bei, dass es sich um ein dezentrales System handelt.

Wer einen E-Mail-Server für private Zwecken einrichten möchte, kann sich z. B. der Top-Level-Domain .email annähern, mit welcher sich angenehm kurze E-Mail-Adressen für die eigene Familie (z. B. ) realisieren lassen.

Auch wenn heutzutage die firmeninterne Kommunikation in vielen Fällen über andere Systeme wie Slack oder Teams läuft und wir in persönlichen Kontakten meist auf Messenger à la WhatsApp oder Signal setzen, wird E-Mail, auch wenn sie ein in die Jahre gekommenes Medium ist, uns in der Zukunft begleiten.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Freifunk – eine Einführung

Bedingt durch unseren Hackerspace, den wir in Neubrandenburg betreiben, habe ich mich in letzter Zeit etwas intensiver mit dem Thema Freifunk beschäftigt.

Der Hackerspace in der Stadtmauer

Es sollte ein Router an das Freifunknetz angeschlossen werden. Die Vorstellungen, welche mir davon im Kopf schwebten, war am Anfang etwas diffus. Glücklicherweise gibt es den Verein Förderverein Freie Netzwerke e. V. – welcher einem mit Rat und Tat zur Seite steht.

Die Freifunk-Community

So wird die offizielle Webseite, freifunk.net, besucht und dort finden sich folgende Punkte unter anderem die Punkte Worum geht’s? und Wie mache ich mit? – schon mal ein guter Einstieg. In früheren Jahren fand sich auf der Webseite dann noch der Satz:

Wir regeln den Rest.

Ganz so einfach ist es allerdings nicht. Auf der Suche nach Informationen ist die Webseite ein guter Anlaufpunkt, im Worum geht’s?-Video klingt das Ganze noch einfach und blumig.

Aktivieren Sie JavaScript um das Video zu sehen.
Video-Link: https://vimeo.com/64814620

Für etwas Klarheit sollte sich die Organisationsstruktur der Freifunk-Community angeschaut werden. Zum einen existiert der Förderverein Freie Netzwerke e. V. Dieser betreibt unter anderem die Webseite freifunk.net. Auf der Webseite wird die Tätigkeit des Vereines wie folgt beschrieben:

Aufgabe des Fördervereins Freie Netzwerke e.V. ist die Förderung der Bildung und Kultur bezüglich kabelloser und kabelgebundener Computernetzwerke, die der Allgemeinheit zugänglich sind (sogenannte freie Netzwerke). Zu diesem Zweck betreibt der Verein die Internetplattform freifunk.net und fördert darüber hinaus diverse Aktivitäten und initiiert Projekte, die den nachfolgenden Zwecken dienen:

* Information über freie Netzwerke, insbesondere durch das Internet sowie durch Vorträge, Veranstaltungen, Vorführungen und Publikationen
* Bereitstellung von Know-How über Technik und Anwendung freier Netzwerke
* Information über gesellschaftliche, kulturelle, gesundheitliche und rechtliche Auswirkungen freier Netzwerke
* Förderung der Kontakte und des Austauschs mit Menschen und Organisationen im In- und Ausland, die im Bereich der freien Netzwerke tätig sind
* Förderung und Unterstützung von Projekten und Initiativen, die in ähnlichen Bereichen tätig sind

Neben der Freifunk-Webseite betreibt der Verein unter anderem auch den Blog freifunkstattangst.de, welcher sich mit der Frage der Störerhaftung beschäftigt.

Die lokalen Freifunk-Communitys, z. B. in Berlin, Hamburg oder auch Bielefeld, möchten an ihren Standorten dezentrale Mesh-Netzwerke aufbauen. Mittlerweile existieren über 400 solcher lokalen Communitys im deutschsprachigen Raum.

Gratis-WLAN mit Internetanbindung

Dabei wird Freifunk gerne auf die Formel Gratis-WLAN mit Internetanbindung reduziert. Bei einem genaueren Blick auf Freifunk ist dies aber nur ein netter Nebeneffekt. Genauer wird das Ganze in der Vision erklärt. Dort wird eine zentrale Frage an den Interessenten gestellt:

Wie wäre es, wenn auch online jeder mit jedem kommunizieren könnte, ohne eine Firma bei der man sich anmelden müsste?

Diese Frage beschreibt sehr gut, warum die Freifunker das tun, was sie tun. Auch das Selbstverständnis der Freifunker wird dort beschrieben:

Wir verstehen frei als

* öffentlich und anonym zugänglich
* nicht kommerziell und unzensiert
* im Besitz einer Gemeinschaft und dezentral organisiert

Die Qual der Wahl

Doch wie fängt der Interessierte an? Neben der rechtlichen Form (z. B. ein gemeinnütziger Verein) welche sich die lokale Community geben kann, gibt es viel profanere Probleme, welche es zu lösen gilt.

Ein Freifunk-Router (CC-BY / Jens Ohlig)

Ein Freifunk-Router (Jens Ohlig, Freifunk router, CC BY 3.0)

Bevor sich mit der Hardware beschäftigt werden kann, muss sich erst mit der Software – in diesem Fall der Firmware – beschäftigt werden. Schließlich muss eine kompatible Firmware für die gewünschte Hardware gefunden werden. Die Anzahl der Firmware-Varianten ist insbesondere für Einsteiger erst einmal unüberschaubar.

Es fühlt sich so an als ob jede lokale Community ihre eigene Firmware-Version nutzt. Als Einsteiger kommt der Wunsch auf hier mehr an die Hand genommen zu werden.

Fledermäuse im Mesh-Netzwerk

Die unterschiedlichen Firmwares unterscheiden sich nicht nur durch die unterschiedlichen Features, sondern auch durch die verwendeten Routing-Protokolle zum Aufbau eines Mesh-Netzwerkes. So gibt es Firmware welche das Optimized Link State Routing Protocol, kurz OLSR, nutzen, andere wiederum nutzen das Better Approach To Mobile Adhoc Networking-Protokoll (B.A.T.M.A.N.). Bei der Gründung einer neuen Community muss sich also überlegt werden, welches Routing-Protokoll eingesetzt werden soll. Schließlich sollten die anderen Router der Community mit demselben Protokoll betrieben werden.

OLSR, wurde in der RFC 3626 spezifiziert und ist ein Protokoll, bei dem jedem Knoten die komplette Topologie des Netzes bekannt ist. Damit handelt es sich um ein Link-State-Routing-Protokoll, welche sich dadurch auszeichnen, dass der Router eine Datenbank mit den entsprechenden Informationen über die Topologie aufbaut. Bei OLSR führt dies dazu, dass relativ viel Bandbreite und Rechenleistung zur Berechnung der Pfade im vermeshten Netzwerk benötigt wird.

Das Protokoll B.A.T.M.A.N. hingegen kennt nicht mehr die komplette Topologie des Netzwerkes. Stattdessen informiert jedes Gerät seine Nachbarn darüber, dass es existiert. Diese Nachbarn wiederum informieren ihre Nachbarn. Beim Routing geht es nun darum das Paket in die richtige Richtung zu schicken, ohne die komplette Route vorher zu kennen.

Mit der Weiterentwicklung B.A.T.M.A.N. Advanced, welches auf der zweiten Schicht im OSI-Modell, dem Data Link Layer arbeitet, können die entsprechenden Geräte sich mit dem vermeshten Netz verbinden und sind frei in der Wahl ihrer Protokolle auf dem OSI-Layer 3. Es spielt für B.A.T.M.A.N. Advanced keine Rolle mehr, ob auf diesem OSI-Layer DHCP, IPv4, IPv6 oder andere Protokolle genutzt werden. Seit mittlerweile über zehn Jahren befindet sich die Unterstützung für dieses Protokolls, in Form Kernel-Moduls, im offiziellen Linux-Kernel.

OpenWrt

Die Basis der meisten, wenn nicht aller Freifunk-Firmwares ist OpenWrt. Dabei handelt es sich um eine auf Linux basierende Distribution für kleinere Embedded Devices – welche vorwiegend für Router genutzt wird.

Historisch basiert OpenWrt auf der Firmware der Router-Serie WRT54G von Linksys. Der dort genutzte Linux-Kernel ist unter der GNU General Public License lizenziert und damit muss der Quellcode für die Firmware ebenfalls mit ausgeliefert werden.

Nach einigen Appellen führte dies dazu, dass Linksys, den entsprechenden Quellcode freigab. Daneben wurde im Lichte dieser Ereignisse das Projekt gpl-violations.org, welches sich der Durchsetzung der GPL verschrieb, durch Harald Welte gegründet.

Auf der Suche nach der passenden Hardware sollte sichergestellt werden, dass diese von OpenWrt unterstützt wird. Dazu gibt es in der OpenWrt-Wiki eine Table of Hardware und einen Einkaufsratgeber. Wichtig ist hier, dass das beste Gerät nicht existiert, es sollte den gewünschten Ansprüchen entsprechen und dem Einsatzzweck genügen.

Nach der Geräteauswahl, erfolgt die Auswahl der Firmware, schließlich muss der Router mit einer passenden Software bespielt werden. Auch hier ist die Auswahl wieder einmal unübersichtlich. Soll das Routing-Protokoll OSLR genutzt werden, so kann vom Meshkit eine passende Freifunk-Firmware generiert werden. Allerdings werden hier nicht alle OpenWrt-Plattformen unterstützt, sodass je nach verwendeter Hardware Meshkit ausscheidet.

meshkit.freifunk.net

Bei der Nutzung des moderneren B.A.T.M.A.N. bzw. B.A.T.M.A.N. Advance-Protokolls, kann auf Gluon gesetzt werden. Dabei handelt es sich um ein modulares Framework mit welchem eine entsprechende Freifunk-Firmware auf der Basis von OpenWrt erzeugt werden kann. Über die Hälfte der Freifunk-Communitys setzt auf diese Lösung.

Bei Gluon wird anhand einiger Konfigurationsdateien ein passendes Image erzeugt. Das Gluon-Image verfügt auch über eine Funktion für automatische Updates, mit welcher die entsprechenden Geräte mit neuen Versionen bespielt werden können.

Rechtliche Rahmenbedingungen

Nach der Installation des Images auf der gewünschten Hardware ist, ist der Freifunk-Router fertiggestellt. Überspitzt ließe sich sagen, dass die Probleme damit anfangen. Auf technischer Seite gibt es bei der Standardkonfiguration das Problem, dass die Luftschnittstelle unverschlüsselt ist, was unschön ist. Ein anderes Problem ist die Haftung, womit wir bei der rechtlichen Seite von Freifunk landen.

Die Freifunk-Geräte senden ihren Traffic zu einem in der Firmware eingestellten Gateway. Damit haben die Aufsteller der Router keine Probleme. Im Gateway wird der Traffic dann in das Internet überführt. Hier wird es problematisch. Natürlich haftet in der Theorie niemand für die Straftaten anderer. Allerdings ist der Betreiber des Gateways der erste Ansprechpartner, wenn etwas schiefgeht – und im schlimmsten Fall hat dieser erst einmal eine Menge Stress mit der Judikative und der Exekutive – bis dort bemerkt wird, dass jemand anders gesucht wird. Glück dem, der sich auf das Providerprivileg berufen kann.

Als Lösung ließe sich hier unter anderem der Gateway-Traffic über einen VPN-Zugang ins Internet routen, damit das eigene Freifunk-Netzwerk unbeschwerter in Betrieb genommen werden kann. Dies ist bei den meisten Freifunk-Communitys der Standard.

Mitte 2017 beschloss der Bundestag eine Änderung des Te­le­me­di­en­ge­set­zes, in welchem die oft kritisierte Störerhaftung abgeschafft wurde. Der entsprechende Paragraph 8 des TMG enthält nun unter anderem folgenden Punkt:

(1) Diensteanbieter sind für fremde Informationen, die sie in einem Kommunikationsnetz übermitteln oder zu denen sie den Zugang zur Nutzung vermitteln, nicht verantwortlich, sofern sie

1. die Übermittlung nicht veranlasst,
2. den Adressaten der übermittelten Informationen nicht ausgewählt und
3. die übermittelten Informationen nicht ausgewählt oder verändert haben.

² Sofern diese Diensteanbieter nicht verantwortlich sind, können sie insbesondere nicht wegen einer rechtswidrigen Handlung eines Nutzers auf Schadensersatz oder Beseitigung oder Unterlassung einer Rechtsverletzung in Anspruch genommen werden; dasselbe gilt hinsichtlich aller Kosten für die Geltendmachung und Durchsetzung dieser Ansprüche. ³ Die Sätze 1 und 2 finden keine Anwendung, wenn der Diensteanbieter absichtlich mit einem Nutzer seines Dienstes zusammenarbeitet, um rechtswidrige Handlungen zu begehen.

Damit wurde auch im Freifunk-Bereich wesentlich mehr Rechtssicherheit geschaffen, sodass der Betrieb solcher offener Netzwerke wesentlich angenehmer geworden ist.

Resümee

Die Gründung einer lokalen Gruppe ist mit einigen Herausforderungen verbunden, während die Integration eigener Router in bestehende Communitys wesentlich einfacher ist. Für unseren Hackerspace haben wir beschlossen, es auf einen späteren Zeitpunkt zu vertagen, da wir unsere Energie erst einmal in andere Themen gesteckt haben.

Dieser Artikel erschien ursprünglich 2014 unter dem Titel Freifunk für Dummies und wurde anschließend für eine Veröffentlichung bei Golem.de aktualisiert.

IPv6-Paket eines MikroTik-Routers aktivieren

Auf einem MikroTik-Router wollte ich neben dem klassischen IPv4 auch IPv6 nutzen. Im Webinterface sah ich in der Paketübersicht allerdings, dass das betreffende Paket deaktiviert war.

Das IPv6-Paket war deaktiviert

Zur Aktivierung eines Paketes kann unter anderem das Terminal genutzt werden. In diesem muss der Befehl zur Aktivierung des IPv6-Paketes eingegeben werden:

/system package enable ipv6

Anschließend muss das System neugestartet werden:

/system reboot

Nach dem Neustart steht das IPv6-Paket anschließend zur Verfügung.

IPv4 über DNS tunneln

Viele Netzwerke, wie z.B. öffentliche WLAN-Zugänge lassen Verbindung ohne Authentifikation zu. Nachdem man sich mit dem Netzwerk verbunden hat, muss man sich meist auf einem sogenannten Captive Portal anmelden. Dabei handelt es sich um eine Vorschaltseite, welche einem beim Aufruf einer Webseite angezeigt wird und der Anmeldung bzw. Identifizierung dient. Bei vielen dieser Netzwerken funktioniert die Kommunikation über das DNS-Protokoll ohne weitere Probleme (trotz Captive Portal) und Authentifikation, so das man diese nutzen kann um einen Tunnel ins freie Internet zu errichten.

code.kryo.se/iodine/

code.kryo.se/iodine/

Eine Lösung um einen solchen DNS Tunnel einzurichten ist iodine. Mit iodine ist es möglich IPv4-Verkehr über DNS zu tunneln. Pro DNS-Request können dabei bis zu einem Kilobyte an Daten übertragen werden, was sich positiv auf die Performance und den Durchsatz auswirkt. iodine läuft dabei auf vielen unixodien Systemen, sowie unter Windows. Lizenziert ist iodine unter der ISCL und damit freie Software. Der Quelltext ist auf GitHub zu finden.