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@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
