Lassen Sie uns sicheres DNS wieder schnell machen. DNS über QUIC / Sudo Null IT News

DNS (Domain Name System Protocol) ist eines der wichtigsten Infrastrukturprotokolle zur Unterstützung des Internets und wurde ursprünglich für maximale Performance und die Möglichkeit der verteilten Speicherung einer unbegrenzten Anzahl von Domainzonen entwickelt. DNS kann über das UDP-Protokoll betrieben werden, was den Aufwand für den Verbindungsaufbau und den übermäßigen Datenverkehr im Netzwerk reduziert. Eines der wichtigsten Probleme war jedoch die Sicherheit des Datenaustauschs, da der Client in der ursprünglichen Version des Protokolls die Richtigkeit der Informationen nicht überprüfen kann und dies zur Substitution von IP-Adressen durch Angreifer mit Umleitung des Clients zu einem führen kann Phishing-Site.

Um dieses Problem zu lösen, wurden DNSSEC-Erweiterungen eingeführt, um eine digitale Antwortsignatur zu generieren. Die Anfrage und die Antwort selbst waren jedoch nicht verschlüsselt, was dazu verwendet werden könnte, den Zugriff auf bestimmte Domänen zu beschränken oder Statistiken über den Zugriff auf Hosts auf Transitknoten zu erhalten. Ein Teil der Lösung für dieses Problem ist die Verwendung von DNS-over-TLS (DoT, verwendet TLS zum Verschlüsseln von UDP-Datagrammen) und DNS-over-HTTPS (DoH, sendet Anfragen und Antworten über eine HTTPS-Verbindung), die über TCP laufen. Im ersten Fall ist die Anfrage kompakter (kann aber durch Verkehrsanalyse erkannt werden); fügt Header hinzu (die zum Verfolgen und Abfangen von Cookies verwendet werden können). Aber gibt es eine Möglichkeit, die Vorteile von UDP und DoH zu kombinieren? Wir treffen auf DNS-over-QUIC, das in genehmigt wurde RFC9250 als vorgeschlagener Standard.

Lassen Sie uns zunächst ein paar Worte zum QUIC-Protokoll (Quick UDP Internet Connections, RFC9000). Es wurde ursprünglich 2012 von Google entwickelt und nutzt das UDP-Transportprotokoll, um verschlüsselte Datenströme zu übertragen. Das Protokoll reduziert die Kosten für den Verbindungsaufbau erheblich, unterstützt die Verbindungsmigration (die Möglichkeit, die IP-Adresse und den Port beim Wechseln von Netzwerken dank des Vorhandenseins einer Stream-ID zu ändern), ermöglicht das Multiplexen mehrerer Datenströme, ermöglicht die Möglichkeit von erneutes Senden einzelner beschädigter Fragmente (da die Verschlüsselung an der Fragmentgrenze ausgerichtet ist und Daten auch dann entschlüsselt werden können, wenn Nachrichten teilweise verloren gehen). Das QUIC-Protokoll ist das Herzstück des kürzlich genehmigten HTTP/3 (RFC9114). Alle Chromium-basierten Browser unterstützen QUIC (mit gesetztem enable-quic-Flag), auch Firefox ab Version 80.0 (mit der Konfiguration network.http.http3.enabled).

Das DNS-over-QUIC-Protokoll (im Folgenden als DoQ bezeichnet) verwendet TLS 1.3 und kann verwendet werden, um Anfragen von Clients an DNS-Server und DNS-Server-Interaktionen zu senden (einschließlich der Übertragung von Zonenaktualisierungen und Anfragen zwischen rekursiven und autoritativen Servern). DNS-Anfragen werden über QUIC-Streams gerendert und die Serverantwort (unabhängig vom Volumen) wird vollständig im selben Stream wie die Anfrage zurückgegeben. In diesem Fall können Anfragen asynchron verarbeitet werden, ohne dass auf Antworten auf zuvor eingegangene Anfragen gewartet werden muss. Ein Client kann mehrere Anfragen durch verschiedene Threads senden (die Anzahl ist begrenzt durch Governance-Mechanismen serverseitige Verbindung).

