Blackhole option anomaly

Summary

Using the following option seems to block AXFR queries and rndc commands

blackhole { none; };

I also reported this behaviour here : https://lists.isc.org/pipermail/bind-users/2022-February/105709.html

BIND version used

Most likely started in 9.17.19

Not present in 9.17.15 -> 9.17.19

Present in 9.17.19 -> 9.18.0

Steps to reproduce

Setup two authoritative servers (1 primary and 1 master) Allow AXFR transfer from one to another

Try using and commenting the following option

blackhole { none; };

I have tested in different configuration setups (in case of a conflict with an other option), and I'm seeing the same behaviour.

What is the current bug behavior?

Zones update on the primary servers are not applied to the secondary servers The primary stops sending notify queries and the secondary is unable to transfer the zone However, AXFR queries with dig keep answering as expected.

These rndc commands are ignored (checked with tcpdump packet capture)

• retransfer
• refresh

Nothing is logged

Zone also doesn't refresh when the Refresh timer described in SOA expires.

What is the expected correct behavior?

I'm expecting zone transfers to keep functioning whenever the zone is update on the primary server. Notify queries sent and logged (and visible in logfiles and packet capture)

Relevant configuration files

options {
	blackhole {
		"none";
	};
	directory "/named/database";
	dump-file "/named/database/dump_named.txt";
	};
	listen-on port 53 {
		192.168.10.1/32;
	};
	pid-file "/named/etc/named.pid";
	server-id "1";
	recursion no;
	also-notify {
		192.168.10.2/32;
	};
	allow-transfer {
		192.168.10.2/32;
	};
	zone-statistics no;
};

Relevant logs and/or screenshots

None

Possible fixes

Commenting blackhole { none; }; restores the expected behaviour` Also, blackholing a random IP also restores the expected behaviour.

Not really sure how that parameter exactly works, but it would seem like blackhole { none; }; is interpreted as a blackhole { all; }; here.