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