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
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
