Hello Simon, On Thu, Jan 23, 2025 at 12:23:38AM +0000, Simon Kelley wrote: > 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.
ack. > 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. What you say is right, but I cannot follow your conclusion. Agreed, in the say 99% (just to have a number without comma) where there is no chain-of-trust to the public DNS it's nonsensical to ask the specified server-IP about DNSSEC stuff. But it's also (and IMHO even more) nonsensical to ask the upstream recursor about DNSSEC for my invented domain. So we have: The current implementation is useless and surprising in 99% and wrong in the remaining 1%. Sending also the DNSSEC queries about your private domain to the server is only useless in 99% (but not surprising) and the right thing to do in the remaining 1%. So I'd claim that not distinguishing between DNSSEC and "ordinary" and just forwarding all requests concerning example.com to <ip> is the right and consistent thing to do and might even be easier to implement. Additionally asking the public recursor about your home domain might even be considered a privacy issue. > 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 With my above argument and if you really want to keep the current behaviour possible, I'd say: Make the behaviour that you call "dnssec" the default and create a syntax to enable that split configuration where all ordinary queries go to 1.2.3.4 but the DNSSEC ones to upstream. I look forward to your reply and wonder if it contains another DNS lesson because I'm missing something relevant. Best regards Uwe
signature.asc
Description: PGP signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
