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.
Cheers,
Simon.
On 1/15/25 15:02, Uwe Kleine-König wrote:
Hello,
I own a domain (kleine-koenig.org) and my OpenWrt router ("happy")
(OpenWrt 24.10.0-rc5 with dnsmasq-full 2.90-r3) in my homenet uses
(among others) the following configuration settings:
domain=kk4.kleine-koenig.org
local=/kk4.kleine-koenig.org/
server=/kleine-koenig.org/192.168.128.3
auth-server=happy.kleine-koenig.org,192.168.128.4
auth-zone=kk4.kleine-koenig.org
On the nameserver on 192.168.128.3 I have:
$ dig +short @192.168.128.3 kk4.kleine-koenig.org NS
happy.kleine-koenig.org.
$ dig +short @192.168.128.3 happy.kleine-koenig.org
192.168.128.4
.
So dnsmasq serves a recursor on 192.168.144.1 and the auth on 192.168.128.4.
From a host in the homenet I can resolve happy.kk4.kleine-koenig.org just
fine:
$ dig +dnssec +short @192.168.144.1 happy.kk4.kleine-koenig.org
192.168.144.1
but when trying to verify that address using dnssec this fails:
$ delv @192.168.144.1 happy.kk4.kleine-koenig.org
;; no valid RRSIG resolving 'kk4.kleine-koenig.org/DS/IN':
192.168.144.1#53
;; broken trust chain resolving 'happy.kk4.kleine-koenig.org/A/IN':
192.168.144.1#53
;; resolution failed: broken trust chain
When asking 192.168.128.3 it works fine:
$ delv @192.168.128.3 happy.kk4.kleine-koenig.org
; unsigned answer
happy.kk4.kleine-koenig.org. 417 IN A 192.168.144.1
as does it when asking for an unrelated dnssec'd name:
$ delv @192.168.144.1 www.powerdns.org
; fully validated
www.powerdns.org. 3276 IN CNAME powerdns.org.
www.powerdns.org. 3276 IN RRSIG CNAME 13 3 3600
20250123000000 20250102000000 13432 powerdns.org.
eVhqAkmhMBgvFYcR+g3kRU2ERtYcJBJghurQsNS4Uz7tyttghf5AU7PX
iG4HrsAjwNoyzzOycfxzYrD9r8cHIw==
powerdns.org. 3276 IN A 149.210.160.248
powerdns.org. 3276 IN RRSIG A 13 2 3600
20250123000000 20250102000000 13432 powerdns.org.
L9J8qokzJSgO1lHeHRY+lZnHNbJL4mxaHCmpSrIHrZB0rhgrC5//Wi6Z
w9e08oMHP+lDWA+NfpZgUBh5l94gmw==
The problem (I think) is that dnsmasq doesn't answer the query for a NS
on the recursive side of dnsmasq:
$ nslookup -type=ns kk4.kleine-koenig.org 192.168.144.1
Server: 192.168.144.1
Address: 192.168.144.1#53
Non-authoritative answer:
*** Can't find kk4.kleine-koenig.org: No answer
Authoritative answers can be found from:
(but it does on the auth side:
$ nslookup -type=ns kk4.kleine-koenig.org 192.168.128.4
Server: 192.168.128.4
Address: 192.168.128.4#53
kk4.kleine-koenig.org nameserver = happy.kleine-koenig.org.
).
I would have expected that the NS query on the recursive side to also
yield happy.kleine-koenig.org?! Am I missing something, or is this a bug?
Best regards
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
