MerlinKodo/clash-rev

[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"
      }
    ]
  }
}

dnsleaktest redir-host
Screenshot_20231101-004433_Brave~2
Screenshot_20231101-011911_Brave

dnsleaktest fake-ip
Screenshot_20231101-004504_Brave

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.

@adiprasetya

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:

  1. 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.
  2. 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.
  3. 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.