On 5/8/25 16:06, Simon Kelley wrote:
On 5/4/25 18:29, Dominik Derigs wrote:
Hey Simon and list readers,
we are seeing an interesting report, first the log file:
Apr 21 19:00:01 dnsmasq[310194]: query[PTR] 1.1.0.10.in-addr.arpa from
127.0.0.1
Apr 21 19:00:01 dnsmasq[310194]: forwarded 1.1.0.10.in-addr.arpa to
10.0.1.1
Apr 21 19:00:01 dnsmasq[310194]: dnssec-query[DS] 10.in-addr.arpa to
8.8.4.4
Apr 21 19:00:01 dnsmasq[310194]: Insecure DS reply received for 10.in-
addr.arpa, check domain configuration and upstream DNS server DNSSEC
support
Apr 21 19:00:01 dnsmasq[310194]: reply 10.in-addr.arpa is BOGUS DS -
not secure
Apr 21 19:00:01 dnsmasq[310194]: validation 1.1.0.10.in-addr.arpa is
BOGUS
Relevant config lines are:
no-resolv
bogus-priv
server=8.8.8.8
server=8.8.4.4
rev-server=10.0.1.0/24,10.0.1.1
server=/fritz.box/10.0.1.1
dnssec
trust-anchor=.,<the default value)
In the context of bogus-priv - is it actually expected that DNSSEC-
related queries are sent to non-local servers? My interpretation is
that they shouldn't be sent upstream here...
Best,
Dominik
This is a bit weird.
First, the bogus-priv thing. Without the
rev-server=10.0.1.0/24,10.0.1.1
line, then bogus-priv would have stopped the query going upstream,
but rev-server... gives us permission to send it to 10.0.1.1, so bogus-
priv is not relevant.
In previous releases, because the query is being sent to a domain-
specific server, dnsmasq would not have attempted to do DNSSEC
validation, unless there was a configured DS record for the domain. In
2.92 that changes to allow validation in the case that there's a chain-
of-trust through the DNS tree into the data from the domain-specific
server. The code handles the case where there's a non-secure answer from
a domain-specific server.
This works pretty well, and in fact it works in this case if you change
the rev-server line to
rev-server=10.0.1.0/8,10.0.1.1
now, dnsmasq will send the DS query for 10,in-addr.arpa to 10.0.1.1, get
an unsigned answer, log a warning and continue.
Because the prefix is 24, in your case, the query goes to 8.8.8.8, and
then we hit something strange. in-addr.arpa is DNSSEC signed and 10.in-
addr.arpa is NXDOMAIN. We'd therefore expect a signed answer proving
that 10.in-addr.arpa doesn't exist.
If you ask the authoritative servers for in-addr.arpa for the DS record
for 10.in-addr.arpa, you do, indeed get a signed answer saying it
doesn't exist.
If you ask 8.8.8.8 or 1.1.1.1, you get an unsigned answer that says it
doesn't exist. That's what trips things up. My guess is that we're
tripping over code in the big public nameservers that stops them
spamming the in-addr.arpa nameservers with all the millions of pointless
and erroneous reverse lookups for RFC1918 addresses that escape into the
public DNS. It's not at all sensible to trust non-signed non-existence-
of-DS answers from non-domain-specific upstream servers. That provides a
trivial way to bypass all of DNSSEC.
I guess we could solve this by making bogus-priv add the equivalent of
local=/10.in-addr.arpa/
local=/168.192.in-addr.arpa/
etc
to the config, but only for DNSSEC, basically the same low-down trick
that Google and Cloudflare are playing.
TL;DR
Change the prefix length in rev-server to 8 and it all works fine. If we
want to avoid tripping up on this, we may need to play tricks.
Any suggestions welcome.
Cheers,
Simon.
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=8ddabd11bcd948d13b88f0ccbfe2e319fc042e40
Looks like a good solution to me, and certainly fixes the immediate problem.
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
