@RPRX 我写了个只返回rcode的DNS服务，要不要合并到这里？

{
  "domains": [
    "geosite:category-ads-all",
    "domain:lan",
    "regexp:^[^\\.]*$"
  ],
  "skipFallback": true,
  "finalQuery": true,
  "address": "rcode://3"
}

j2rong4cn@d08f648

@j2rong4cn

although, it is possible to add rcode-only-dns-server but it is better to add this feature to the DNS-hosts instead of adding rcode-only-dns-server.

i change the hosts code to achieve this goal, but currently we only have rcode=0: #4673

there is no difference between rcode=0, and rcode=3 or others in practice, because we don't return any IP in any case.

anyway, if rcode-number is important for your job, you can extend hosts code to return your desired rcode.

anyway, @RPRX has to make the final decision and I just said my opinion.

@patterniha
I need to return rcode=3. I used nslookup to test and found that nslookup will fallback when rcode=0.
I see StaticHosts.Lookup does not return an error, so I wrote rcode-only-dns-server

@patterniha I need to return rcode=3. I used nslookup to test and found that nslookup will fallback when rcode=0. I see StaticHosts.Lookup does not return an error, so I wrote rcode-only-dns-server

so i think it is better to extend hosts code, for example:

"geosite:category-ads-all": "#3"

This is definitely a better and more direct way, anyway @RPRX gives the final opinion.

@patterniha I need to return rcode=3. I used nslookup to test and found that nslookup will fallback when rcode=0. I see StaticHosts.Lookup does not return an error, so I wrote rcode-only-dns-server

so i think it is better to extend hosts code, for example:

"geosite:category-ads-all": "#3"

This is definitely a better and more direct way, anyway @RPRX gives the final opinion.

Good, let's do as you say.

After a quick look, it is not feasible to geoipchange directly to this breaking change, which will seriously damage the existing configuration.expected_geoip

@RPRX

No, it is 100% compatible with current configuration.

it does not change any current logic and configuration.

I just move codes to "condition_geoip.go", because we need to have more general function for unexpectedIPs, priorIPs and similar needs in the future.

It seems like you looked too quickly.

///

The only break is allowUnexpectedIPs and I don't think it has been used and it can be safely changed to priorIPs.

Thank you, as you are focused on Xray DNS, please have a look at this Issue too #4677

so i think it is better to extend hosts code, for example:

"geosite:category-ads-all": "#3"

Check this out
j2rong4cn@43b71df

so i think it is better to extend hosts code, for example:
"geosite:category-ads-all": "#3"

Check this out j2rong4cn@43b71df

you should open a PR, I'm just a contributor like you.

我觉得用 priorIPs 取代 allowUnexpectedIPs 是合理的，不过 geo 是支持反选的比如 "geoip:!cn"，所以两个 un 似乎没必要

不过现在反选只支持 geo，如果有需要的话再加一个反选 IP/CIDR 的语法就差不多了

还有就是先 expectedIPs 再 priorIPs，看名称的话顺序不太对，应当把 priorIPs 改名为 secondExpectedIPs

I think it is reasonable to priorIPsreplace with allowUnexpectedIPs, but geo supports inverse selection "geoip:!cn", so two uns seem unnecessary.

@RPRX

Yes, support inverse but:

1. You cannot and two inverse, for example you cannot have !geoip:cloudflare && !geoip:cloudfront
2. You can inverse only geoip, and you cannot inverse Non-geoip cird, for example i need inverse of {10.10.34.0/24 + 2001:4188:2:600:10:10:34:0/120} for serverless-for-Iran-anti-saction but we can't even have inverse of {10.10.34.0/24}, let alone the inverse of both.

Also, first , expectedIPsthen priorIPs, the order is not right if you look at the names, you should priorIPschange tosecondExpectedIPs

First, We will rarely need both at the same time.
Second, Even if we have both, it doesn't matter whether we apply expectIPs first or priorIPs first.

First, We will rarely need both at the same time.
Second, Even if we have both, it doesn't matter whether we apply expectIPs first or priorIPs first.

这俩不就是为了配合起来使用的吗，expect 两次，且有一个明确在前面，还有人要的话就 third

话说我突然想到，expectedIPs 作为一个数组，可能也像 #4673 以前的 hosts 一样把内容给合并了

或许直接更改它的行为，改为不合并，确保数组内第一个就是 first，第二个就是 second，以此类推，还是说本来就是这样的逻辑

