一点疑问

[dusty-97]

近期在OpenWrt Passwall配合ChinaDNS-NG使用时遇到一点问题：
当节点挂掉时，如果在Linux系统中去cURL请求一个即不在chn、也不在gfw中但是解析结果是国内IP的域名，cURL请求会有异常，OpenWrt本机报错：curl: (6) Couldn't resolve host xxx，局域网Ubuntu设备卡顿5秒后cURL响应成功。

如果域名标签选择直连则该问题不会复现。
我的疑问是，既然china-dns已经返回了国内IP，还必须等待trust-dns响应吗，是否可以考虑直接丢弃trust-dns的响应不要等待？

模拟故障的方法：trust-dns随便指定一个不是DNS的IP

问题复现时，dig该域名很快相应，nslookup会卡一会：

root@OpenWrt:~# nslookup -port=15353 kwx.cc
Server:		127.0.0.1
Address:	127.0.0.1:15353

Non-authoritative answer:
Name:	kwx.cc
Address: 113.207.49.61
Name:	kwx.cc
Address: 14.17.80.21

*** Can't find kwx.cc: No answer

Windows nslookup也会卡一会：

nslookup kwx.cc
服务器:  OpenWrt.lan
Address:  192.168.1.1

非权威应答:
DNS request timed out.
    timeout was 2 seconds.
名称:    kwx.cc
Addresses:  14.17.80.21
          113.207.49.61

[zfl9]

首先，dig响应很快，而nslookup会卡顿一会，说明就是AAAA查询的问题。

其次，对于 tag:none 域名，chinadns-ng 不会无条件等待 trust 结果，只有当 china 结果不可用时（非 china-ip、无ip且noip-as-chnip未开启）才会等待 trust 结果。

那么具体发生了什么就很明显了：

• A查询，如你所说，china 上游的结果是 china ip，A查询结束。不管trust结果如何。
• AAAA查询，china 上游的结果被 filter 了，原因见前面说的，极大概率是 noip。

请使用 dig 域名 AAAA 来验证，另外，为什么不看看神奇的 chinadns-ng verbose 日志呢。

[zfl9]

题外话：

我一直“不喜欢”将 nslookup 作为 DNS 测试工具，因为它默认同时查询并等待 A 和 AAAA。

一旦其中某个查询有问题，测试者很容易被 nslookup 的表面现象蒙蔽，然后就在那里猜。。

nslookup 并不是专业 DNS 测试工具，如果想探明 DNS 问题的真相，我强烈建议使用 dig。。。

希望下次遇到类似问题，先用 dig 单独验证下 A 查询和 AAAA 查询，而不是根据 nslookup 结果瞎猜~

[dusty-97]

首先，dig响应很快，而nslookup会卡顿一会，说明就是AAAA查询的问题。

其次，对于 tag:none 域名，chinadns-ng 不会无条件等待 trust 结果，只有当 china 结果不可用时（非 china-ip、无ip且noip-as-chnip未开启）才会等待 trust 结果。

那么具体发生了什么就很明显了：

• A查询，如你所说，china 上游的结果是 china ip，A查询结束。不管trust结果如何。
• AAAA查询，china 上游的结果被 filter 了，原因见前面说的，极大概率是 noip。

请使用 dig 域名 AAAA 来验证，另外，为什么不看看神奇的 chinadns-ng verbose 日志呢。

Passwall没有输出日志，于是我用其他机器模拟trust-dns异常的情况测试了下，确实如此，AAAA查询超时

root@VM-4-4-ubuntu:~# dig kwx.cc @127.0.0.1 -p 15354 A

; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> kwx.cc @127.0.0.1 -p 15354 A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49950
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;kwx.cc.				IN	A

;; ANSWER SECTION:
kwx.cc.			238	IN	A	14.17.80.21
kwx.cc.			238	IN	A	113.207.49.61

;; Query time: 8 msec
;; SERVER: 127.0.0.1#15354(127.0.0.1) (UDP)
;; WHEN: Sun Jun 02 00:11:45 CST 2024
;; MSG SIZE  rcvd: 56

root@VM-4-4-ubuntu:~# dig kwx.cc @127.0.0.1 -p 15354 AAAA
;; communications error to 127.0.0.1#15354: timed out
;; communications error to 127.0.0.1#15354: timed out
;; communications error to 127.0.0.1#15354: timed out

; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> kwx.cc @127.0.0.1 -p 15354 AAAA
;; global options: +cmd
;; no servers could be reached

