q q Times Out When Querying Router's DNS on Win10 22H2

On Windows 10 22H2, when using the router's configured DNS server (the same one), I've encountered a peculiar issue:

The doggo tool can successfully resolve the query and return a result.

The q tool consistently times out during the lookup.

This issue is 100% reproducible.

However, if I use third-party public DNS servers (e.g., 223.5.5.5 or 119.29.29.29), both doggo and q can resolve the query normally.

Does anyone have any idea what the potential cause might be? https://github.com/natesales/q version 0.19.9 (3f3ae8d2a8d58aed559f1b6be27e76f1e669d1d9 2025-09-18T22:36:21Z)

C:\Users\*>doggo.exe weixin.qq.com @192.168.110.1 --debug
time=2025-11-04T11:51:06.941+08:00 level=DEBUG msg="LoadNameservers: Initial nameservers" nameservers=[192.168.110.1]
time=2025-11-04T11:51:06.986+08:00 level=DEBUG msg="Added nameserver" nameserver="{Address:192.168.110.1:53 Type:udp}"
time=2025-11-04T11:51:06.986+08:00 level=DEBUG msg="LoadNameservers: Final nameservers" nameservers="[{Address:192.168.110.1:53 Type:udp}]"
time=2025-11-04T11:51:06.986+08:00 level=DEBUG msg="initiating UDP resolver"
time=2025-11-04T11:51:06.986+08:00 level=DEBUG msg="Attempting to resolve" domain=weixin.qq.com. ndots=0 nameserver=192.168.110.1:53
NAME                            TYPE    CLASS   TTL     ADDRESS                         NAMESERVER
weixin.qq.com.                  CNAME   IN      600s    minorshort.weixin.qq.com.       192.168.110.1:53
minorshort.weixin.qq.com.       A       IN      600s    117.89.182.41                   192.168.110.1:53
minorshort.weixin.qq.com.       A       IN      600s    101.227.132.63                  192.168.110.1:53

C:\Users\dima>q weixin.qq.com /s 192.168.110.1 --verbose
DEBU Name: weixin.qq.com
DEBU RR types: [NS MX TXT CNAME A AAAA]
DEBU Server(s): [192.168.110.1]
DEBU Using server 192.168.110.1:53 with transport plain
DEBU Using UDP with TCP fallback: 192.168.110.1:53
FATA timeout after 10s

C:\Users\dima>q weixin.qq.com /s 223.5.5.5 --verbose
DEBU Name: weixin.qq.com
DEBU RR types: [A AAAA NS MX TXT CNAME]
DEBU Server(s): [223.5.5.5]
DEBU Using server 223.5.5.5:53 with transport plain
DEBU Using UDP with TCP fallback: 223.5.5.5:53
minorshort.weixin.qq.com. 52s A 101.227.132.63
minorshort.weixin.qq.com. 52s A 117.89.182.41
weixin.qq.com. 54s CNAME minorshort.weixin.qq.com.
minorshort.weixin.qq.com. 1m33s AAAA 240e:978:d04:3003::27
minorshort.weixin.qq.com. 1m33s AAAA 240e:e1:aa00:1001::a
minorshort.weixin.qq.com. 1m33s AAAA 240e:e1:aa00:101a::48
minorshort.weixin.qq.com. 1m33s AAAA 240e:e9:6003:23b::25
weixin.qq.com. 2m51s CNAME minorshort.weixin.qq.com.
weixin.qq.com. 4m7s CNAME minorshort.weixin.qq.com.
weixin.qq.com. 4m10s CNAME minorshort.weixin.qq.com.

Nov 04 '25 04:11 nasaboy

The latest version 0.19.11 was tested and the same situation occurred. However, I found that after adding the /t parameter, it could be queried normally

C:\Users\dima>q weixin.qq.com /t A /s 192.168.110.1 --verbose
DEBU Name: weixin.qq.com
DEBU RR types: [A]
DEBU Server(s): [192.168.110.1]
DEBU Using server 192.168.110.1:53 with transport plain
DEBU Using UDP with TCP fallback: 192.168.110.1:53
minorshort.weixin.qq.com. 10m A 101.227.132.63
minorshort.weixin.qq.com. 10m A 117.89.182.41
weixin.qq.com. 10m CNAME minorshort.weixin.qq.com.

C:\Users\dima>q weixin.qq.com /t A AAAA /s 192.168.110.1 --verbose
DEBU Name: weixin.qq.com
DEBU RR types: [A AAAA]
DEBU Server(s): [192.168.110.1]
DEBU Using server 192.168.110.1:53 with transport plain
DEBU Using UDP with TCP fallback: 192.168.110.1:53
minorshort.weixin.qq.com. 10m A 101.227.132.63
minorshort.weixin.qq.com. 10m A 117.89.182.41
weixin.qq.com. 10m CNAME minorshort.weixin.qq.com.
minorshort.weixin.qq.com. 10m AAAA 240e:978:d04:3003::27
minorshort.weixin.qq.com. 10m AAAA 240e:e1:aa00:1001::a
minorshort.weixin.qq.com. 10m AAAA 240e:e1:aa00:101a::48
minorshort.weixin.qq.com. 10m AAAA 240e:e9:6003:23b::25

Nov 05 '25 06:11 nasaboy

Works for me on Win 11 latest. Found maybe related https://github.com/mr-karan/doggo/issues/111, where the issue seems to be large responses timing out when nothing but udp is available.

What router brand/os/firmware are you running at home?

I must say I found it surprising that q uses cloudflare dns as a default, not my local dns setup. That is really going to trip me up.

Nov 10 '25 23:11 FaffeF

I am using Ruijie EG105G-P-L. I've tested this on several routers, and it happens every time. It might be because it exceeds the UDP 512-byte limit, but I'm not entirely sure.

Nov 11 '25 01:11 nasaboy

I must say I found it surprising that q uses cloudflare dns as a default, not my local dns setup. That is really going to trip me up.

This is only the case for Windows and is a result of different resolver selection on Windows at the moment. I don't do any development on Windows so I'm limited here, but the problem is that on *nix we look for /etc/resolv.conf for default resolver configuration.

Nov 11 '25 02:11 natesales

I'm no programmer, but there seems to be an API available to list current dns servers: https://learn.microsoft.com/en-us/windows/win32/api/windns/nf-windns-dnsqueryconfig.

Or, maybe just a warning message "WARNING: /etc/resolv.conf not found, defaulting to Cloudflare DNS servers"?

Nov 29 '25 16:11 FaffeF