Hi Veaceslav,
I am able to resolve rawbank.cd using BIND 9.20.16:
% dig IN A rawbank.cd @192.168.40.82
; <<>> DiG 9.10.6 <<>> IN A rawbank.cd @192.168.40.82
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2361
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;rawbank.cd. IN A
;; ANSWER SECTION:
rawbank.cd. 1800 IN A 41.222.216.201
;; Query time: 934 msec
;; SERVER: 192.168.40.82#53(192.168.40.82)
;; WHEN: Wed Dec 10 05:24:33 EST 2025
;; MSG SIZE rcvd: 55
This is because I have a mirror zone setup:
zone "." {
type mirror;
request-ixfr no;
file "root.zone";
masterfile-format text;
};
and so BIND seems to be accepting the glue provided by the root zone
as authoritative. At least, a pcap shows no queries about the cd TLD
itself, only rawbank.cd. Do you perhaps have a similar mirror zone
configured?
Thank you,
Darren Ankney
On Mon, Dec 8, 2025 at 6:24 PM Veaceslav Revutchi <[email protected]> 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. 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.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