Da die Interaktion über QUIC im Allgemeinen für DNS-Anfragen und HTTP-Nachrichten identisch ist, können Sie DNS-Anfragen vor einer möglichen Paketfilterung auf Transportprotokollebene schützen (zusätzlich verwendet es Füllung QUIC-Pakete, um mögliche Verkehrsanalysen zu vermeiden). Um einen DNS-Amplification-Angriff zu verhindern (verursacht durch die Tatsache, dass die Client-Adresse im UDP-Datagramm die Adresse des Opfers ersetzen kann, an das die Antwort gesendet wird), stellt QUIC einen Mechanismus bereit Validierung Adressen. Da QUIC das UDP-Protokoll verwendet, gibt es keine Verbindungsaufbauphase und eine Antwort kann sofort nach der Protokollaushandlung empfangen werden (etwas langsamer als im Fall einer unsicheren DNS-UDP-Verbindung), aber alle QUIC-Sitzungsschutz- und Sitzungsverwaltungsmechanismen bleiben verfügbar ( einschließlich der Fähigkeit, die Sitzung fortzusetzen, wenn sich die IP-Adresse des Clients ändert, ohne Threads zu unterbrechen). Sie können die Leistung von DoQ mit anderen sicheren Transportarten in vergleichen Dies Arbeit.

Beim Verbindungsaufbau über QUIC meldet der Server die Unterstützung des Protokolls durch Senden des doq ALPN-Tokens. Standardmäßig muss der Server auf Anfragen auf UDP-Port 853 antworten, kann aber auf jeden beliebigen Port (z. B. 443) konfiguriert werden. DNS-Requests werden immer mit Message ID = 0 gesendet, Request und Response dürfen 65535 nicht überschreiten (da die Länge auf ein 16-Bit-Feld begrenzt ist).

DNS-over-QUIC-Unterstützung ist derzeit nicht in stabilen Browser-Builds verfügbar, Sie können sie jedoch verwenden DNS-Proxy um einen Proxy-Server zu implementieren, der sich mit allen sicheren DNS-Protokollen (DoT, DoH, DoQ und DNSCrypt) verbinden kann. Als Alternative zu DoQ kann DoH3 betrachtet werden (Weiterleitung von DNS-Anfragen und -Antworten über eine HTTP/3-Verbindung, aber es ist langsamer als DoQ aufgrund des Aufbaus einer HTTP/3-Verbindung und hat ähnliche Nachteile wie DoH – Weiterleitung von Headern und Cookies). Gleichzeitig sollte beachtet werden, dass Android 11+-Telefone bereits vorhanden sind Unterstützung Übergeben von DNS-Abfragen über http3 mit Google Play-Systemaktualisierung. Für DoH3 können Sie Cloudflare-DNS-Server verwenden: https://cloudflare-dns.com/dns-query. Um DoH3 in Chrome für Android zu konfigurieren, können Sie zum Menü gehen, Einstellungen → Datenschutz und Sicherheit → Sicheres DNS verwenden auswählen und die Adresse des Anbieters (z. B. Cloudflare) angeben. Sie können das für den Zugriff auf die Seite und DNS verwendete Protokoll auf der Testseite überprüfen (wird nach dem Neuladen der Seite ausgelöst).

Obwohl es keine offizielle DoQ-Unterstützung gibt, können Sie einen Proxy-DNS-Server in Ihrem lokalen Netzwerk oder auf Ihrem Computer installieren, der Anfragen von Anwendungen empfängt und sie über DoQ an ein externes DNS weiterleitet (z. RouteDNS, doq-Proxy oder DNSProxy). DNSProxy kann über einen Docker-Container ausgeführt werden (z. B. chenhw2/dnsproxy) oder über go install installiert. Die wichtigsten Optionen für uns werden sein:

  • -u – Geben Sie Upstream-DNS-Server an (tls://ip für DoT-Verwendung, für DoH, quic://host für DoQ), mehrere Adressen können durch Kommas getrennt aufgelistet werden. Bitte beachten Sie, dass Sie bei der Verwendung von DNS-Namen zur Verbindung mit einem externen Server (z. B. https oder DoQ) für eine erfolgreiche Erstverbindung (Bootstrap) den Hostnamen auf jede mögliche Weise mit der IP-Adresse verknüpfen müssen (z. B. durch Angabe von Fallback DNS oder mit –add -host beim Starten des Containers);

  • -p – Port, um auf lokale DNS-Anfragen zu lauschen (Sie können auch Verbindungen über DoH (-s), DoT (-t), DoQ (-q) und DNSCrypt (-y) zulassen). In diesem Fall müssen Sie das Zertifikat übergeben und privater Schlüssel zur Verwendung in TLS oder Verschlüsselung für HTTPS/QUIC-Anwendungsprotokolle);

  • –cache – DNS-Cache aktivieren;

  • –fastest-addr – gibt die schnellste Adresse zurück (falls es mehr als eine gibt).

