validating the fix for CVE-2025-40778

[Matus UHLAR - fantomas]

On 08.12.25 18:24, Veaceslav Revutchi wrote:
>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. 

Yes, this is the correct behaviour.

cd.                     172800  IN      NS      ns-root-21.scpt-network.net.
cd.                     172800  IN      NS      ns-root-22.scpt-network.net.
cd.                     172800  IN      NS      ns-root-23.scpt-network.net.

scpt-network.net.       172800  IN      NS      ns1.scpt-network.cd.
scpt-network.net.       172800  IN      NS      ns2.scpt-network.cd.


>The gtld servers refer back to .cd
>resulting in a delegation loop and servfail (relevant queries at the
>end of the message).

this is the expected behaviour.

>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?

you are lucky that the root servers provide glue records:

% dig +nocmd +nocomments +nostats +noquestion ns cd. @k.root-servers.net.

cd.                     172800  IN      NS      ns-root-22.scpt-network.net.
cd.                     172800  IN      NS      ns-root-23.scpt-network.net.
cd.                     172800  IN      NS      ns-root-21.scpt-network.net.
ns-root-23.scpt-network.net. 172800 IN  A       161.97.87.130
ns-root-22.scpt-network.net. 172800 IN  A       102.68.60.15
ns-root-21.scpt-network.net. 172800 IN  A       102.68.62.15

otherwise there would be no chance to resolve anything in the "cd" domain.

That delegation loop should be solved as soon as possible.


-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows found: (R)emove, (E)rase, (D)elete