getdnsapi / stubby

Stubby is the name given to a mode of using getdns which enables it to act as a local DNS Privacy stub resolver (using DNS-over-TLS).
https://dnsprivacy.org/dns_privacy_daemon_-_stubby/
BSD 3-Clause "New" or "Revised" License
1.19k stars 99 forks source link

Failed to resolve specific DNS request with OpenWrt 22.03 #339

Open amitguptakiitian opened 1 year ago

amitguptakiitian commented 1 year ago

Hi,

I am using an Asus rt-ax53u router flashed with 22.03.3 OpenWRT firmware. I have enabled stubby for DOT. dnsmasq is failed to resolve the DNS URL if the DNS response is more than 512 bytes. nslookup output for the failed response is as below. image

I tried capturing the lo interface network packets and observed that message truncated bit is set in the DNS response. Ideally, either edns0 option or dns request must be be sent over tcp to handle such scenario but it is not happening. Below is the DNS response snapshot were message truncated bit is set.

image

OpenWrt version r20028-43d71ad93e

OpenWrt target/subtarget ramips/mt7621

Device ASUS RT-AX53U

dnsmasq Configuration image

I checked with the lower version 19.07 of openwrt and it works. Below is the response captured at lo interface. image

the below response I received with OpenWrt 22.03. image

can someone help me to resolve this issue? Thanks in Advance!

saradickinson commented 1 year ago

So I'm a bit confused by this one. In getdns-1.6.0/stubby-0.3.0 (Openwrt 19.07) a fix was included to prevent the issue where stubby was sending back responses that were larger than the senders EDNS0 packet size: https://github.com/getdnsapi/getdns/issues/430, and instead stubby truncated answers to cause the sender to re-try over TCP. So firstly, I'm surprised you don't see this behaviour in Openwrt 19.07.... Secondly I'm surprised that dnsmasq is not retrying over TCP when it gets a response from Stubby with TC=1 in 22.03. I don't know enough about dnsmasq to know if your config is involved though!

Also see https://github.com/getdnsapi/getdns/issues/495 for discussion of the use of name compression to reduce (but not eliminate) the problem for senders that only implement UDP....