Lassen Sie uns den DNS-Proxy starten. Wir werden AdguardDNS verwenden (Sie können jedoch beispielsweise Ihren eigenen Server installieren CoreDNS, Schnellhund, ungebunden oder doqd).

docker run –restart=always –name dnsproxy -p 53:53/udp -p 53:53 \ –add-host dns.adguard.com:94.140.15.15 -d \ -e “ARGS=-l 0.0. 0.0 –cache –fastest-addr -u quic://dns.adguard.com -v”\chenhw2/dnsproxy

Jetzt können wir zur Verwendung von lokalem DNS wechseln:

  • Windows – netsh interface ipv4 set dnsservers “Wi-Fi” static 127.0.0.1 primary or Set-DnsClientServerAddress -InterfaceAlias ​​​​”Wi-Fi” -ServerAddresses “127.0.0.1” -Validate for PowerShell (mit Administratorrechten, Schnittstellenname evtl anders, die Liste kann über netsh interface show interface abgerufen werden);

  • Linux – sudo systemd-resolve –interface eth0 –set-dns 127.0.0.1 für SystemD-basierte Systeme oder ersetzen Sie Nameserver 127.0.0.1 in /etc/resolv.conf (Schnittstellenname kann variieren, siehe IP-Link-Show);

  • MacOS – sudo networksetup -setdnsservers Wi-Fi 127.0.0.1 (Schnittstellenname kann unterschiedlich sein, siehe sudo networksetup -listallnetworkservices).

Im Containerprotokoll (docker logs dnsproxy) können wir Anfragen und Antworten von Upstream-Dns-Servern sehen. Versuchen wir, eine Adressanfrage zu stellen: nslookup habr.ru und finden Sie heraus, dass der Proxy den Upstream-Server erfolgreich kontaktiert hat:

24.07.2022 11:59:59 1#5561 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy) [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; Opcode: QUERY, Status: NOERROR, ID: 2 ;; flags:rd; FRAGE: 1, ANTWORT: 0, BEHÖRDE: 0, ZUSÄTZLICH: 0 ;; FRAGETEIL: ;habr.ru. IN A 2022/07/24 11:59:59 1#5562 [debug] github.com/AdguardTeam/dnsproxy/upstream.(*bootstrapper).createDialContext.func1(): Anwählen von 94.140.15.15:853 2022/07/24 11:59:59 1#5562 [debug] github.com/AdguardTeam/dnsproxy/upstream.(*bootstrapper).createDialContext.func1(): Dialer hat die Verbindung zu 94.140.15.15:853 in 51,3 µs erfolgreich initialisiert 2022/07/24 11:59:59 1#5561 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).replyFromUpstream(): RTT: 25.3216ms 24.07.2022 11:59:59 1#5561 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; Opcode: QUERY, Status: NOERROR, ID: 2 ;; Flaggen: qr rd ra; FRAGE: 1, ANTWORT: 1, BEHÖRDE: 0, ZUSÄTZLICH: 0 ;; FRAGETEIL: ;habr.ru. IN EINEM ;; ANTWORTTEIL: habr.ru. 3600 IN A 178.248.233.33

Der Übergang zur Verwendung von DoQ reduziert im Allgemeinen die Zeit, die zum Ausführen von DNS-Abfragen benötigt wird, schützt den Inhalt der Anfrage vor dem Abfangen und Analysieren auf zwischengeschalteten Geräten und vermeidet mögliches Adress-Spoofing in der Antwort. Darüber hinaus funktionieren DoQ (und DoH3) gut in Netzwerkwechselumgebungen (z. B. zwischen verschiedenen Wi-Fi-Netzwerken oder zwischen Wi-Fi und Mobilfunk), was besonders für mobile Clients wichtig ist.

Eine detaillierte Liste öffentlicher Server, die DoQ, DoH3 unterstützen, Informationen zur Protokollunterstützung durch Browser, Client- und Serverimplementierungen von sicherem DNS finden Sie unter diese Seite.

Heute Abend findet bei OTUS eine offene Session „IS-IS. Filtern von LSP-Paketen“, wobei die Teilnehmer:

  • Vergleichen Sie die Arten und Möglichkeiten der Filterung im Protokoll;

  • Richten Sie die Filterung sowohl bei L1- als auch bei L2-Interaktionen zwischen Geräten ein;

  • Bestimmen Sie die Vor- und Nachteile jeder Option.

Registrieren Verknüpfung.

Similar Posts

Leave a Reply

Your email address will not be published.