TUN inbound: Keep Windows' DNS Client from sending DoH/DoT outside the TUN

With strictRoute, only port 53 was kept inside the TUN. But Windows' DNS
Client service sends the queries for an interface's DNS servers out
through that interface, whatever the routes say, and since Windows 11
and Server 2022 it may send them over HTTPS or TLS, when that is set up
for the interface (as Windows Settings does) or for the server. Those
left through the physical link.

On those versions, the DNS Client service may now only connect through
the TUN, except for its mDNS and LLMNR. The filters recognize the
service by its SID in the token of its process, as Windows Firewall's
own rules for it do. Earlier versions only query port 53, and may run
the service in one process with others, so they get no such filters.
The port 53 rule stays, for the programs that query a resolver on the
local network themselves, and for those earlier versions.

Tested on Windows 11, elevated: with DoH set on Wi-Fi per adapter, per
network profile or by global auto-upgrade, none of the DNS Client's
connections left through Wi-Fi (WFP logged the drops by the new filter),
names still resolved through the TUN, mDNS and LLMNR still went out, and
other programs were unaffected, also in a real Xray run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

proxy/tun/README.md

@@ -201,14 +201,14 @@ After the start network adapter with the name you chose in the config will be cr
 When `dns` is set, those servers are applied to the adapter. Windows is kept from registering the TUN's addresses in DNS, and its DNS cache is flushed when the TUN starts and stops.
 
 With `strictRoute` and `autoSystemRoutingTable` set, Xray also adds Windows Filtering Platform filters that keep two kinds of traffic of every program but Xray itself from leaving outside the TUN:
-- With `dns` set, DNS (port 53) only goes through the TUN. Windows keeps sending name queries to the DNS servers of the other interfaces as well, and a resolver on the local network (e.g. `192.168.1.1` handed out by DHCP) is reached through its more specific LAN route instead of the TUN. The `dns` servers therefore have to lie within `gateway` or `autoSystemRoutingTable` (a warning is logged otherwise), and DNS servers that should be reached directly belong in Xray's own `dns` settings.
+- With `dns` set, DNS (port 53) only goes through the TUN. Windows keeps sending name queries to the DNS servers of the other interfaces as well, out through those interfaces whatever the routes say, and other programs reach a resolver on the local network (e.g. `192.168.1.1` handed out by DHCP) through its more specific LAN route instead of the TUN. On Windows 11 and Server 2022 and later, where those queries may also go over HTTPS or TLS, Windows' DNS Client service cannot connect outside the TUN at all, except for name resolution on the local network (LLMNR, mDNS). The `dns` servers therefore have to lie within `gateway` or `autoSystemRoutingTable` (a warning is logged otherwise), and DNS servers that should be reached directly belong in Xray's own `dns` settings.
 - Unless the TUN carries IPv6, that is, has an IPv6 address in `gateway` and IPv6 routes in `autoSystemRoutingTable`, IPv6 is blocked entirely, in both directions, as it would bypass the TUN. Only loopback and what Windows itself needs on the local link (neighbor and multicast listener discovery, DHCPv6) remain allowed.
 
 With the filters in place, Xray's own connections out also get past Windows Firewall's block rules (other firewalls may still block them), while connections to Xray's inbounds stay subject to them.
 
 Names that Xray resolves through the system resolver, such as an outbound's server address given as a domain with the default `AsIs` domain strategy, would be looked up by Windows on Xray's behalf, and those queries would then go into the TUN too. While DNS is restricted this way and `autoOutboundsInterface` is in use (the default with `autoSystemRoutingTable`), Xray therefore resolves them itself, with its own queries to the DNS servers of the other interfaces. That bypasses Windows' DNS cache, and its name resolution on the local network (LLMNR, mDNS): a server address given as a domain is looked up again for every connection, and a DNS server that does not answer delays each lookup. Having Xray's own `dns` resolve it, through the outbound's `sockopt.domainStrategy`, avoids that. The `localhost` DNS server queries the same servers whenever `autoOutboundsInterface` is in use. Both skip the TUN's own DNS servers, unless another interface uses them as well: queried from Xray itself, they would lead back into it, or nowhere.
 
-If the filters cannot be added, the TUN does not start (on Windows 10 and later; older versions only log a warning). They are removed when Xray exits. Not covered are encrypted DNS that Windows may send to the servers of other interfaces (DNS over HTTPS), and name resolution on the local network over IPv4 (LLMNR, mDNS, NetBIOS).
+If the filters cannot be added, the TUN does not start (on Windows 10 and later; older versions only log a warning). They are removed when Xray exits. Not covered is name resolution on the local network (LLMNR, mDNS, NetBIOS), except over IPv6 while that is blocked.
 
 `strictRoute` (Windows only) is `false` by default, as the filters break some setups: a local DNS resolver other programs use (e.g. on `127.0.0.1:53`), the DNS of another VPN on its own interface, IPv6 on the local network while the TUN has no IPv6 address, virtual machines whose NAT resolves names on the host, or signing in to a captive portal. Without the filters, DNS may leak as described above.