[Dnsmasq-discuss] DNSSEC in dnsmasq's parent zone

[Simon Kelley]

On 1/18/25 21:56, Uwe Kleine-König wrote:
> Hello Simon,
> 
> On 1/18/25 16:06, Simon Kelley wrote:
>> I'm having a little difficulty understanding exactly what's going on 
>> in your description, but I think I understand the underlying problem, 
>> and I've demonstrated it and fixed it here, so I'm hoping it will fix 
>> your case too.
>>
>> What causes the problem is that when dnsmasq gets a query in forwarder 
>> mode for a zone which it's authoritative for, it answers the query 
>> itself instead of forwarding it.
>>
>> The alternative to that is to forward the query to the configured 
>> upstream recursor, which will recurse and ask dnsmasq in authoritative 
>> mode. The recursor will then return the answer to dnsmasq acting as 
>> forwarder and  the answer will get returned to the original requestor. 
>> That gives the correct answer, but uses more bandwidth and takes 
>> longer, so answering directly is the right thing to do; almost always.
>>
>> The problem arises when the parent of the delegated zone is DNSSEC 
>> signed and the client is doing DNSSEC validation, as delv does in your 
>> example. We can assume that the delegated zone is NOT signed, since 
>> dnsmasq doesn't provide facilities for DNSSEC in auth mode.
>>
>> For explanation, assume that the parent zone is example.com, and 
>> dnsmasq.example.com is delegated to dnsmasq with a suitable NS record.
>>
>> delv will work down the chain of trust, starting at the root, and get 
>> as far as example.com is gets to the delegation to 
>> dnsmasq.example.com, notes it's a new zone, and therefore asks for a 
>> DS record for dnsmasq.example.com. dnsmasq.example.com is not signed, 
>> so what it gets is a signed proof that the DS record for 
>> dnsmasq.example.com doesn't exist. It can now return data from 
>> dnsmasq.example.com which is not DNSSEC signed, no problem. The DNSSEC 
>> standard specifies that DS records comes from the parent auth server, 
>> so the recursor will ask the auth server for the example.com domain 
>> for the DS record for dnsmasq.example.com, and that is able to provide 
>> the signed proof of non-existence.
>>
>> The above works fine with any recursive server, but not via dnsmasq as 
>> a forwarder when dnsmasq is also authoritative. The reason is that 
>> when dnsmasq gets the query for DS dnsmasq.example.com, it notes that 
>> it is authoritative for dnsmasq.example.com and returns the answer 
>> directly. Since there's no DS record in it's data for the zone, it 
>> answers that the DS record doesn't exist, which is fine, but it can't 
>> provide cryptographic proof of non-existence. Delv can't prove that 
>> the the subdmomain is not signed, but there are no signatures. It does 
>> the right thing, and complains.
>>
>> The fix for this is very simple: suppress answering queries for auth 
>> zones locally when the query is for root of the zone AND for a DS 
>> record. Now DS dnsmasq.example.com gets forwarded to the recursor, 
>> which asks the auth server for example.com, which has the correct 
>> DNSSEC signed "DS dnsmasq.example.com" does not exist answer. dnsmsq 
>> acting as forwarder returns that to delv and all is good.
>>
>> I've pushed a patch to the git repo to do exactly that at
>>
>> https://thekelleys.org.uk/gitweb/? 
>> p=dnsmasq.git;a=commit;h=8ce27433f8b2e17c557cb55e4f16941d309deeac
>>
>> if you can get that code into you setup and try again, I'd be very 
>> grateful.
> 
> It seems you interpreted the gaps in my report correctly. I'm not sure 
> forwarding just the request to DS is sufficient, I would expect you also 
> need to forward NS (or answer that from the --auth-server parameter?)
> 
> Anyhow, I'll investigate how to update dnsmasq on my OpenWrt machine 
> with your patch and report back.

Thanks. I did some more testing and found a couple more bugs. One is 
theoretical and one is real in the sense that I saw it happen, but it 
requires the forwarder part of dnsmasq to be configured with

  --cache-rr=ANY,

so you probably haven't hit it. Anyway, I tagged 2.91test8, so best to 
test that.

The NS record is fine. It does get answered from the --auth-server param 
and a client should get the same answer from either the parent zone's 
auth server or the child zone's as long as both have been configured the 
same. It's in the unsigned child zone, so DNSSEC RRs don't apply.

The DS record is the only thing that HAS to come from the parent, to 
prove that the child is not signed.


Cheers,

Simon.

> 
> Thanks!
> Uwe
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss