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

[Simon Kelley]

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.