We operate bind resolvers on debian, rh8 and rh9, and recently updated to address the CVE above. On debian, once we updated to 9.18.41 we received reports of domains in the .cd cctld failing to resolve. After some debugging and research we concluded that bind rejects the glue at the root for .cd because it's in a different tld (.net) and instead proceeds to resolve the NS records. The gtld servers refer back to .cd resulting in a delegation loop and servfail (relevant queries at the end of the message).
Next we updated bind on rh8 to the redhat recommended version (9.16.23-RH) with the fix. Again, .cd started to fail as expected. Next we upgraded bind on rh9 (9.18.29) which redhat claims contains the fix. Surprisingly this did not break .cd resolution and we don't use "forward" or "static-stub" config statements to help it resolve, so it's pure recursion. So the question is, is it possible that a bind version with the fix for the CVE above would be able to resolve domains in the .cd cctld given the current configuration of .cd at the root? -------- ; <<>> DiG 9.18.41-1~deb12u1-Debian <<>> @a.root-servers.net. hosting.cd +norec ;; AUTHORITY SECTION: cd. 172800 IN NS ns-root-23.scpt-network.net. cd. 172800 IN NS ns-root-21.scpt-network.net. cd. 172800 IN NS ns-root-22.scpt-network.net. ;; ADDITIONAL SECTION: ns-root-23.scpt-network.net. 172800 IN A 161.97.87.130 ns-root-21.scpt-network.net. 172800 IN A 102.68.62.15 ns-root-22.scpt-network.net. 172800 IN A 102.68.60.15 -------- ; <<>> DiG 9.18.41-1~deb12u1-Debian <<>> @a.gtld-servers.net. ns-root-21.scpt-network.net +norec ;; AUTHORITY SECTION: scpt-network.net. 172800 IN NS ns1.scpt-network.cd. scpt-network.net. 172800 IN NS ns2.scpt-network.cd. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
