CIDR rejected by 9.11.18 and higher

Summary

ondrej@isc.org requested I file this as a regression rather than a feature drop. We have a very old setup that did something clever with CIDR notation. The two CIDRs we use are 10.80.201.0/19 and 10.80.211.0/19 which (as I understand it) covers a range of addresses in 5 class C networks that need access. Making changes is hard, and it was requested that we not change how this works during the pandemic. But the new secretiive bug announcement makes me worry that this is important and we should stop lurking at 9.11.7. When I wrote the email I assumed that the CIDR change had gone from warning to error.

My original email:

> On 14 May 2020, at 15:03, William D. Colburn <wcolburn@nrao.edu> wrote:       
>
> That this upcoming security announcement is pre-announced makes me worry      
> that it is very imporant, and not one we can ignore.  Not that we should      
> have ignored the last four either, but changes like this are hard.            
>
> BIND stopped working for us at 9.11.8, and because of the intricacies of      
> making massive changes to our infrastructure, we have been sitting at         
> 9.11.7 for quite a while.  The problem we have is that you deprecated         
> support for legacy CIDR, and our configuration is now invalid.  No one        
> wants to attempt any changes to the BIND config right now because we are      
> in an infectous disease status and almost no one is at work.                  
>
> The CIDRs in question are 10.80.201.0/19, and 10.80.211.0/19, which we        
> use to control access of special hardware across a range of IP                
> addresses.  It's a "clever" solution, and clever is never really a good       
> idea, but it has been in place for more than a decade.  The official          
> request was not to change those during this pandemic.  Unfortunately,         
> the system serving these systems is also the system public-facing to the      
> internet.
>
> Is there something I can do when compiling this new bind to make CIDR         
> notation work again, as in an option at compile time?
>
> --Schlake

BIND version used

WORKS:

root@anotheruvula</home/anotheruvula/services/named># bind-9.11.7/*/named -V
BIND 9.11.7 (Extended Support Version) <id:084ef47>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Fri Jun 14 02:54:29 EDT 2019
built by make with '--disable-openssl-version-check' '--prefix=/opt/services/named/bind-9.11.7' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-ipv6' '--with-openssl=yes'
compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-18)
compiled with OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20901
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.7
threads support is enabled

FAILS:

root@anotheruvula</home/anotheruvula/services/named># bind-9.11.18/*/named -V
BIND 9.11.18 (Extended Support Version) <id:bc6c00f>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Fri Jun 14 02:54:29 EDT 2019
built by make with '--disable-openssl-version-check' '--prefix=/opt/services/named/bind-9.11.18' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-ipv6' '--with-openssl=yes'
compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-23)
compiled with OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20901
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.7
threads support is enabled

default paths:
  named configuration:  /etc/named.conf
  rndc configuration:   /etc/rndc.conf
  DNSSEC root key:      /etc/bind.keys
  nsupdate session key: /var/run/named/session.key
  named PID file:       /var/run/named/named.pid
  named lock file:      /var/run/named/named.lock

Steps to reproduce

allow-update { 
            10.80.201.0/19;
            10.80.211.0/19;
}

What is the current bug behavior?

The named exits without starting.

syslog errors:

May 14 11:54:15 anotheruvula named[9737]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch '19'
May 14 11:54:15 anotheruvula named[9737]: loading configuration: failure
May 14 11:54:15 anotheruvula named[9737]: exiting (due to fatal error)

What is the expected correct behavior?

I'd expect no error, but for many versions I got this warning:

May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:519: '10.80.211.0/19': address/prefix length mismatch

Relevant configuration files

(Paste any relevant configuration files - please use code blocks (```) to format console output. If submitting the contents of your configuration file in a non-confidential Issue, it is advisable to obscure key secrets: this can be done automatically by using named-checkconf -px.)

Just the allow-update is needed, as above.

allow-update { 
            10.80.201.0/19;
            10.80.211.0/19;
}

Relevant logs and/or screenshots

May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:519: '10.80.211.0/19': address/prefix length mismatch

and

May 14 11:54:15 anotheruvula named[9737]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch '19'
May 14 11:54:15 anotheruvula named[9737]: loading configuration: failure
May 14 11:54:15 anotheruvula named[9737]: exiting (due to fatal error)

Possible fixes

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