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

Sat Jan 18 15:06:58 UTC 2025

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 at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss