remove legacy NS processing limit check

Commit `604d8f0b967563b0ba9dcd4f09559fdd9e21dfbe` introduced during 9.19
development cycle a check to ensure the resolver never attempts to
lookup more than 20 NS names. This limit was introduced by
`3a44097fd6c6c260765b628cd1d2c9cb7efb0b2a` as part of the CVE-2022-2795.

However, this test relies on the fact that, at the time, the NS names
were processed in a specific order in the nameserver, as this snip from
the log (from a build on `604d8f0` branch) running the test illustrates:

```
24-Mar-2026 21:19:46.346 dispatch 0x7fdaa722d200: success, length == 19956, addr = 0x7fdaa0a7c102
24-Mar-2026 21:19:46.346 dispatch 0x7fdaa722d200: got valid DNS message header, /QR 1, id 14328
24-Mar-2026 21:19:46.346 dispatch 0x7fdaa722d200: search for response in bucket 7213: success
24-Mar-2026 21:19:46.354 received packet from 10.53.0.3#5300
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  14328
;; flags: qr aa; QUESTION: 1, ANSWER: 0, AUTHORITY: 999, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: baf16b0241efc700
;; QUESTION SECTION:
;large-referral.example.net.	IN	A

;; AUTHORITY SECTION:
;large-referral.example.net. 300	IN	NS	ns1.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns2.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns3.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns4.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns5.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns6.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns7.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns8.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns9.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns10.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns11.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns12.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns13.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns14.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns15.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns16.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns17.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns18.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns19.fake.redirect.com.
;large-referral.example.net. 300	IN	NS	ns20.fake.redirect.com.
```

This is not true anymore, as the NS are in a random order. Moreover,
commit `3c33e7d9370006b1599e3d99c0d5fa6a6dad7979` introduced the
randomization of the selection of the NS names to lookup, which make the
test potentially unreliable, as it now doesn't mean anything to check
the nameserver does not query `ns21.fake.redirect.com.`, as it could be
the first one, or in any position form the randomized list.

Another test has been added in commit
`c67b52684f11652b07afaa75a917f6f0355dbca6` which test both the
randomization of the NS name to be looked up, as well as the upper bound
limit of NS  name lookup to be done.

For all those reasons, this specific legacy check is now removed.

diff --git a/bin/tests/system/resolver/tests.sh b/bin/tests/system/resolver/tests.sh
index dcaf655b26d406f0c35b7de819181266cc60183a..bd8f8972c231b7968b653b1079dc90300d7c33df 100755 (executable)
--- a/bin/tests/system/resolver/tests.sh
+++ b/bin/tests/system/resolver/tests.sh
@@ -855,12 +855,6 @@ if [ "${findname_call_count}" -gt 1000 ]; then
   echo_i "failed: ${findname_call_count} (> 1000) findname() calls detected for large-referral.example.net"
   ret=1
 fi
-# Check whether the limit of NS RRs processed for any delegation
-# encountered was not exceeded.
-if grep -Eq "dns_adb_createfind: started (A|AAAA) fetch for name ns21.fake.redirect.com" ns1/named.run; then
-  echo_i "failed: unexpected address fetch(es) were triggered for ns21.fake.redirect.com"
-  ret=1
-fi
 if [ $ret != 0 ]; then echo_i "failed"; fi
 status=$((status + ret))