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

Sat Feb 1 23:29:35 UTC 2025

On 1/23/25 08:56, Uwe Kleine-König wrote:
> 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.

The comment on the code which implements this has the following comment

  /* F_DNSSECOK as agument to search_servers() inhibits forwarding
      to servers for domains without a trust anchor. This make the
      behaviour for DS and DNSKEY queries we forward the same
      as for DS and DNSKEY queries we originate. */

In other words, we try and give the same answers when we get a DS or 
DNSKEY query as we we would use in doing DNSSEC validation.

I'm not sure this is very sensible. This whole arrangement was put into 
place as a attempt to make the --server=/domain/ configuration play 
nicely with DNSSEC and specifically to try and avoid the possibility 
that switching on DNSSEC validation would break existing configurations.

I have some thoughts on a way to do this much better, which will work in 
all cases. It needs some experimentation and testing, so I'd like to 
return to this after the 2.91 release.

The plan is to eliminate the distinction between DNSSEC and non-DNSSEC 
servers and instead use proof-of-non-existence-of-DS records.

as an example

server=/subnet.example.com/1.2.3.4

and we lookup host.subnet.example.com

The DNSSEC validation will attempt to find the DS record for 
subnet.example.com.

This might exist as configured trust anchor, which is the way to get 
DNSEC validate on a detached server.

If not we will ask 1.2.3.4 for the record.

The result may be a DS record signed by the example.com DNSKEY, and 
validation can continue.

It may also be a proof of non-existence of DS subnet.example.com signed 
with the example.com DNSKEY in which case an unvalidated answer is OK.

It may be forwarded to the authoritative server for example.com which 
knows nothing about subnet.example.com, since subnet.example.com is a 
made-up domain which only exists at 1.2.3.4. This would normally result 
in a BOGUS result from validation, but in this case the code can infer 
the situation from the existence of the server=/subdomain.example.com/ 
configuration and turn this into a valid DS-doesn't-exist record. This 
allows lookups to 1.2.3.4 to work when its data is unsigned.

This means that things work when the data from 1.2.3.4 is signed and the 
chain-of-trust extends from the root. They also work when data from 
1.2.3.4 is signed but there is no chain of trust from the root, but a 
local trust anchor is provided. The system also works when data from 
1.2.3.4 is unsigned and the chain of trust from the root proves that. 
Finally it works when the data from 1.2.3.4 is unsigned and the domain 
just doesn't exist in any chain of trust.

This is still a somewhat fuzzy idea, and the explanation may reflect 
that, but I hope it makes some sense. I shall implement a prototype in 
the near future.

> 
>> 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

Cheers,

Simon.