root@VM-4-4-ubuntu:~/test# ./chinadns-ng -l 15354 -c 114.114.114.114 -t 188.177.166.155 -v
2024-06-02 00:11:29 I [main.zig:116 main] local listen addr: 127.0.0.1#15354@tcp+udp
2024-06-02 00:11:29 I [groups.zig:123 on_start] tag:chn upstream: tcpi://114.114.114.114
2024-06-02 00:11:29 I [groups.zig:123 on_start] tag:chn upstream: udpi://114.114.114.114
2024-06-02 00:11:29 I [groups.zig:123 on_start] tag:gfw upstream: tcpi://188.177.166.155
2024-06-02 00:11:29 I [groups.zig:123 on_start] tag:gfw upstream: udpi://188.177.166.155
2024-06-02 00:11:29 I [main.zig:116 main] ip test db: chnroute,chnroute6
2024-06-02 00:11:29 I [main.zig:116 main] default domain name tag: none
2024-06-02 00:11:29 I [main.zig:116 main] response timeout of upstream: 5
2024-06-02 00:11:29 I [main.zig:116 main] filter no-ip reply from chinadns
2024-06-02 00:11:29 I [main.zig:116 main] printing the verbose runtime log
2024-06-02 00:11:45 I [server.zig:309 QueryLog.query] query(id:7875, tag:none, qtype:1, 'kwx.cc') from 127.0.0.1#54013
2024-06-02 00:11:45 I [server.zig:375 QueryLog.forward] forward query(qid:1, from:udp, 'kwx.cc') to china group
2024-06-02 00:11:45 I [Upstream.zig:939 Group.send] forward query(qid:1, from:udp) to upstream udpi://114.114.114.114
2024-06-02 00:11:45 I [server.zig:375 QueryLog.forward] forward query(qid:1, from:udp, 'kwx.cc') to trust group
2024-06-02 00:11:45 I [Upstream.zig:939 Group.send] forward query(qid:1, from:udp) to upstream udpi://188.177.166.155
2024-06-02 00:11:45 I [server.zig:577 ReplyLog.reply] reply(qid:1, tag:none, qtype:1, 'kwx.cc') from udpi://114.114.114.114 [accept]
2024-06-02 00:11:49 I [server.zig:309 QueryLog.query] query(id:45677, tag:none, qtype:28, 'kwx.cc') from 127.0.0.1#43522
2024-06-02 00:11:49 I [server.zig:375 QueryLog.forward] forward query(qid:2, from:udp, 'kwx.cc') to china group
2024-06-02 00:11:49 I [Upstream.zig:939 Group.send] forward query(qid:2, from:udp) to upstream udpi://114.114.114.114
2024-06-02 00:11:49 I [server.zig:375 QueryLog.forward] forward query(qid:2, from:udp, 'kwx.cc') to trust group
2024-06-02 00:11:49 I [Upstream.zig:939 Group.send] forward query(qid:2, from:udp) to upstream udpi://188.177.166.155
2024-06-02 00:11:49 I [server.zig:602 ReplyLog.china_noip] reply(qid:2, tag:none, qtype:28, 'kwx.cc') has no answer ip [filter]
2024-06-02 00:11:49 I [server.zig:577 ReplyLog.reply] reply(qid:2, tag:none, qtype:28, 'kwx.cc') from udpi://114.114.114.114 [filter]
2024-06-02 00:11:54 I [server.zig:309 QueryLog.query] query(id:45677, tag:none, qtype:28, 'kwx.cc') from 127.0.0.1#35721
2024-06-02 00:11:54 I [server.zig:375 QueryLog.forward] forward query(qid:3, from:udp, 'kwx.cc') to china group
2024-06-02 00:11:54 I [Upstream.zig:939 Group.send] forward query(qid:3, from:udp) to upstream udpi://114.114.114.114
2024-06-02 00:11:54 I [server.zig:375 QueryLog.forward] forward query(qid:3, from:udp, 'kwx.cc') to trust group
2024-06-02 00:11:54 I [Upstream.zig:939 Group.send] forward query(qid:3, from:udp) to upstream udpi://188.177.166.155
2024-06-02 00:11:54 W [server.zig:844 on_timeout] query(qid:2, id:45677, tag:none) from udp://127.0.0.1#43522 [timeout]
2024-06-02 00:11:54 I [server.zig:602 ReplyLog.china_noip] reply(qid:3, tag:none, qtype:28, 'kwx.cc') has no answer ip [filter]
2024-06-02 00:11:54 I [server.zig:577 ReplyLog.reply] reply(qid:3, tag:none, qtype:28, 'kwx.cc') from udpi://114.114.114.114 [filter]
2024-06-02 00:11:59 I [server.zig:309 QueryLog.query] query(id:45677, tag:none, qtype:28, 'kwx.cc') from 127.0.0.1#55133
2024-06-02 00:11:59 I [server.zig:375 QueryLog.forward] forward query(qid:4, from:udp, 'kwx.cc') to china group
2024-06-02 00:11:59 I [Upstream.zig:939 Group.send] forward query(qid:4, from:udp) to upstream udpi://114.114.114.114
2024-06-02 00:11:59 I [server.zig:375 QueryLog.forward] forward query(qid:4, from:udp, 'kwx.cc') to trust group
2024-06-02 00:11:59 I [Upstream.zig:939 Group.send] forward query(qid:4, from:udp) to upstream udpi://188.177.166.155
2024-06-02 00:11:59 W [server.zig:844 on_timeout] query(qid:3, id:45677, tag:none) from udp://127.0.0.1#35721 [timeout]
2024-06-02 00:11:59 I [server.zig:602 ReplyLog.china_noip] reply(qid:4, tag:none, qtype:28, 'kwx.cc') has no answer ip [filter]
2024-06-02 00:11:59 I [server.zig:577 ReplyLog.reply] reply(qid:4, tag:none, qtype:28, 'kwx.cc') from udpi://114.114.114.114 [filter]
2024-06-02 00:12:04 W [server.zig:844 on_timeout] query(qid:4, id:45677, tag:none) from udp://127.0.0.1#55133 [timeout]

这种情况有什么好的解决办法吗？--no-ipv6过滤掉所有AAAA查询？
（因为我是非IPv6环境，OpenWrt DNS设置中过滤掉了IPv6解析，Passwall设置中也过滤掉了远程DNS IPv6解析，所以没有考虑到AAAA查询的问题，抱歉）

[zfl9]

有两种方法：

1. noip-as-chnip，具体看readme倒数第二段的说明

2. 如果没有ipv6网络，建议直接过滤所有AAAA查询，这样AAAA查询就会立即返回。

[dusty-97]

有两种方法：

1. noip-as-chnip，具体看readme倒数第二段的说明
2. 如果没有ipv6网络，建议直接过滤所有AAAA查询，这样AAAA查询就会立即返回。

Thanks.