[Dnsmasq-discuss] Code dump.

[Dominik Derigs]

Am 12/2/24 um 12:38 AM schrieb Simon Kelley:
> This code has been extensively tested by me, but I'd like to hear how 
> others are getting on with it. It has not been easy to get right. The 
> --log-queries option has a new version, --log-queries=proto, which 
> includes information about which query was used for each transaction.
>
>
> Cheers,
>
> Simon.

Hey Simon,

I'm actively maintaining a special branch in the Pi-hole project 
"update/dnsmasq" always following the bleeding edge master of your 
public repository. Your most recent changes have been merged Monday 
evening/night, I am actively using it (incl. "proto"), there may be 
more, we don't really track this. In case anything odd comes up, I'll 
forward it here. Otherwise, I have seen the following in the logs while 
scrolling through them:

...

Dec  4 16:59:10 dnsmasq[2465200]: UDP 215 127.0.0.1/56995 query[PTR] 
66.2.168.192.in-addr.arpa from 127.0.0.1
Dec  4 16:59:10 dnsmasq[2465200]: UDP 215 127.0.0.1/56995 forwarded 
66.2.168.192.in-addr.arpa to 192.168.2.1
Dec  4 16:59:10 dnsmasq[2465200]: UDP 215 127.0.0.1/56995 reply 
192.168.2.66 is print.fritz.box (DNSSEC signed)

...

Dec  4 16:59:19 dnsmasq[2465200]: UDP 238 192.168.2.2/50790 config error 
is REFUSED (EDE: invalid data)

...

The first thing is the "DNSSEC signed" here, where 192.168.2.1 is the 
local DHCP router. It is configured using 
--rev-server=192.168.2.0/24,192.168.2.1 --server=/fritz.box/192.168.2.1. 
No trust-anchors are specified nor is the local home network using any 
DNSSEC. According to my logs, this has been an issue for longer.

The other thing is the spurious logging of "config error is REFUSED 
(EDE: invalid data)" which seems to happen quite often. There are no 
other log lines concerning query 238. As this started only on Dec 2 
evening, it seems related to your latest commits as that's when I 
restarted dnsmasq on latest master. The query itself is a SOA record 
generated by the repeater and sent to 0.0.0.0. I don't really think 
there's a dnsmasq bug but maybe we can improve logging for this case. I 
will send the pcap in a second mail off-list as the record itself 
contains sensitive information about my local network.

Dynamically switching over to TCP on UDP truncation seems to be working 
as expected.

I will keep looking for other strange things over the next days.

Best,

Dominik