Colin Vidal 2130d4fecc 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.		2026-03-25 01:09:28 +00:00
..
startperf	Reformat shell scripts with shfmt	2023-10-26 10:23:50 +02:00
system	remove legacy NS processing limit check	2026-03-25 01:09:28 +00:00
testdata/wire	move all optional tests from bin/tests to bin/tests/optional	2018-03-09 14:12:47 -08:00
.gitignore	Move environment variables from conf.sh to pytest	2024-05-09 17:08:08 +02:00
meson.build	replace the build system with meson	2025-06-11 10:30:12 +03:00
test_client.c	Add and use global memory context called isc_g_mctx	2025-08-04 11:29:26 +02:00
test_server.c	Add and use global memory context called isc_g_mctx	2025-08-04 11:29:26 +02:00