ExpectedIPs, unexpectedIPs, priorIPs, unpriorIPs
Are 4 distinct options, Although we can have several of them at the same time,but it is a rarely used.

ExpectedIPs is clear.

unexpectedIPs is reverse-form of ExpectedIPs and i explained why we need reverse-form too.

priorIPs logic is simple: act same as expectedIPs but if no IP matched, the original-IPs still returned without any change, it is useful for workers/MitM configs.

unpriorIPs is reverse-form of priorIPs

我误解了你，你也误解了我，我本来以为你那个 priorIPs 是填 "0.0.0.0/0" 和 "::/0" 用的，作为第二层 expected

但是这个误解正好导致一个更简洁而强大的想法：把 expectedIPs 改为逐级匹配的，这一点你还没看懂 #4666 (comment)

至于如何合并反选，我还得再想想

It suddenly occurred to me that expectedIPsas an array, it might be possible to merge the contents like before #4673hosts

Maybe just change its behavior to not merge, making sure the first one in the array is first, the second one is second, and so on.Or is this the logic?

Suppose you want your IPs to be in range A but not in range B.
So you simply set:
ExpectedIPs = [A], unexpectedIPs = [B]

Therefore, the presence of unexpectedIPs next to expectedIPs is mandatory and the goal cannot be achieved by just changing syntax.

我觉得四个选项叠一起的话逻辑有点混乱，压成两个选项就行，unexpectedIPs 是可以加的，它们是合并而不是逐级，且作用于 expectedIPs 每一级匹配成功之后（除非 "0.0.0.0/0 或 "::/0"），比如第一级匹配到了但被 unexpectedIPs 否决了就继续下一级

这样就可以 cover 所有需求了，更少的配置项，更强大的功能

As i understand, you agree with unexpectedIPs but not with priorIPs and unpriorIPs.

So what is alternative for priorIPs = [geoip:cloudflare] in your method?

比如如下配置

"expectedIPs": ["geoip:us", "geoip:uk", "0.0.0.0/0", "::/0"],
"unexpectedIPs": ["10.10.34.0/24", "2001:4188:2:600:10:10:34:0/120"]

逻辑是

1. expect US IPs, if we picked an IP, check all unexpectedIPs, if no IP was picked or the picked IP is "unexpected" then
2. expect UK IPs, if we picked an IP, check all unexpectedIPs, if no IP was picked or the picked IP is "unexpected" then
3. allow all IPv4, do not check unexpectedIPs
4. allow all IPv6, do not check unexpectedIPs

1. This break current expectedIPs behavior.

   If the IPs contain both uk and us, now we only have us ips.

2. Many changes need to be made in the code.

3. It is definitely more complicated than using 4 options

这并不会严重破坏 expectedIPs 的行为，只是把 US 放第一级、UK 放第二级了，这可以接受，用户配置里本来就是这个顺序，我不确定现有的代码逻辑里是合并了还是逐级匹配，但是改成逐级匹配没有难度，就只是改成 for 循环，比多两个选项要简单

并且如果有人要 third 或者更多，他也可以通过优先级顺序来实现

简单来说就是你的 PR 在广义范围上的 expected 功能只有两级且第二级只能全选，我提的是 expected 多级且每级范围可以自定义

@RPRX

I had a goal (Serverless for Iran) and you helped me a lot to achieve my goal, but you neglected me near the end of my work.

I also helped you and found and fixed nearly 20 small and big bugs in this time.

Serverless-for-iran-anti-sanction-version is not yet complete and needs some-of-these-dns-new-features and happy-eyeballs to complete.

Needless to say, these features are also very useful for Chinese users and other uses.

Many users on Telegram ask me for Serverless-for-iran-anti-sanction-version, According to the tests I did, it opens almost all services and websites (except telegram) in all ISPs in iran.

Why does a PR take more than a month to be approved?

那我先合了，有要改的以后再改吧

所以你检查系统是否支持ipv4v6的方法是向两个硬编码的ip进行dial????

@Fangliding

I explained in #4666 (comment) why I used net.dial instead of net.InterfaceAddrs().

It doesn't matter which IP we check for, It is enough to check for a non-reserved IP.

每次 dns 查询，你都额外 dial 两次

我的小霸王学习机受得了
用户手机也受不了

哦，草
不止两次

