DNS-Server

Sie können diese Option verwenden, um die DNS-Einstellungen des Systems zu überschreiben. Chute unterstützt DNS-Server, DoH (DNS-over-HTTPS), DoT (DNS-over-TLS), DoQ (DNS-over-QUIC) und DoH3 (DNS-over-HTTP/3)-Dienste.

[General]
dns-server = 8.8.8.8, 8.8.4.4
doh = cloudflare, google, 1111
dot = dns.google, cloudflare-dns.com
doq = dns.adguard.com
doh3 = https://dns.google/dns-query

Sie können das Schlüsselwort system verwenden, um zusätzliche DNS-Server zu den Systemeinstellungen hinzuzufügen. (Doppelte Server werden ignoriert)

Sie können das Schlüsselwort syslib verwenden, um das DNS-Ergebnis mit der systemeigenen API zu erhalten. Unter macOS wird syslib auf Pool-Ebene übersprungen, solange die TUN-Schnittstelle aktiv ist, da der System-Resolver dann auf Chute selbst zeigt; server:syslib in [Host] und der .local-Pfad verwenden es weiterhin.

[General]
dns-server = system, syslib, 8.8.8.8, 8.8.4.4

Ein Eintrag darf einen Port tragen — 192.0.2.53:5353 bzw. [2001:db8::1]:5353 für IPv6. Hostnamen sind in dns-server nicht erlaubt; für einen Resolver, der über einen Namen erreicht wird, verwenden Sie DoH, DoT, DoQ oder DoH3. Diese dürfen auch direkt hier stehen, mit ihrem Schema — https://, tls://, quic:// oder h3:// — und kommen dann zu doh, dot, doq bzw. doh3 hinzu, wie bei encrypted-dns-server.

Derzeit gibt es 5 integrierte DoH-Dienste. Die Bezeichner sind kleingeschrieben und unterscheiden Groß-/Kleinschreibung:

• cloudflare (Cloudflare)
• google (Google)
• 1111 (1.1.1.1)
• securedns (SecureDNS)
• dnssb (DNS.SB)

Sie können auch Ihren persönlichen DoH-Dienst konfigurieren. Wenn Sie beispielsweise https://dns.nextdns.io/xxxxxx als Ihren NextDNS-DoH-Endpunkt verwenden, können Sie dies wie folgt konfigurieren:

[General]
doh = google, dns.nextdns.io/xxxxxx

Ein ungültiger DoH-Eintrag wird als Konfigurationsfehler gemeldet und die doh-Zeile wird abgelehnt.

Aus Kompatibilität mit Surge-Konfigurationen werden die Schreibweisen doh-server und doh-service als Aliase von doh akzeptiert.

DoT-Dienst (DNS-over-TLS)

Sie können DoT-Dienste konfigurieren, um DNS-Abfragen über TLS zu verschlüsseln.

[General]
dot = dns.google, cloudflare-dns.com

Jeder DoT-Diensteintrag sollte ein Domainname sein, der DNS-over-TLS unterstützt. Chute verbindet sich standardmäßig mit dem Hostnamen auf Port 853; ein Eintrag kann auch als host:port oder host:port:peer-name geschrieben werden (verwenden Sie [IPv6]:port für IPv6-Adressen), um den Port und den TLS-Peer-Namen zu überschreiben.

Wenn der DoT-Hostname nicht aufgelöst werden kann oder nicht erreichbar ist, wird er stillschweigend übersprungen.

Sie können DoT, DoH, DoQ, DoH3 und traditionelle DNS-Server in derselben Konfiguration mischen:

[General]
dns-server = system, 8.8.8.8
doh = cloudflare
dot = dns.google
doq = dns.adguard.com
doh3 = https://dns.google/dns-query

DoQ-Dienst (DNS-over-QUIC)

Sie können DoQ-Server konfigurieren, um DNS-Abfragen über QUIC zu verschlüsseln.

