What is the name of the domain?
any
What is the issue you’re encountering
Local Proxy mode does not support local DNS resolving
What steps have you taken to resolve the issue?
Submitted feature requests to support local DNS resolving in other places. That being said, I doubt they will be implemented, see below for explanation why.
What are the steps to reproduce the issue?
Firstly, to make sure the issue is exactly that, simply try running
(socks5h is remote resolving, socks5 is local - see SOCKS - Wikipedia)
~ curl --proxy socks5://127.0.0.1:40000 https://www.cloudflare.com/cdn-cgi/trace -v
- Trying 127.0.0.1:40000…
- Host www.cloudflare.com:443 was resolved.
- IPv4: 104.16.124.96, 104.16.123.96
- SOCKS5 connect to 104.16.124.96:443 (locally resolved)
- SOCKS5 request granted.
- Connected to 127.0.0.1 () port 40000
vs
~ curl --proxy socks5h://127.0.0.1:40000 %sameurl% -v
- Trying 127.0.0.1:40000…
- SOCKS5 connect to www.cloudflare.com:443 (remotely resolved)
- connection to proxy closed
- closing connection #0
curl: (97) connection to proxy closed
However, so far, that’s alright - curl supports both modes, just use the latter.
The problem arises when some significant places, namely browsers, only support the first one - remote DNS resolving. As far as I can tell, at least on macOS, Chrome relies on system settings for proxy, and there is no way to make it resolve locally. Firefox has the settings to disable remote DNS resolving for SOCKS4/5, however, by default they’re on and when using Cloudflare WARP as Local Proxy the error message in Firefox does not help to understand what the difficulty is. Even if you disable it in Firefox settings, some of its popular official extensions do not have such settings (namely Multi-Account Containers) and they do not fall back to the browser’s settings, they merely hardcode true for remote resolving.
Because the crux of the issue is that remote DNS resolving via SOCKS5 is deemed to be more secure - it does not leak your DNS resolving to the system DNS resolver that might be, e.g., from your ISP. While I understand, one can set up local DNS resolving securely (e.g. by using 1.1.1.1 or 1.1.1.1 via DoH), this introduces difficulty. The default, the norm, would likely gravitate towards the simplest and secure solution - remote DNS resolving. When someone reports an issue that their DNS is leaking, the simplest solution for the software developer would be to upgrade to remote DNS resolving for everyone instead of introducing both modes and a settings panel (I’ve already seen this happen in the aforementioned Multi-Account Containers development history).
Moreover, specifically in Cloudflare WARP case, this would improve performance. By using remote DNS resolving, one replaces two requests (DNS and SOCKS) from the client to Cloudflare with one request from the client and two requests within the Cloudflare infrastructure. The last mile to the client is usually the slowest part of the journey, so remote DNS resolving should give latency advantage on average.
All in all, I suggest Cloudflare implement remote DNS resolving in Local Proxy mode in WARP.