前脚刚在 LookupIP() 检查完
然后马上又在 QueryIP() 检查

然而 QueryIP() 只被前者调用
上次检查结果都传进去了的

人家原版的 QueryIP() 中再次检查是因为 Nameserver 也有自己的 v4 v6 option

也就是说每次 dns 查询至少无意义地 dial udp 四次
真的没什么开销吗？

这不是 vibe coding 我吃屎三斤

package main

import (
	"net"
	"testing"
)

func checkSystemNetwork() (supportIPv4 bool, supportIPv6 bool) {
	conn4, err4 := net.Dial("udp4", "8.8.8.8:53")
	if err4 != nil {
		supportIPv4 = false
	} else {
		supportIPv4 = true
		conn4.Close()
	}

	conn6, err6 := net.Dial("udp6", "[2001:4860:4860::8888]:53")
	if err6 != nil {
		supportIPv6 = false
	} else {
		supportIPv6 = true
		conn6.Close()
	}
	return
}

func BenchmarkCheckSystemNetwork(b *testing.B) {
	for i := 0; i < b.N; i++ {
		checkSystemNetwork()
		checkSystemNetwork()
	}
}

BenchmarkCheckSystemNetwork-4   	     703	   1703517 ns/op	    4623 B/op	      46 allocs/op

开销还挺大

@Meo597

This option is most commonly used on mobile-client-side, people are constantly switching between mobile-data and wi-fi.

in Iran, Most ADSL/VDSL/FTTH do not support IPv6, but IPv6 is supported in most places for mobile-data.

///

The cost of port-binding is almost zero, less than 0.1ms per bind,

Also how many dns-lookup do we have per minute?

checking supported-IP-versions only once, causes users to have to turn VPN off and on after each network change.

This is an important feature for Serverless, please do not change that.

你不是糊了 happy eyeballs 吗？
这个就完全没用了

别告诉我你糊完了自己都没试一下

I add useSystem queryStrategy for UDP not TCP.

if a system doesn't support IPv6, an IPv6 should not selected for freedom-UseIP/ForceIP.

1. 耗时 1.7ms 不是 0.17ms
2. 如果有 fallback 时间继续翻倍
3. 如果像你说的 wifi / 蜂窝 来回切，手机会按需请求 a or aaaa。ios 上只有 tun，请求来的都是 ip，android proxy 模式压根不支持 udp 然后 tcp 你已经有了 happyeyeballs 了。所以你这玩意只能是给 xary-core 内部用的。所以你这个东西的使用场景到底是什么？
4. 如果真像你说的确实手机需要，你至少应该让非移动端 sync.Once

别的都不提，你 QueryIP 为什么还要再查一次，你真的搞明白 dns 这一串函数的调用顺序了吗？

你这个功能纯粹就是臆想的糊上去
我提出问题了现编一个理由出来
你真的用过吗？

iOS only has TUN, so requests always come in via IP

we have two situations:

1. not using fakedns:
   so if we return both IPv4 and IPv6 for browser dns-request, the browser usually choose IPv6 for quic, so if our network doesn't support IPv6, the quic-connection will not be established (in case of TUN, browser does not realize that IPv6 is not available, unless we disable IPv6 in TUN at all)
2. using fakedns:
   so we have domain in freedom and if we use "UseIP"/"ForceIP", an IPv6 may be chosen, and the quic-connection will not be established.

///

I tested and it takes less than 50ms for 1000 bind-and-close(0.05ms per bind-and-close), so the cost is negligible.

Anyway if you still concern the cost, you can add useSystemOnce,
useSystem is the key-feature for my Serverless, and should not be changed.

我用 x86 跑，成本都是 1.7ms pre call，虽然是低功耗的 cpu
你 5w 手机秒了 25w PC 太厉害了
你是怎么做性能测试的？上面的 benchmark 跑跑看？

问题关键在于非移动端用它代价太大
你至少应该 PR 一个 patch 让它非移动端时 once

1.7ms only for port binding!!!, I think you measured other-things too (or something is wrong with your benchmark)

This has nothing to do with CPU-power, this is a simple thing.

please run:

    a := time.Now()
	for i := 0; i < 1000; i++ {
		c, _ := net.Dial("udp4", "8.8.8.8:443")
		c.Close()
	}
	println((time.Now().Sub(a)).Milliseconds())

and send the result.

原来你是这么做 benchmark 的
长见识了