[Dnsmasq-discuss] querying DS from wrong server

[Simon Kelley]

On 7/7/25 08:40, Uwe Kleine-König wrote:
> Hello Simon,
> 
> thanks for your patch!
> 
> On 7/7/25 00:37, Simon Kelley wrote:
>> On 6/23/25 21:44, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> back in January I hit a DNSSEC related problem that I reported on that
>>> list, and that resulted in commit
>>> 8ce27433f8b2e17c557cb55e4f16941d309deeac.
>>>
>>> Now I slightly changed my setup to make it more robust, it works as
>>> follows now:
>>>
>>> I have a authoritative DNS server for kleine-koenig.org running on
>>> [::1]:10053 and dnsmasq (running on OpenWrt) configured with
>>>
>>>      server=/kleine-koenig.org/::1#10053
>>>      domain=kk4.kleine-koenig.org
>>>
>>> . The problem I have now is that a dnssec verifying resolver querying the
>>> forwarding side of dnsmasq sees:
>>>
>>>      $ delv www.kleine-koenig.org
>>>      ;; broken trust chain resolving 'kleine-koenig.org/DNSKEY/IN': ::1#53
>>>      ;; broken trust chain resolving 'www.kleine-koenig.org/A/IN': 127.0.0.1#53
>>>      ;; resolution failed: broken trust chain
>>>
>>> I think the problem is that the DS query for kleine-koenig.org is also
>>> forwarded to [::1]:10053. Instead it should be forwarded to the same
>>> server that (non-DS) queries for .org are sent to.
>>>
>>> So the logic implemented in 8ce27433f8b2e17c557cb55e4f16941d309deeac was
>>> to short-sighted, a DS query should always go to the parent; not only for
>>> the zones that dnsmasq is authoritative for.
>>
>> Agreed, I just pushed 2.92test15 which implements this.
>>
>> I did a load of testing, and I think every situation works now.
>>
>> Domain specific server, no DNSSEC records, for a domain which is provably not signed higher up the hierarchy.
>>
>> Domain specific server, no DNSSEC records, for a domain which should be signed. (Dnsmasq gives this the benefit of the doubt, but logs a warning.)
>>
>> Domain specific server with DNSSEC records, that the higher domains don't have  DS record for, but there is trust anchor in dnsmasq config.
>>
>> Domain specific server with DNSSEC records, that the higher domains do have  DS record for.
>>
>> For those last two, DS queries work the same way, returning either the local trust anchor, or the DS from the parent.
> 
> I think that's still broken. To use a testcase that we both can use, I did the following:
> 
> 	dnsmasq -p 10053 -d -q --server=/debian.org/dns4.easydns.info
> 
> and then query using:
> 
> 	$ delv @::1 -p 10053 debian.org A
> 	;; chase DS servers resolving 'debian.org/DS/IN': ::1#10053
> 	;; missing expected cookie from ::1#10053
> 	;; missing expected cookie from ::1#10053
> 	;; missing expected cookie from ::1#10053
> 	;; missing expected cookie from ::1#10053
> 	;; broken trust chain resolving 'debian.org/DNSKEY/IN': ::1#10053
> 	;; broken trust chain resolving 'debian.org/A/IN': ::1#10053
> 	;; resolution failed: broken trust chain
> 
> . This request makes dnsmasq log:
> 
> 	dnsmasq: query[A] debian.org from ::1
> 	dnsmasq: forwarded debian.org to 2620:49:4::10
> 	dnsmasq: reply debian.org is 151.101.194.132
> 	dnsmasq: reply debian.org is 151.101.66.132
> 	dnsmasq: reply debian.org is 151.101.2.132
> 	dnsmasq: reply debian.org is 151.101.130.132
> 	dnsmasq: reply debian.org is <RRSIG>
> 	dnsmasq: query[DNSKEY] debian.org from ::1
> 	dnsmasq: forwarded debian.org to 2620:49:4::10
> 	dnsmasq: reply is truncated
> 	dnsmasq: query[DNSKEY] debian.org from ::1
> 	dnsmasq: forwarded debian.org to 2620:49:4::10
> 	dnsmasq: reply debian.org is <DNSKEY>
> 	dnsmasq: reply debian.org is <DNSKEY>
> 	dnsmasq: reply debian.org is <DNSKEY>
> 	dnsmasq: reply debian.org is <RRSIG>
> 	dnsmasq: reply debian.org is <RRSIG>
> 	dnsmasq: query[DS] debian.org from ::1
> 	dnsmasq: forwarded debian.org to 2620:49:4::10
> 	dnsmasq: reply debian.org is NODATA
> 	...
> 
> In my understanding the DS query must not go to 2620:49:4::10.

and it does, if you compile dnsmasq with DNSSEC validation, and enable 
it :) That's of course wrong, blame force of habit.

2.92test16 should fix this. It certainly works for me in your excellent 
test case.


Cheers,

Simon.
> 
> Best regards
> Uwe