Projektübersicht

Umstellung des gesamten DNS-Verkehrs im Heimnetz auf verschlüsselte Übertragung (TLS, Port 853), ergänzt um Bypass-Schutz per Firewall und automatisierte Blocklisten gegen Malware und Tracking.

1. Situation (Ausgangslage)

DNS-Anfragen laufen standardmässig im Klartext über Port 53. Der ISP kann damit jede aufgerufene Domain protokollieren, auch wenn die eigentliche Verbindung danach per HTTPS verschlüsselt ist. HTTPS schützt den Inhalt, DNS verrät das Ziel. Zusätzlich sind unverschlüsselte Anfragen anfällig für Man-in-the-Middle-Angriffe und DNS-Spoofing.

2. Task (Zielsetzung)

• Verschlüsselung: Alle DNS-Anfragen im Netzwerk über TLS (Port 853) absichern.
• Vertrauenswürdiger Resolver: Quad9 als Anbieter, gemeinnützige Schweizer Stiftung, keine Logs, integriertes Malware-Blocking.
• Bypass-Schutz: Verhindern, dass Geräte im LAN (IoT, Smart-TVs, Malware) die Firewall umgehen und direkt unverschlüsselt DNS-Server anfragen.
• Blocklisten: Tagesaktuelle Listen gegen Tracking, Phishing und Schadsoftware, automatisch aktualisiert.

3. Action (Umsetzung)

A. DoT-Konfiguration in OPNsense

Den lokalen Resolver Unbound-DNS auf der virtualisierten OPNsense-Instanz für DoT konfiguriert:

• Quad9 Primär (9.9.9.9) und Fallback (9.9.9.11) als DoT-Endpunkte eingetragen, mit Verify CN (dns.quad9.net) zur Zertifikatsprüfung.
• Forward First deaktiviert: Kein stiller Fallback auf unverschlüsseltes DNS bei Ausfall. Lieber kein Internet als unbemerkt offene DNS-Anfragen.
• Alte DNS-Einträge im System entfernt, damit OPNsense nicht unkontrolliert externe Server kontaktiert.

B. Firewall-Härtung (Bypass-Schutz)

Eine Block-Regel an Position 1 des LAN-Interfaces erstellt:

• Regel: Jeder DNS-Traffic (Port 53), der nicht an OPNsense selbst gerichtet ist, wird blockiert.
• Zweck: Smart-TVs, IoT-Geräte und Apps mit fest einprogrammierten DNS-Servern (z.B. Google 8.8.8.8) werden gezwungen, den sicheren Resolver zu nutzen.

C. Blocklisten und Automatisierung

• Blocklisten integriert (u.a. hagezi Multi PRO, Threat Intelligence, Fake/Scams).
• Automatischen Cron-Job eingerichtet: tägliche Aktualisierung um 03:00 Uhr, damit neue Bedrohungen zeitnah erfasst werden.

4. Result (Ergebnis & Verifikation)

Verifikation der Verschlüsselung

Die Wirksamkeit wurde mit drei unabhängigen Tests bestätigt:

• tcpdump Live-Test: Auf dem WAN-Interface ausschliesslich verschlüsselter Traffic auf Port 853 sichtbar, kein Port-53-Verkehr.
• Wireshark-Analyse: TLS v1.3 Handshake mit korrektem SNI (dns.quad9.net) bestätigt. Ab "Change Cipher Spec" vollständig verschlüsselt.
• DNS-Leak-Test: Nur Quad9-Server in den Ergebnissen, keine ISP-eigenen DNS-Server.

Fazit

Der ISP sieht nur noch eine verschlüsselte Verbindung zu Quad9 auf Port 853. Welche Domains aufgerufen werden, bleibt verborgen. Durch das Caching in Unbound entsteht im Alltag kein spürbarer Geschwindigkeitsverlust. Die Bypass-Regel stellt sicher, dass kein Gerät im Netzwerk die Verschlüsselung umgehen kann.

Lessons Learned

• Bypass-Gefahr unterschätzt: Ohne explizite Firewall-Regel ignorieren viele Geräte (Google Home, Smart-TVs) die DHCP-DNS-Zuweisung und tunneln Anfragen direkt an eigene Server.
• Fail-Safe vs. Verfügbarkeit: Die Entscheidung gegen Forward First bedeutet: bei Quad9-Ausfall fällt das Internet komplett aus. Das ist bewusst so gewählt, erfordert aber Monitoring der DNS-Erreichbarkeit.
• SNI bleibt offen: DoT schliesst das grösste Leck, aber der Hostname im TLS-Handshake (SNI) bleibt für den ISP sichtbar. Vollständiger Schutz erfordert zusätzlich ein VPN.