Ohne eine vorläufige Ankündigung begann DNS over TLS plötzlich
mit der Arbeit an
8.8.8.8 . Zuvor hatte Google nur die Unterstützung von
DNS über HTTPS angekündigt
.Der öffentliche Resolver von CloudFlare mit der IP-Adresse
1.1.1.1 unterstützt seit Projektstart DNS über TLS.
Warum ist es notwendig?
Mit dem klassischen DNS-Schema können Anbieter ihre schmutzigen Pfoten in Ihre DNS-Pakete crawlen, die von Ihnen angeforderten Domänen durchsuchen und die Antworten nach Belieben austauschen. Betrüger tun dasselbe und ersetzen Resolver auf gehackten Routern, um den Benutzer auf einen gefälschten Server zu leiten.
Bei DNS über TLS / HTTPS werden Anforderungen in einem verschlüsselten Tunnel gesendet, sodass der Anbieter die Anforderung nicht ersetzen oder anzeigen kann.
Und mit dem Aufkommen der Domainnamenverschlüsselung in X.509-Zertifikaten (
ESNI ) wird es unmöglich, über DPI über SNI (Server Name Indication, ein spezielles Feld, in dem der Domainname im ersten TLS-Paket übertragen wird) zu blockieren, die jetzt von einigen großen Anbietern verwendet werden.
Wie funktioniert es?
Es wird eine TLS-Verbindung zum TCP: 853-Port hergestellt, und das Resolver-Zertifikat wird wie HTTPS in einem Browser mithilfe von Systemstammzertifikaten überprüft. Dadurch müssen keine Schlüssel mehr manuell hinzugefügt werden. Innerhalb des Tunnels wird eine regelmäßige DNS-Abfrage durchgeführt. Dies verursacht weniger Overhead als DNS über HTTPS, wodurch der Anforderung und Antwort HTTP-Header hinzugefügt werden.
Leider ist derzeit nur in Android 9 (Pie) die Unterstützung für DNS über TLS in den System Resolver integriert.
Setup-Anweisungen für Android 9 .
Für andere Systeme wird vorgeschlagen, einen Daemon eines Drittanbieters zu verwenden und den Systemauflöser an localhost (127.0.0.1) zu senden.
Setup unter macOS
Lassen Sie uns DNS über TLS auf der neuesten Version von macOS am Beispiel des
Knotenauflösers analysieren
Installation
brew install knot-resolver
Standardmäßig funktioniert knot wie ein normaler rekursiver Resolver wie dnsmasq.
Konfiguration bearbeiten
nano /usr/local/etc/kresd/config
Und am Ende der Datei hinzufügen:
policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} })))
Infolgedessen sieht meine Konfiguration folgendermaßen aus:
Spoiler erweitern -- Config file example useable for personal resolver. -- The goal is to have a validating resolver with tiny memory footprint, -- while actively tracking and refreshing frequent records to lower user latency. -- Refer to manual: https://knot-resolver.readthedocs.io/en/latest/daemon.html#configuration -- Listen on localhost (default) -- net = { '127.0.0.1', '::1' } -- Drop root privileges -- user('knot-resolver', 'knot-resolver') -- Auto-maintain root TA trust_anchors.file = 'root.keys' -- Load Useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'hints', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Smaller cache size cache.size = 10 * MB policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} })))
Weitere Informationen zur Authentifizierung von Hostnamen und TLS-Zertifikaten.Der
hostname Parameter ist in diesem Fall der Common Name (CN) oder der Subject Alt Name (SAN) des Zertifikats. Dies ist der Domänenname, für den das Zertifikat ausgestellt wurde. Es überprüft die Authentizität des Serverzertifikats.
Hier sind die SAN-Werte für das Zertifikat, das beim Herstellen einer Verbindung zu 8.8.8.8:853 verwendet wird
dns.google 8888.google 8.8.4.4 8.8.8.8 2001:4860:4860:0:0:0:0:64 2001:4860:4860:0:0:0:0:6464 2001:4860:4860:0:0:0:0:8844 2001:4860:4860:0:0:0:0:8888
Jeder dieser Werte kann als Hostname-Parameter verwendet werden. Wenn Sie Ihren eigenen öffentlichen rekursiven Resolver bereitstellen, ist es unwahrscheinlich, dass Sie ein X.509-Zertifikat für eine IP-Adresse ausstellen können. Daher müssen Sie im Parameter hostname einen Domänennamen angeben.
Daemon-Start
sudo brew services start knot-resolver
Mit dem folgenden Befehl können Sie überprüfen, ob der Dämon erfolgreich gestartet wurde:
sudo lsof -i -P -n | grep kresd
Der kresd-Prozess sollte Port 53 auf localhost überwachen.
Wenn etwas schief gelaufen ist, sehen Sie sich das Fehlerprotokoll an:
cat /usr/local/var/log/kresd.log
Überprüfen des Resolver-Betriebs
dig @127.0.0.1 habr.com
Überprüfen Sie, ob der lokale Resolver richtig reagiert.
Installation als System Resolver
Wenn alles richtig funktioniert, können Sie in den Eigenschaften des Netzwerkadapters einen Systemauflöser zuweisen:
UPDWas ist der Unterschied zwischen DNSCrypt, DNSSEC, DNS über TLS / HTTPS?
DNSCrypt kann mit UDP und TCP arbeiten. Verbindung zu Port 443. Für die Verschlüsselung wird ein eigenes Protokoll verwendet, das sich von HTTPS unterscheidet. Es kann einfach mit DPI hervorgehoben werden. Es handelt sich vielmehr um einen Entwurf, der vor der Einführung von DNS über TLS / HTTPS getestet wurde, da er keinen RFC enthält, dh kein offizieller Internetstandard ist. Höchstwahrscheinlich wird es bald vollständig durch Letzteres ersetzt.
DNS über TLS (DoT) - Die TCP-Verbindung erfolgt über Port 853. Eine reguläre DNS-Anforderung wird innerhalb des Tunnels übertragen. Der Anbieter sieht, dass dies eine DNS-Abfrage ist, kann diese jedoch nicht stören. Wenn andere Dinge gleich sind, sollte in DNS über TLS für jede Anforderung etwas weniger Overhead anfallen als in über HTTPS.
DNS über HTTP (DoH) - TCP-Verbindung zu Port 443, ähnlich wie bei
normalem HTTPS. Darin befindet sich ein anderes Anforderungsformat mit HTTP-Headern. Für den Anbieter wird eine solche Anforderung jedoch als normale HTTPS-Verbindung angesehen. Ich nehme an, dieses Protokoll wurde erfunden, falls DNS-Abfragen an fremde Server blockiert werden, um sie unter normalem Webverkehr zu maskieren. Außerdem können Browser Domänen selbst auflösen und keinen abnormalen Datenverkehr erzeugen.
Tatsächlich sind DNS über HTTPS und über TLS dasselbe mit einem etwas anderen Anforderungsformat. Beide Protokolle werden als Standards akzeptiert und haben einen RFC. Höchstwahrscheinlich werden wir in naher Zukunft die Massenverteilung von beiden sehen.
DNSSEC ist ein Protokoll zum digitalen Signieren von DNS-Einträgen. Es hat nichts mit Verschlüsselung zu tun, da alle Anfragen im Klartext übertragen werden. Es kann sowohl über das alte klassische DNS-Protokoll, d. H. UDP / TCP an Port 53, als auch innerhalb von DNS über TLS / HTTPS funktionieren. Der Zweck von DNSSEC besteht darin, einen DNS-Eintrag zu authentifizieren. Ein Domänenbesitzer kann den Stammservern seiner Domänenzone einen öffentlichen Schlüssel hinzufügen und alle Einträge im NS-Server-Assistenten signieren. Tatsächlich wird jedem DNS-Eintrag, beispielsweise A-Eintrag oder MX-Eintrag, ein weiterer Eintrag vom Typ RRSIG hinzugefügt, der die Signatur enthält. Mit der DNSSEC-Validierungsprozedur auf einem rekursiven Resolver können Sie feststellen, ob dieser Eintrag tatsächlich vom Domäneninhaber erstellt wurde.
Ein detaillierterer Vergleich aller Protokolle
dnscrypt.info/faq (Absatz Andere Protokolle)