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

[Simon Kelley]

On 1/20/25 10:32, Uwe Kleine-König wrote:

>> It was ignored. The logic is somewhat tortuous, but it goes like this.
>> The server=/kleine-koenig.org/192.168.128.3 is not available for queries
>> which need DNSSEC validation; a DS query always needs DNSSEC validation, so
>> it doesn't get sent to 192.168.128.3.
> 
> Huh. Is this a bug that is hard to fix, or this is beneficial in any
> situation and so works as intended?

The rationale goes like this.

The most common use for server=/example.com/<ip> is to resolve names 
which don't appear in the public DNS, accessible, via delegations, from 
the root. Typically addresses in RFC1918 space behind a NAT router. 
After all if it was delegated from the global DNS, there would be no 
point: the ordinary recursors could find the data.

If that domain isn't connected to the global DNS via delegation, it's 
even less likely to be connected to the global DNS via a chain-of-trust, 
so there's no point in doing DNSSEC validation. If the domain is DNSSEC 
signed, since there's no chain-of-trust from the root, there needs to be 
a DS record in dnsmasq's configuration which provides a trust anchor for 
that domain.

Hence the rule that DNSSEC validation is turned off be default for a 
domain which is being answered by a domain-specific server, but it gets 
turned back on again is there's a DS record configured for the domain.

The hardest part of allowing configuration to make a  domain-specfic 
server behave as if there is a DS record in the dnsmasq config when 
there isn't is inventing a backwards-compatible extension to the option 
syntax: internaly it's just setting a bit in the structurethat 
represents the server.

maybe

dnssec-server=/example.com/1.2.3.4

or

server=/example.com/dnssec-1.2.3.4

or

server=dnssec/example.com/1.2.3.4




> 
> Anyhow, for testing I added an NS record for kk4.kleine-koenig.org to the
> public zone and dropped
> 
> 	server=/kleine-koenig.org/192.168.128.3
> 
> from the config. Then I get
> 
> 	root at happy:~# delv happy.kk4.kleine-koenig.org
> 	; unsigned answer
> 	happy.kk4.kleine-koenig.org. 0	IN	A	192.168.144.1
> 	happy.kk4.kleine-koenig.org. 0	IN	A	192.168.145.1
> 
> .
> 
>> If you add a DS record for
>> kleine-koenig.org to your config, it should work, assuming that
>> 192.168.128.3 is DNSSEC capable.
> 
> After first trying with dns-rr= which somewhat worked (as I succeeded to
> create a DS record with it), it didn't impress dnsmasq enough to make
> dnssec verification happy.
> 
> Now I added
> 
> 	trust-anchor=kleine-koenig.org,34607,13,2,FF05DA4F2E6A2692421FA7ED99DF07205A6A04ABC917F26CD7E781520A2652D1
> 
> which matches the DS record for kleine-koenig.org in both the public DNS
> and the internal view and now delv happy.kk4.kleine-koenig.org works
> (same output as above, with "unsigned answer" as expected).
> 
> That's a bit inconvenient because I have to duplicate that information.
> An "auto" mode that just uses kleine-koenig.org/DS would be good. And if
> the config doesn't match, DNSSEC is broken anyhow, isn't it?
> So IMHO such an auto-mode being the default would be sane, but that
> relates to the question above about why DNSSEC isn't used for server=.

See my reply above.

> 
> (Side note: I first tried:
> 
> 	trust-anchor=,kleine-koenig.org,34607,13,2,FF05DA4F2E6A2692421FA7ED99DF07205A6A04ABC917F26CD7E781520A2652D1
> 
> and
> 
> 	trust-anchor=IN,kleine-koenig.org,34607,13,2,FF05DA4F2E6A2692421FA7ED99DF07205A6A04ABC917F26CD7E781520A2652D1
> 
> (with a , after the = and class=IN respectively), but dnsmasq didn't
> like that
> 
> 	dnsmasq[1]: bad trust anchor at line 43 of /etc/dnsmasq.conf
> 
> despite the manpage stating
> 
> 	--trust-anchor=[<class>],<domain>,<key-tag>,<algorithm>,<digest-type>,<digest>
> 
> which suggests to me that the , has to be there. (And I have no idea
> what to pass for class apart from "IN".))

The manpage is wrong : just fixed it.

it should be

--trust-anchor=<domain>,[<class>,]<key-tag>,<algorithm>,<digest-type>,<digest>

The class can be IN, CH or HS.


Cheers,

Simon.