Warum wir alle plötzlich über DNS reden – ein provokanter Einstieg

Stellen Sie sich vor, Sie geben bei einem Online-Shop Ihre Kreditkartendaten ein und plötzlich wird Ihr Geld an einen völlig anderen Empfänger überwiesen. Das war gestern, heute ist das DNS. Bei einem simplen ping example.com liegt das Rückgrat des Internets – das Domain Name System – im Hintergrund, und jeder Eingriff von außen kann Sie in den digitalen Abgrund stürzen. Deshalb reden inzwischen alle über DNS‑Sicherheit, doch die meisten kennen nur das Wort „VPN“. Wir gehen heute tiefer: DNS‑over‑TLS (DoT), DNS‑over‑HTTPS (DoH) und DNSSEC – drei unterschiedliche Schutzschichten, die Sie kennen sollten, um nicht das nächste Opfer zu werden.

1. Grundprinzipien: Was schützt was?

Erklärung

• 
  DoT verschlüsselt den gesamten DNS‑Query‑Channel über TLS. Der Client verbindet sich mit einem dedizierten Port 853 und fragt dort ab – ähnlich wie bei HTTPS, nur dass das Protokoll DNS bleibt.


• 
  DoH kapselt DNS‑Anfragen in reguläre HTTPS‑Requests (Port 443). Das hat den Vorteil, dass DNS‑Traffic durch Firewalls oder Deep‑Packet‑Inspection kaum zu unterscheiden ist.


• 
  DNSSEC ist kein „Verschlüsselungs‑Tool“, sondern ein Authentisierungs‑Mechanismus. Jeder DNS‑Eintrag wird kryptografisch signiert, so dass ein Angreifer nicht einfach einen gefälschten Eintrag einschleusen kann.

Beispiele & persönliche Bewertung

Mein Fazit: Wenn Sie nur verhindern wollen, dass jemand Ihren DNS‑Traffic ausspioniert, reicht DoT/DoH. Wenn Sie jedoch sicherstellen wollen, dass die zurückgelieferten IP‑Adressen echt sind – zum Beispiel im Unternehmensnetz, das kritische Services hostet – brauchen Sie DNSSEC.

2. DoT in der Praxis – Konfiguration und Test

Erklärung

DoT erfordert einen DNS‑Resolver, der TLS unterstützt (z. B. Unbound 1.14+, Knot Resolver oder Bind 9.16+). Der Client muss wissen, welchen Server er ansprechen soll. Unter Linux ist das meist systemd-resolved oder stubby.

Beispiel 1 – Stubby installieren & konfigurieren

# Auf Debian/Ubuntu

sudo apt-get update && sudo apt-get install stubby

/etc/stubby/stubby.yml anpassen (Ausschnitt):

resolution_type: GETTLS



upstream_recursive_servers:

  - address_data: 1.1.1.1

    tls_auth_name: "cloudflare-dns.com"

    tls_port: 853

  - address_data: 9.9.9.9

    tls_auth_name: "dns.quad9.net"

    tls_port: 853

Die Datei speichert die TLS‑Authentifizierung (Server‑Name‑Indication) und den Port 853. Dann:

sudo systemctl restart stubby

sudo resolvectl dns $(ip route get 1.1.1.1 | awk '{print $5}') 127.0.0.1#53

Jetzt nutzt das System DoT über Stubby. Einen schnellen Test führt man mit dig aus:

DIG +tls +short @127.0.0.1 example.com

Wenn die Ausgabe eine IP‑Adresse liefert, funktioniert DoT.

Meine Einschätzung

DoT ist einfach zu implementieren, weil Sie lediglich den Resolver umstellen. Der Knackpunkt ist die Auswahl eines vertrauenswürdigen TLS‑Resolver‑Pools – ein schlechter Resolver kann Sie wieder in die Irre führen.

3. DoH in der Praxis – Curl & Browser‑Integration

Erklärung

DoH nutzt das HTTPS‑Protokoll, deshalb kann jeder Browser (Firefox, Chrome) oder jedes Tool, das HTTP‑Requests senden kann, als DNS‑Resolver agieren. Ziel ist, DNS‑Traffic in normalen Web‑Traffic zu verstecken.

Beispiel 2 – DoH mit curl testen

# Anfrage an Cloudflare's DoH‑Endpoint

curl -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=example.com&type=A" | jq .Answer[0].data

Ergebnis: 93.184.216.34. Dabei sehen Sie, dass die Antwort im JSON‑Format zurückkommt.

Beispiel 3 – Firefox DoH aktivieren

1. 
   about:config öffnen.


2. 
   network.trr.uri auf https://dns.google/dns-query setzen.


3. 
   network.trr.mode auf 2 (strict) setzen.


4. Browser neu starten.

Jetzt leitet Firefox alle DNS‑Auflösungen über DoH an Googles Resolver.

Meine Einschätzung

DoH ist unsichtbar, das ist sowohl Vor- als auch Nachteil. Unternehmen verlieren die Möglichkeit, DNS‑Abfragen zu protokollieren, weil sie jetzt im HTTPS‑Traffic verborgen sind. Für Privatanwender ist das ein großer Datenschutz‑Boost, für Admins ein neues Rätsel.

4. DNSSEC – Authentizität auf DNS‑Ebene sichern

Erklärung

DNSSEC erweitert jede Zone um digitale Signaturen. Der Prozess besteht aus:

1. Schlüsselgenerierung (KSK – Key Signing Key, ZSK – Zone Signing Key).


2. Signieren der Zone (dnssec-signzone).


3. Publizieren der Schlüssel im Parent‑Domain‑Eintrag (z. B. bei example.com im com‑TLD‑Zone‑File).

Beispiel 4 – BIND‑9 mit DNSSEC einrichten

# 1. Schlüssel erzeugen

cd /etc/bind

dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com

# -> Kexample.com.+007+12345.key & .private



# 2. Zone signieren

dnssec-signzone -o example.com -k Kexample.com.+007+12345.key db.example.com

# Ergebnis: db.example.com.signed

In named.conf.local einbinden:

zone "example.com" {

    type master;

    file "/etc/bind/db.example.com.signed";

    allow-update { none; };

};

Starten Sie BIND neu:

sudo systemctl restart bind9

Beispiel 5 – Überprüfen mit dig

# DNSSEC‑Abfrage

dig +dnssec example.com RRSIG

Wenn Sie ein RRSIG‑Record sehen, ist DNSSEC aktiv. Zusätzlich prüfen Sie die Kette mit dig +trace +dnssec example.com – hier sollten Sie keine SERVFAIL‑Meldung erhalten.

Meine Einschätzung

DNSSEC ist nicht optional, wenn Sie kritische Infrastrukturen betreiben. Der Aufwand ist zwar höher – Schlüsselrotation, DS‑Eintrag beim Registrar – aber das Sicherheits‑ROI ist enorm: Keine Cache‑Poisoning‑Angriffe mehr, weil jede Antwort kryptografisch verifiziert wird.

5. Häufige Fehler und Stolperfallen

6. Fazit & konkreter nächster Schritt

Wir haben gesehen, dass DoT und DoH den Transport schützen, DNSSEC aber die Daten selbst. Kein einzelnes Tool löst alle Probleme – ein Defense‑in‑Depth‑Ansatz ist nötig:

1. 
   DoT für interne Systeme (z. B. über stubby oder unbound).


2. 
   DoH für End‑User‑Devices, wenn Sie das Risiko von Netzwerk‑Filtern minimieren wollen.


3. 
   DNSSEC für jede produktive Zone, insbesondere für Unternehmens‑ und Cloud‑Domänen.

Konkreter nächster Schritt für Sie

Kurz: Installieren Sie heute stubby, konfigurieren Sie Ihren Resolver auf TLS 853 und prüfen Sie mit dig +tls. Danach aktivieren Sie DNSSEC für Ihre interne Zone und testen Sie mit dig +dnssec.

Durch diese drei Maßnahmen erhöhen Sie sofort die Vertraulichkeit, Integrität und Authentizität Ihrer DNS‑Infrastruktur – und verhindern, dass ein einfacher „DNS‑Poisoning‑Attacke“ Ihr Unternehmen teuer zu stehen kommt.

Bleiben Sie neugierig: DNS‑Sicherheit ist ein sich schnell entwickelndes Feld. Schauen Sie regelmäßig in die Release‑Notes von Unbound, BIND und den großen DoH‑Anbietern. Und vergessen Sie nie: Das schönste Tool ist das, das Sie täglich einsetzen und kontinuierlich überprüfen.