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

[Uwe Kleine-König]

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!
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20250118/0d4115f3/attachment.sig>