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 athttps://thekelleys.org.uk/gitweb/? p=dnsmasq.git;a=commit;h=8ce27433f8b2e17c557cb55e4f16941d309deeacif 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
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