[General]
doq = dns.adguard.com

Jeder DoQ-Eintrag sollte ein Domainname oder eine IP-Adresse sein, die DNS-over-QUIC unterstützt. Standardmäßig wird Port 853 verwendet; ein Eintrag kann auch als host:port oder host:port:peer-name geschrieben werden (verwenden Sie [IPv6]:port für IPv6-Adressen), um den Port und den TLS-Peer-Namen zu überschreiben. Chute verwendet QUIC-Transport für DNS-Abfragen, was im Vergleich zu TCP-basierter DNS-Verschlüsselung eine geringere Latenz bietet.

Mehrere DoQ-Server können durch Kommas getrennt angegeben werden:

[General]
doq = dns.adguard.com, dns.nextdns.io

Wenn ein DoQ-Server nicht erreichbar ist, wird er stillschweigend übersprungen.

DoH3-Dienst (DNS-over-HTTP/3)

Sie können DoH3-Dienste für DNS-over-HTTPS mit HTTP/3 (QUIC)-Transport konfigurieren.

[General]
doh3 = https://dns.google/dns-query

Jeder DoH3-Eintrag sollte eine vollständige HTTPS-URL zu einem DNS-Resolver sein, der HTTP/3 unterstützt. Mehrere DoH3-Server können durch Kommas getrennt angegeben werden:

[General]
doh3 = https://dns.google/dns-query, https://cloudflare-dns.com/dns-query

DoH3 kombiniert den Datenschutz von DNS-over-HTTPS mit den Leistungsvorteilen des QUIC-Transports. Wenn ein DoH3-Server HTTP/3 nicht unterstützt oder nicht erreichbar ist, wird er stillschweigend übersprungen.

DNS über TCP

[General]
dns-server = tcp://8.8.8.8, tcp://[2001:4860:4860::8888]:53

Ein als tcp://IP[:port] geschriebener Resolver wird über TCP (RFC 7766) statt UDP gefragt; der Port ist standardmäßig 53. Nützlich in einem Netz, das DNS über UDP verwirft oder manipuliert. Er wird überall akzeptiert, wo ein normaler Resolver steht: in dns-server, den speziellen DNS-Pools, dem dns-server= eines Eintrags der SSID-Suspendierung und einer server:-Liste in [Host]. Wie ein normaler Resolver nimmt er nur eine IP-Adresse — keinen Hostnamen, kein system und kein syslib. Die Optionen pro Server, etwa #disable-qtype=, gelten wie gewohnt. Mit #proxy geht die Anfrage über diese Richtlinie, über TCP wie jede normale Anfrage über eine Richtlinie. encrypted-dns-server nimmt ihn nicht an.

Spezielle DNS-Pools

Neben dem Hauptpool oben gibt es drei optionale Pools für bestimmte Namen:

[General]
direct-dns-server = 223.5.5.5, https://doh.pub/dns-query, system
proxy-dns-server = 1.1.1.1, tls://dns.google
fallback-dns-server = 8.8.8.8

direct-dns-server

Löst Domains auf, deren Regelurteil DIRECT lautet: die Auflösungen, die Chute durchführt, wenn es eine direkte Verbindung aufbaut, und die Anfrage einer App, wenn diese Anfrage Chutes Resolver erreicht — eine, die an den DNS-Port gesendet wird, an dem Chute lauscht, ein in always-real-ip aufgeführter Name oder ein anderer Eintragstyp als A und AAAA. Über TUN gestellte A- und AAAA-Anfragen der Apps erreichen ihn nicht: Die Fake-IP-Schicht beantwortet sie direkt, ganz gleich, was die Regeln sagen. Herangezogen werden dabei nur Domain-Regeln: Eine Anfrage einer App nach einer Domain, auf die keine Domain-Regel passt — eine, deren Urteil von einer IP-Regel wie IP-CIDR oder GEOIP abhängt —, folgt FINAL, also diesem Pool, wenn FINAL DIRECT lautet, und dem Hauptpool, wenn es ein Proxy ist. Chutes eigene Auflösung für eine solche Domain verwendet den Hauptpool, da die Verbindung noch nicht an DIRECT gebunden ist. Ist der Schlüssel nicht gesetzt, beantwortet der Hauptpool alles.

proxy-dns-server

Löst die Hostnamen Ihrer Proxy-Server auf. Ist der Schlüssel nicht gesetzt, verwenden sie den Hauptpool.

fallback-dns-server

Wird einmal gefragt, wenn der Hauptpool überhaupt keine Antwort liefert, unmittelbar bevor die Auflösung fehlschlägt. Wie die anderen DNS-Schlüssel darf er in [General] oder in [DNS] stehen, und nur einmal.

Einträge in diesen Pools dürfen Transporte mischen: ip[:port], [v6][:port], system, syslib, eine DoH-URL (https://…), tls://host[:port] für DoT, quic://host[:port] für DoQ und h3://… für DoH3. Normale, DoH-, DoT-, DoQ- und DoH3-Einträge dürfen mit dem Suffix #proxy enden; system#proxy und syslib#proxy werden mit einer Warnung übersprungen. Liefert direct-dns-server oder proxy-dns-server keine Antwort, wird die Anfrage über den Hauptpool wiederholt. Jeder Schlüssel darf nur einmal vorkommen. Ein tcp://IP[:port]-Eintrag wird über DNS über TCP gefragt.

Zur Kompatibilität mit Shadowrocket wird dns-direct-system = true als direct-dns-server = system gelesen und in dieser Form gespeichert. Ebenso hängt dns-fallback-system = true system an fallback-dns-server an; deklariert das Profil auch fallback-dns-server, werden beide zu einem Pool zusammengeführt.

Optionen für verschlüsseltes DNS

encrypted-dns-server

encrypted-dns-server = https://dns.google/dns-query, tls://dns.google, quic://dns.adguard.com, h3://cloudflare-dns.com/dns-query

Surges gemeinsame Liste für verschlüsselte Resolver. Jeder Eintrag landet je nach Schema (https://, tls://, quic://, h3://) in doh, dot, doq oder doh3; tcp:// und andere Schemata werden mit einem Hinweis ignoriert. Für DNS über TCP gehört tcp:// stattdessen in dns-server oder einen speziellen Pool — siehe DNS über TCP.

encrypted-dns-follow-outbound-mode (Standard: false)

encrypted-dns-follow-outbound-mode = true

Lässt die Verbindungen zu DoH-, DoT-, DoQ- und DoH3-Upstreams wie jede andere Anfrage dem ausgehenden Modus und den Regeln folgen: direkt im Direktmodus, die ausgewählte Richtlinie im globalen Modus und im Regelmodus die Richtlinie der passenden Regel — PROTOCOL,DOH, PROTOCOL,DOT, PROTOCOL,DOQ und PROTOCOL,DOH3 greifen bei ihnen. Ein Upstream mit dem Urteil REJECT wird übersprungen. DoQ und DoH3 sprechen QUIC, ihre Verbindung läuft daher über das UDP-Relay der gewählten Richtlinie; trägt diese Richtlinie — bei einer Gruppe deren aktuelle Wahl — kein UDP, entscheidet udp-policy-not-supported-behaviour: REJECT, der Standard, überspringt den Upstream, DIRECT fragt ihn direkt.

encrypted-dns-skip-cert-verification (Standard: false)

encrypted-dns-skip-cert-verification = true

Die Zertifikate von DoH-, DoT-, DoQ- und DoH3-Upstreams werden nicht geprüft — gedacht für einen Resolver mit selbstsigniertem Zertifikat. Damit entfällt auch der Schutz davor, dass sich jemand als Resolver ausgibt.

Eine Anfrage über eine Richtlinie senden

[General]
dns-server = 1.1.1.1#proxy, 8.8.8.8#proxy=HK
doh = https://dns.google/dns-query#proxy=Proxy%20Group
doq = dns.adguard.com#proxy=HK

Ein Eintrag in dns-server, doh, dot, doq, doh3 oder einem der speziellen Pools darf mit #proxy oder #proxy=<policy> enden: Die Anfrage läuft dann über diese Richtlinie statt direkt. #proxy allein verwendet die für den globalen Modus ausgewählte Richtlinie oder, wenn es keine gibt, die Richtlinie der FINAL-Regel; #proxy=<name> nennt eine Richtlinie oder Gruppe, Leerzeichen werden als %20 geschrieben. Ein normaler DNS-Eintrag wechselt zu DNS über TCP, da nicht jede Richtlinie UDP weiterleiten kann. Ein DoQ- oder DoH3-Eintrag bleibt bei QUIC, und seine Verbindung läuft über das UDP-Relay der Richtlinie: Trägt die Richtlinie — bei einer Gruppe deren aktuelle Wahl — kein UDP, wird dieser Upstream mit einer Warnung übersprungen und nie direkt gefragt. Existiert die Richtlinie nicht oder ergibt sie REJECT, wird der Upstream übersprungen. Auflösungen des eigenen Hostnamens eines Proxy-Servers verwenden nie einen Upstream über einen Proxy.

Optionen pro Server

[General]
dns-server = 1.1.1.1#disable-ipv6, 8.8.8.8#disable-qtype=65
doh = https://dns.google/dns-query#h3=true, https://10.0.0.1/dns-query#skip-cert-verify=true

Dasselbe #-Fragment trägt auch Optionen, die nur für diesen einen Server gelten. Mehrere werden mit & verbunden, =true darf entfallen:

• h3=true — diesen DoH-Server über HTTP/3 statt HTTP/2 befragen.
• skip-cert-verify=true — das Zertifikat dieses einen Upstreams nicht prüfen. Für diesen Server entfällt damit der Schutz vor einem untergeschobenen Resolver, genau wie es das globale encrypted-dns-skip-cert-verification für alle tut.
• disable-ipv4=true / disable-ipv6=true — diesen Server nie nach A- / AAAA-Einträgen fragen.
• disable-qtype=65 — ihn nie nach diesem Eintragstyp fragen. disable-qtype-65 bedeutet dasselbe, und eine Kommaliste deaktiviert mehrere auf einmal: 8.8.8.8#disable-qtype=65,64 ist ein Eintrag mit beiden abgeschalteten Typen. Die Aufteilung in Einträge kennt das #-Fragment, sodass ein Komma außerhalb davon weiterhin Server trennt — 8.8.8.8#proxy, 1.1.1.1 sind zwei davon.

Ein Server, für den ein Fragetyp deaktiviert ist, wird übersprungen, bevor die Anfrage hinausgeht: er kostet weder einen Versuch noch eine Zeitüberschreitung. Lehnen alle Server des Pools den Typ ab, scheitert die Auflösung, statt auf Antworten zu warten, die niemand gesendet hat.

HTTPS- und SVCB-Anfragen

allow-dns-svcb = true

Standardmäßig aus: HTTPS-Anfragen (Typ 65) und SVCB-Anfragen (Typ 64) der Apps werden mit einer leeren NOERROR-Antwort beantwortet statt weitergeleitet, weil die Adresshinweise in diesen Einträgen es einer App erlauben würden, an Fake-IP und den Regeln vorbei zu verbinden. Mit true werden sie weitergeleitet. Der Schalter gilt auch für die Anfragen, die Apps über TUN senden, sowohl an Chutes eigene DNS-Adresse als auch an einen Resolver, den hijack-dns übernimmt. Chutes eigene ECH-Abfragen sind davon nicht betroffen.