[Dnsmasq-discuss] DNSSEC query sent upstream despite local domain

[Simon Kelley]

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.