]> git.ipfire.org Git - thirdparty/bind9.git/commit
rpz_rrset_find() now recurses on ISC_R_NOTFOUND
authorEvan Hunt <each@isc.org>
Sun, 22 Mar 2026 03:28:24 +0000 (20:28 -0700)
committerEvan Hunt <each@isc.org>
Mon, 23 Mar 2026 19:30:16 +0000 (12:30 -0700)
commitae67c1851dcd4ce3e03012f7a6ac6cfa0eb6b37f
tree99af8cc3350f22695b24f99e3ba2a3946ddb4b65
parentb3115825c8fa492d4ac9e4f06888abcf98142bfe
rpz_rrset_find() now recurses on ISC_R_NOTFOUND

previously, rpz_rrset_find() behaved differently depending on whether
a cache lookup returned DNS_R_DELEGATION or ISC_R_NOTFOUND.  the former
indicates the presence of a cached NS rrset, and the latter indicates
that the cache is cold or that all NS rrsets above the query name have
expired. both results indicate that the caller should recurse, but
rpz_rrset_find() only recursed in the case of DNS_R_DELEGATION.

the nsip-wait-recurse and nsdname-wait-recurse test cases in the
rpzrecurse system test were dependent on this misbehavior. the test
server was configured with a lame delegation, so that recursion always
failed, but once the lame delegation was expired due to a zero TTL, the
cache returned ISC_R_NOTFOUND, which caused the recursion not to be
attempted. the test seemed to be observing a delay before recursion
succeeded, but it was actually observing a delay before recursion was
skipped. fixing this bug caused the test to fail.

the test server has now been reconfigured so that recursion succeeds
after a delay, instead of failing. now we're able to test that
we're waiting for the successful completion of recursion.
bin/tests/system/rpzrecurse/ans5/ans.py
bin/tests/system/rpzrecurse/ns3/named2.conf.j2
bin/tests/system/rpzrecurse/ns3/named3.conf.j2
bin/tests/system/rpzrecurse/ns3/root.db
bin/tests/system/rpzrecurse/ns4/child.example.db
bin/tests/system/rpzrecurse/tests.sh
lib/ns/query.c