DoH vs. DoT vs. Standard-DNS
Standard-DNS (UDP Port 53):
Client -> [unverschlüsselt] -> DNS-Server
ISP oder jeder im Netzwerkpfad kann mitlesen. MITM möglich.
DNS over TLS (DoT, Port 853):
Client -> [TLS-Tunnel] -> DNS-Server
Verschlüsselt, aber als DNS-Traffic erkennbar (eigener Port).
DNS over HTTPS (DoH, Port 443):
Client -> [HTTPS, wie normaler Web-Traffic] -> DNS-Server
Verschlüsselt UND nicht von normalem HTTPS-Traffic unterscheidbar.
Der Unterschied zwischen DoT und DoH ist nicht primär die Verschlüsselung — die ist bei beiden TLS-basiert und gleich stark. Der Unterschied liegt in der Sichtbarkeit: DoT auf Port 853 lässt sich von einer Firewall gezielt erlauben oder blockieren, weil der Port eindeutig ist. DoH auf Port 443 sieht für eine Firewall aus wie jeder andere HTTPS-Aufruf — das macht es für Endnutzer schwerer zu blockieren, aber auch für Unternehmens-IT schwerer, DNS-Anfragen zentral zu kontrollieren und zu filtern.
Warum das für Unternehmen relevant ist, nicht nur für Privatsphäre
Wer im Unternehmensnetz DNS-basierte Filterung einsetzt (Malware-Domains blocken, Content-Filter, DNS-Logging für Security-Monitoring), muss DoH bewusst berücksichtigen — Anwendungen, die eigenständig DoH nutzen (manche Browser tun das standardmäßig), umgehen sonst den zentralen DNS-Resolver komplett. Die saubere Lösung ist nicht, DoH zu verbieten, sondern zentral selbst DoT/DoH zum gewünschten Upstream-Resolver zu nutzen und clientseitiges DoH über Gruppenrichtlinien zu deaktivieren.
Empfohlene DoH/DoT Provider
Cloudflare:
DoH: https://cloudflare-dns.com/dns-query
DoT: 1dot1dot1dot1.cloudflare-dns.com
Quad9 (Schweizer gemeinnützige Stiftung, DSGVO-freundlich):
DoH: https://dns.quad9.net/dns-query
DoT: dns.quad9.net
Besonderheit: blockiert bekannte Malware-Domains automatisch
NextDNS (individuell konfigurierbar):
DoH: https://dns.nextdns.io/ACCOUNT_ID
eigene Blocklisten, Logging, Statistiken
Linux systemd-resolved (DoT)
# /etc/systemd/resolved.conf
cat > /etc/systemd/resolved.conf << 'EOF'
[Resolve]
DNS=9.9.9.9#dns.quad9.net 2620:fe::fe#dns.quad9.net
FallbackDNS=1.1.1.1#cloudflare-dns.com
DNSOverTLS=opportunistic
DNSSEC=yes
EOF
systemctl restart systemd-resolved
resolvectl status
resolvectl query firma.de
# DNS-Traffic prüfen (sollte Port 853 statt 53 zeigen)
ss -tlnp | grep :853
DNSOverTLS=opportunistic versucht DoT und fällt bei Fehlschlag automatisch auf unverschlüsseltes DNS zurück — sicherer, aber mit Fallback-Lücke. DNSOverTLS=yes erzwingt Verschlüsselung strikt, kann aber bei Netzwerken mit blockiertem Port 853 zu kompletten DNS-Ausfällen führen. Für Produktivsysteme ist die strikte Einstellung nur mit vorherigem Test im Zielnetz zu empfehlen.
Pi-hole mit DoH (Cloudflared)
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
dpkg -i cloudflared-linux-amd64.deb
cat > /etc/systemd/system/cloudflared.service << 'EOF'
[Unit]
Description=Cloudflare DoH Proxy
[Service]
ExecStart=/usr/local/bin/cloudflared proxy-dns --port 5053 \
--upstream https://dns.quad9.net/dns-query
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
systemctl enable --now cloudflared
Pi-hole Admin -> Settings -> DNS -> Custom 1: 127.0.0.1#5053. Damit filtert Pi-hole weiterhin wie gewohnt (Werbe-/Tracker-Blocklisten), leitet aber alle nicht-lokal beantworteten Anfragen verschlüsselt an den Upstream weiter.
FAQ
Ist DoH sicherer als DoT?
Beide verschlüsseln den DNS-Traffic gleichwertig. DoH ist schwerer zu blockieren, da es wie normaler HTTPS-Traffic aussieht. DoT ist auf Port 853 leichter von Firewalls gezielt zu identifizieren und zu kontrollieren — was aus Unternehmenssicht auch ein Vorteil sein kann, nicht nur eine Einschränkung.
Kann mein ISP DoH blockieren?
Theoretisch durch Blockieren der DoH-Server-IPs, aber das ist aufwändig, trifft viele legitime Dienste gleichzeitig und ist in Deutschland unüblich.
Fazit
DoH und DoT verschlüsseln DNS-Anfragen und schließen damit eine reale Lücke im sonst unverschlüsselten Standard-DNS. Für Unternehmen ist die zentrale, kontrollierte Nutzung (über systemd-resolved oder Pi-hole+cloudflared) der richtige Weg — nicht das Verbieten, sondern das bewusste Steuern verschlüsselter DNS-Anfragen.
Ich richte verschlüsselte, zentral kontrollierte DNS-Infrastruktur für Unternehmen in Heidelberg, Mannheim und der Rhein-Neckar-Region ein. Jetzt anfragen.