Bind ignores cz.cc and cu.cc domains from RPZ blocking zone

Summary

When we added domains like test.cz.cc or test.cu.cc in RPZ zone, bind will not lookup those 2 TLDs in RPZ and always send request to upstream.

BIND version used

Tested on Ubuntu20 BIND 9.16.1-Ubuntu (Stable Release) id:d497c32

Tested on Centos8 BIND 9.11.26-RedHat-9.11.26-6.el8 (Extended Support Version) id:3ff8620

Steps to reproduce

1. Install bind and dns-utils
2. Configure named.conf
3. Configure test.zone
4. Validate with named-checkconf -z
5. Start named service
6. Test dig command for working block: dig test.co.cc @127.0.0.1
7. Test dig command for not working block: dig test.cz.cc @127.0.0.1

What is the current bug behavior?

DNS queries against domain test.cu.cc and test.cz.cc are going always to upstream DNS for resolving and times out. Even if those domains are configured in test.zone RPZ file. They are either ignored from RPZ checking or there is some hidden rule to always send those to upstream. Another cc domains like test.co.cc and test.cc.cc return 127.0.0.1 correctly as defined in RPZ file.

What is the expected correct behavior?

Domains test.cu.cc and test.cz.cc should be blocked with RPZ as it is for every other domain defined in RPZ.

Relevant configuration files

named.conf:

options {
	directory "/var/cache/bind";

	recursion yes;

	querylog yes;

	allow-transfer {
		none;
	};

	forwarders {
		8.8.8.8;
	};

	dnssec-validation auto;

	listen-on { 127.0.0.1; };
	
	// enable response policy zone.
	response-policy {
		zone "rpz-block.com";
	};
};

zone "rpz-block.com" {
    type master;
    file "/etc/named/test.zone";
};

RPZ block zone file /etc/named/test.zone:

$TTL 10
@	IN	SOA	localhost. root.localhost. (
                     2022012701    ;Serial
                     180        ;Refresh
                     180        ;Retry
                     604800        ;Expire
                     10        ;Minimum TTL
)
@ IN	NS    localhost.
test.co.cc 180 IN A 127.0.0.1
test.cc.cc 180 IN A 127.0.0.1
test.cu.cc 180 IN A 127.0.0.1
test.cz.cc 180 IN A 127.0.0.1

Relevant logs and/or screenshots

Expected behavior from "dig test.co.cc":

dig test.co.cc @127.0.0.1

; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> test.co.cc @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2548
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 53d1528c6349377174a40a8261f2761a8758415c9e57bcf5 (good)
;; QUESTION SECTION:
;test.co.cc.			IN	A

;; ANSWER SECTION:
test.co.cc.		5	IN	A	127.0.0.1

;; AUTHORITY SECTION:
rpz-block.com.		10	IN	NS	localhost.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 27 10:38:18 UTC 2022
;; MSG SIZE  rcvd: 119

named debug log:

27-Jan-2022 10:38:18.960 client @0x7f234c00c040 127.0.0.1#54687 (test.co.cc): query: test.co.cc IN A +E(0)K (127.0.0.1)
27-Jan-2022 10:38:18.960 client @0x7f234c00c040 127.0.0.1#54687 (test.co.cc): rpz QNAME Local-Data rewrite test.co.cc via test.co.cc.rpz-block.com

Debug logs from "dig test.cz.cc":

dig test.cz.cc @127.0.0.1

; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> test.cz.cc @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 21c9b32a3c911d3dbec3359461f276754b1b560848f9b487 (good)
;; QUESTION SECTION:
;test.cz.cc.			IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 27 10:39:49 UTC 2022
;; MSG SIZE  rcvd: 67

named debug log:

7-Jan-2022 10:39:39.312 client @0x7f234c00c040 127.0.0.1#39671 (test.cz.cc): query: test.cz.cc IN A +E(0)K (127.0.0.1)
27-Jan-2022 10:39:39.312 fetch: test.cz.cc/A
27-Jan-2022 10:39:40.512 timed out resolving 'test.cz.cc/A/IN': 8.8.8.8#53
27-Jan-2022 10:39:40.512 address not available resolving 'test.cz.cc/A/IN': 240e:ff:9000:1100::1a7#53
27-Jan-2022 10:39:40.512 address not available resolving 'test.cz.cc/A/IN': 240e:ff:9000:1100::1a6#53
27-Jan-2022 10:39:44.312 client @0x7f2368220c50 127.0.0.1#39671 (test.cz.cc): query: test.cz.cc IN A +E(0)K (127.0.0.1)
27-Jan-2022 10:39:44.312 fetch: test.cz.cc/A
27-Jan-2022 10:39:49.312 client @0x7f234c00c040 127.0.0.1#39671 (test.cz.cc): query failed (SERVFAIL) for test.cz.cc/IN/A at ../../../bin/named/query.c:9441
27-Jan-2022 10:39:49.312 client @0x7f234c01cf50 127.0.0.1#39671 (test.cz.cc): query: test.cz.cc IN A +E(0)K (127.0.0.1)
27-Jan-2022 10:39:49.312 client @0x7f234c01cf50 127.0.0.1#39671 (test.cz.cc): servfail cache hit test.cz.cc/A (CD=0)
27-Jan-2022 10:39:49.312 client @0x7f234c01cf50 127.0.0.1#39671 (test.cz.cc): query failed (SERVFAIL) for test.cz.cc/IN/A at ../../../bin/named/query.c:7190

Possible fixes

(If you can, link to the line of code that might be responsible for the problem.)