[Bug] using dns server instead of client
adiprasetya opened this issue · 5 comments
Prerequisites
- I understand that this is the official open-source version of the Clash.Rev core
- I am submitting an issue with the Clash.Rev core, not Clash.Meta / OpenClash / ClashX / Clash For Windows or any other derivative version
- I am using the latest version of the Clash.Rev core in this repository
- I have searched at the Issue Tracker and have not found any related issues
- I have read the official Wiki and was unable to solve the issue
Version
Clash Rev Version: v1.0.2 OS: android Architecture: arm64 Go Version: go1.21.4 Build Time: Thu Nov 16 10:14:11 CST 2023 Use tags: with_gvisor
Operating System
Linux, Android
Architecture
amd64, arm64
Configuration File
dns:
enable: true
ipv6: false
enhanced-mode: redir-host # or fake-ip
default-nameserver:
- 8.8.8.8#DIRECT
nameserver:
- tls://1.1.1.1#PROXY
- https://1.1.1.1/dns-query#PROXY
proxy-server-nameserver:
- 8.8.8.8#DIRECT
Log
time="2023-11-16T03:19:36.950074719Z" level=debug msg="[DNS] resolve ifconfig.me from https://1.1.1.1:443/dns-query"
time="2023-11-16T03:19:36.950604257Z" level=debug msg="[https://1.1.1.1:443/dns-query] using HTTP/2 for this upstream: <nil>"
time="2023-11-16T03:19:36.950427027Z" level=debug msg="[DNS] resolve ifconfig.me from tls://1.1.1.1:853"
time="2023-11-16T03:19:37.475536873Z" level=debug msg="[DNS] ifconfig.me --> [34.160.111.145] A from tls://1.1.1.1:853"
time="2023-11-16T03:19:37.481970719Z" level=debug msg="[DNS] resolve 145.111.160.34.in-addr.arpa from https://1.1.1.1:443/dns-query"
time="2023-11-16T03:19:37.482258411Z" level=debug msg="[DNS] resolve 145.111.160.34.in-addr.arpa from tls://1.1.1.1:853"
time="2023-11-16T03:19:37.651235027Z" level=debug msg="[DNS] 145.111.160.34.in-addr.arpa --> [] PTR from https://1.1.1.1:443/dns-query"
time="2023-11-16T03:19:40.590395027Z" level=debug msg="[DNS] resolve mtalk.google.com from https://1.1.1.1:443/dns-query"
time="2023-11-16T03:19:40.590567719Z" level=debug msg="[DNS] resolve mtalk.google.com from tls://1.1.1.1:853"
time="2023-11-16T03:19:40.706268334Z" level=debug msg="[DNS] mtalk.google.com --> [74.125.130.188] A from https://1.1.1.1:443/dns-query"
Description
it seems clash still using dns on the server even the logs say that resolved from client conf. actually it using server configuration. before meta archive they repo, i already make this issue and no response. it is bug from clash founder. i hope it can be fixed. i just ordinary person so what can i do is just bug reporting.
Reproduction Steps
server configuration using sing-box set to adguard
{
"dns": {
"servers": [
{
"tag": "adguard",
"address": "94.140.14.14"
}
]
}
}
server log return hostname instead of ip, so it basically using dns server. unlike sing-box, sing-box return ip on the server log.
Thank you for the feedback. I need to conduct some tests to determine where the problem lies and how to modify it.
Based on my understanding of your question, it seems you're experiencing an issue where, despite having set your local DNS to Cloudflare DNS, a DNS Leak Test identifies the DNS server as the AdGuard DNS server set on your service side. Please correct me if my understanding is inaccurate.
Regarding this issue, consider the insights from these two articles:
浅谈在代理环境中的 DNS 解析行为
漫谈各种黑科技式 DNS 技术在代理环境中的应用
Concerning your configuration file:
Copy code
dns:
enable: true
ipv6: false
enhanced-mode: redir-host # or fake-ip
default-nameserver:
- 8.8.8.8#DIRECT
nameserver:
- tls://1.1.1.1#PROXY
- https://1.1.1.1/dns-query#PROXY
proxy-server-nameserver:
- 8.8.8.8#DIRECT
When accessing dnsleaktest.com
, consider the following scenarios:
- If domain rules require proxy usage, Clash directly sends the request and domain to the server side, which completes the DNS resolution and establishes access. Thus, the server side's DNS is detected.
- If domain rules match direct connection, Clash uses the set nameserver for DNS resolution and establishes a direct connection. The Cloudflare DNS server is detected in this case.
- If there are IP rules, local DNS resolution via the set nameserver occurs to match IP addresses. If it's a direct connection, it establishes directly, detecting the Cloudflare DNS server. If it's via proxy, the server side and client side DNS are detected.
Regarding the difference between redir-host
and fake-ip
modes, redir-host
always initiates local DNS resolution, potentially showing both Cloudflare DNS and AdGuard. In contrast, fake-ip
, when directly matching domain rules, bypasses local DNS resolution.
Test
For a simple test, add the rule - DOMAIN-KEYWORD,dnsleaktest.com,DIRECT
at the top of your configuration file. After reloading the configuration, you should find that the detected DNS server is now your locally set Cloudflare DNS server.
Here are my test results: After adding - DOMAIN-KEYWORD,dnsleaktest.com,DIRECT
and setting my local DNS to Cloudflare, the results were as follows, only my client DNS:
Removing this rule and allowing dnsleaktest.com to go through the proxy, the result showed the remote server's DNS service:
as i know, dns client side configuration it should be using the client configuration (like sing-box). no matter if go through proxy or direct. for an example, if i using cloudflare and it's will be resolving on the client and then request to the server as an ip, that because it's already resolved on the client. if it's still request to the proxy server as a hostname, that will be resolve on the server, not in the client. dns resolver should be client only. it's matter for privacy.
kinda not understanding what you mean.
sorry for the bad english.
I understand that what you want is for the client to complete the DNS resolution and then for the server to use the IP resolved by the client directly, without performing its own DNS resolution. However, to avoid DNS pollution, it is necessary to use a pure DNS server. Generally, we choose DOH or DOT services. In most cases, it's also necessary to add #PROXY
to query through a proxy. In this way, the DNS resolution is already done via a remote proxy server. From this perspective, there is no difference in terms of privacy issues compared to the current method.
This topic warrants further discussion, so I'll be moving it to the Discussions section rather than addressing it as an issue.