DNS

Chute verwendet einen benutzerdefinierten DNS-Client, um erweiterte Funktionen zu unterstützen. Er kann sich anders verhalten als der DNS-Client Ihres Betriebssystems.

Chute fungiert als DNS-Server, wenn eine Sitzung die DIRECT-Regel anwendet. Chute überprüft zuerst den DNS-Eintrag des Hosts und initialisiert dann den Socket mit der im DNS-Eintrag zurückgegebenen IP. Mit dieser Methode umgehen alle Sitzungen, die die DIRECT-Regel anwenden, die System-DNS-Konfiguration und werden über den Chute-DNS-Server geleitet.

Chute iOS konfiguriert den System-DNS-Server als Chute-DNS-Server.

Upstream-DNS-Server

Chute verwendet standardmäßig die DNS-Serveradressen des Betriebssystems. Sie können diese mit DNS-Server, DoH (DNS-over-HTTPS), DoT (DNS-over-TLS), DoQ (DNS-over-QUIC) und DoH3 (DNS-over-HTTP/3)-Diensten über die Option 'dns-server' überschreiben.

DNS-Abschnitt

DNS-Optionen werden normalerweise in [General] geschrieben, können aber gleichwertig unter einem Abschnitt [DNS] der obersten Ebene stehen: dns-server, doh (Aliase doh-server, doh-service), dot, doq, doh3, direct-dns-server, proxy-dns-server, encrypted-dns-server, allow-dns-svcb, encrypted-dns-follow-outbound-mode, hijack-dns und always-real-ip verhalten sich in beiden Abschnitten gleich. Genau derselbe Abschnitt akzeptiert außerdem Zeilen für die lokale DNS-Zuordnung, also die domainbezogene Form aus [Host], sodass beide Zeilenformen in einem Abschnitt nebeneinander bestehen können. Jeder andere Schlüssel wird zunächst als Zuordnungszeile gelesen: Ein key = value ohne IP-Adresse und ohne Präfix der Art server: wird zu einem Alias, sodass ein hierher verirrter [General]-Schlüssel — optimistic-dns = false — den Namen optimistic-dns stillschweigend auf false abbildet, statt einen Fehler zu melden. Nur eine Zeile, die auch der Zuordnungs-Parser zurückweist, wird mit einem Hinweis im Protokoll ignoriert. fallback-dns-server und encrypted-dns-skip-cert-verification werden hier ebenfalls gelesen.

[DNS]
doh = https://dns.google/dns-query
always-real-ip = *.lan
*.example.com = server:1.1.1.1

Details

Chute fragt alle DNS-Server gleichzeitig ab, um die Leistung zu verbessern, ähnlich wie dnsmasq mit dem Parameter '--all-servers'. Die erste Antwort der Server wird verwendet. Die Chute iOS-App und Chute Dashboard zeigen an, welcher Server zuerst antwortet. Wenn Chute innerhalb von 2 Sekunden keine Antwort erhalten hat, werden alle Server erneut abgefragt. Beachten Sie, dass nur DNS-Server-, DoT- und DoQ-Upstreams an den Wiederholungen teilnehmen; DoH, DoH3 und syslib werden nur in der ersten Runde abgefragt. Nach 3 Wiederholungen (insgesamt 4 Versuchen) oder 10 Sekunden gibt Chute auf und meldet einen DNS-Fehler. Diese Wiederholungen gelten für Chutes eigene Abfragen und für die Fragen, die es von der TUN-Schnittstelle und dem SOCKS5-UDP-Relay übernimmt; eine Frage, die direkt an den DNS-Port gesendet wird, an dem Chute lauscht, geht einmal an die Server und wird nicht wiederholt, sodass die eigene Wiederholung ihres Clients greift.

Welche Server gefragt werden, hängt vom Namen ab. Eine Domain, deren Regelurteil DIRECT lautet, verwendet direct-dns-server, sofern gesetzt; die Hostnamen der Proxy-Server verwenden proxy-dns-server; eine Domain mit einer lokalen DNS-Zuordnung verwendet den dort zugewiesenen Server; alles andere verwendet den Hauptpool (dns-server, doh, dot, doq, doh3). direct-dns-server bedient die Auflösungen, die Chute durchführt, wenn es eine direkte Verbindung aufbaut, und die Frage einer App nur dann, wenn die Frage Chutes Resolver erreicht: Über TUN gestellte A- und AAAA-Fragen der Apps werden stattdessen mit Fake-IPs beantwortet. Liefert ein spezieller Pool keine Antwort, wird die Anfrage über den Hauptpool wiederholt; liefert der Hauptpool keine Antwort, wird fallback-dns-server einmal gefragt, bevor der Fehler gemeldet wird.

Einige Domainnamen können leistungsschwache autoritative Nameserver haben, was dazu führt, dass Upstream-DNS-Server aufgrund von Server-Zeitüberschreitungen oder anderen Konnektivitätsproblemen leere Antworten zurückgeben. Chute meldet einen leeren DNS-Fehler, wenn Upstream-DNS-Server explizit leere DNS-Antworten zurückgeben oder wenn einige Server leere Antworten zurückgeben und andere nicht innerhalb von 3 Sekunden antworten.

Einige DNS-Einträge haben aufgrund der Konfiguration eine sehr kurze TTL; Chute erzwingt eine Mindest-TTL von 60 Sekunden: kürzere TTLs werden auf 60 Sekunden angehoben. Optimistisches DNS ist standardmäßig aktiviert — das zwischengespeicherte DNS-Ergebnis wird sofort zurückgegeben, während es im Hintergrund aktualisiert wird. Es kann über optimistic-dns = false deaktiviert werden. Eine NXDOMAIN-Antwort, die den SOA-Eintrag der Zone mitführt, wird ebenfalls zwischengespeichert, und zwar für die Zeit, die dieser Eintrag für negative Antworten angibt, begrenzt auf 60 Sekunden bis einen Tag; bis sie abläuft, wird der Name mit NXDOMAIN beantwortet, ohne die Server erneut zu fragen. Eine NXDOMAIN-Antwort des Upstream-Servers wird nicht zwischengespeichert, wenn der Name durch eine [Host]-Zuordnung oder einen Alias abgedeckt ist; die Zuordnung oder der Alias hat Vorrang.

Der DNS-Cache hält 200 Einträge. Unter iOS und tvOS darf er nie unbegrenzt wachsen: Die Anforderung eines unbegrenzten Caches wird abgelehnt, der Cache mit 200 Einträgen bleibt, und ein Hinweis meldet das.

Wenn IPv6 verfügbar und aktiviert ist, sendet der Chute-DNS-Client sowohl A- als auch AAAA-Fragen an Upstream-DNS-Server. Die erste zurückgegebene A- oder AAAA-Antwort wird verwendet. In Single-Stack-Netzwerken wird eine Antwort für eine Adressfamilie, die derzeit nicht routbar ist, zugunsten der anderen Familie zurückgehalten und nur als Fallback verwendet, wenn die andere Familie nichts liefert.