DNS outbound: Add skipRcodes

[j2rong4cn]

控制内置DNS服务器 IP查询 失败返回的RCode，重新将IP查询转发给目标
https://xtls.github.io/config/outbounds/dns.html#outboundconfigurationobject

{
  "outbounds": [
    {
      "protocol": "dns",
      "settings": {
        "skipRcodes": [2]
      },
      "tag": "dns-out"
    }
  ],
  "dns": {
    "hosts": {
      "domain:lan": "#2"
    }
  }
}

• 使用TProxy透明代理时，劫持53端口后配合这个PR DNS hosts: Support returning RCode #4681 配置如上 局域网内可以根据名称获取设备IP

> nslookup pc.lan 192.168.0.1
Server:         192.168.0.1
Address:        192.168.0.1#53

Name:   pc.lan
Address: 192.168.0.99

[RPRX]

“直接转发给目标”的描述应改为“直接转发回客户端”

还有示例配置的 "nonIPQuery": "skip" 也有迷惑性，应该与它无关吧？

[RPRX]

按错了

[RPRX]

还是说 DNS 请求也有个 rcode？没研究过，我以为这东西意思是 error code，DNS 响应才有的

[j2rong4cn]

“直接转发给目标”的描述应改为“直接转发回客户端”

我看文档里"nonIPQuery": "skip"写的是转发给目标，这PR就是同样的功能

[j2rong4cn]

@RPRX 具体功能是 内置DNS服务器 IP查询 失败时根据指定的RCode，重新将IP查询转发给目标
感觉叫skipRcodes不合适，叫啥？

[RPRX]

现有命名确实太迷惑了，而且我还寻思 DNS 出站本来就没阻止发回 rcode 为啥还要 skip，你这个功能大概可以叫 fallback 什么的

[Fangliding]

connWriter是远程conn的writer
主要目的是为了配合另一个pr的host的rcode好让部分网址触发skip行为直出
说白了那么多dns pr都是为了在这个简单或者说简陋的小dns匹配器上糊乱七八糟的功能配合达到一些自己的需求

[RPRX]

说白了那么多dns pr都是为了在这个简单或者说简陋的小dns匹配器上糊乱七八糟的功能配合达到一些自己的需求

其实我也觉得，不过有人 PR 且设计得当、可能能 cover 更多需求的话还好

[j2rong4cn]

使用TProxy透明代理时，劫持53端口后配合这个PR #4681 配置如上 局域网内可以根据名称获取设备IP

就是为了这个，用了TProxy透明代理后我发现 使用smb访问电脑共享文件时 xray日志里有 .lan 后缀的查询

[Fangliding]

那正确的解决办法不应该是把localhost dns展开成一个复杂dns服务器配置然后让它匹配.lan域名吗

[j2rong4cn]

你这个功能大概可以叫 fallback 什么的

@RPRX @Fangliding 你们专业，你们决定命名再改吧。

[patterniha]

i don't understand this PR.

It's just enough to set:

"dns":{
    "servers": [
       {
               "address": "localhost",
               "domains": ["domain:lan"]
       }
   ]
}

[j2rong4cn]

那正确的解决办法不应该是把localhost dns展开成一个复杂dns服务器配置然后让它匹配.lan域名吗

直接localhost就可以，但在Android 使用ndk编译的xray net.LookupIP()调用的内核查询？查询流量的gid是0，不是xray运行的gid，所以就搞了这个PR的功能

[patterniha]

in android we can bypass an app from using VPN,
v2rayNG bypass itself from using VPN in its code, so in v2rayNG we don't have problem for net.LookupIP() and "localhost" dns works well in v2rayNG.

[j2rong4cn]

i don't understand this PR.

It's just enough to set:

"dns":{
    "servers": [
       {
               "address": "localhost",
               "domains": ["domain:lan"]
       }
   ]
}

Is the DNS query traffic in the Android system initiated by the kernel? Because the traffic has gid=0, I can only hijack port 53 with gid=0
After using ndk to compile Android's xray, the query traffic of net.LookupIP() has gid=0

[j2rong4cn]

in android we can bypass an app from using VPN, v2rayNG bypass itself from using VPN in its code, so in v2rayNG we don't have problem for net.LookupIP() and "localhost" dns works well in v2rayNG.

I don't use v2rayNG. I use TProxy to implement transparent proxy. Some applications in China will detect VPNs.
https://xtls.github.io/document/level-2/iptables_gid.html

[patterniha]

?? but we need root-access for transparent proxy on android, anyway I just knew about v2rayNG.

[yuhan6665]

related historical work:
#1265
Asterisk4Magisk/Xray4Magisk#86

[j2rong4cn]

related historical work: #1265 Asterisk4Magisk/Xray4Magisk#86

• 你搞错了，这个PR Workflows: Build Android(7+) using NDK; Add Android(7+) amd64 build #4664 让安卓的localhost DNS可以正常工作，不过好像通过内核查询IP

[patterniha]

@j2rong4cn

Use go-resolver instead of cgo-resolver: #4312

Just you to need to set GODEBUG=netdns=go before build.

[patterniha]

@j2rong4cn

Is the problem solved after using go-resolver?

[j2rong4cn]

@j2rong4cn

Use go-resolver instead of cgo-resolver: #4312

Just you to need to set GODEBUG=netdns=go before build.

The following answer comes from gemini deep research：

• Behavior when CGO is disabled
  When CGO_ENABLED is set to 0, Go programs will not be able to use the C code-dependent "cgo-resolver". In this case, Go falls back to using the pure Go implementation of "go-resolver" to perform DNS resolution. The search results also mention the netgo build tag, which forces the use of "go-resolver", and disabling the CGO build process implicitly applies this tag for the net package.
• Operating system differences
  It is worth noting that the choice of DNS resolver may also be affected by the operating system. For example, Go 1.20 introduced a mechanism on macOS to directly use the system resolver even when CGO is disabled. Windows also has its own specific way of handling DNS resolution when CGO_ENABLED=0. So while disabling CGO generally results in the use of "go-resolver", there may be subtle differences on different operating systems.

[patterniha]

No, in windows even if we set CGO_ENABLED=0, it still does not use go-resolver, i tested before.
so we should set GODEBUG=netdns=go for using go-resolver in windows.

[j2rong4cn]

Is the problem solved after using go-resolver?

No, query traffic is still gid=0

[patterniha]

Is the problem solved after using go-resolver?

No, query traffic is still gid=0

so it seems this pr is the only way.

[j2rong4cn]

非刚需功能，先关闭PR了，有人需要再开