I'm encountering the max-records-per-type limit when loading an authoritative
zone, so named won't load the zone.
But an audit of the zone (count the records returned by AXFR) finds no records
exceeeding the limit.
Is anyone else encountering this?
--
Details:
I'm using Infloblox NIOS, a commercial product which includes BIND.
NIOS 9.0.4 apparently is based on BIND 9.16.23-S1 (at least, that's what named
logs at start).
The vendor presumably customizes it and backports selected ISC patches to it.
Infoblox released a NIOS patch that includes the change to address
CVE-2024-1737.
Their patch renamed BIND's new max-records-per-type limit to
named_max_records_per_type, and changed its default from 100 to 500.
And their patch renamed BIND's new max-types-per-name limit to
named_max_types_per_name, and kept the default at 100.
Without that patch, named will load my authoritative zone.
With the patch, it won't load:
named[40000]: general: dns_master_load: example.org: too many records
named[40000]: general: dns_master_load: too many records
named[40000]: general: zone example.org/IN: loading zdb zone: initial load
error: too many records
Infoblox couldn't find the offending record(s) in my zone causing named to hit
the limit.
(Perhaps it would be helpful if when named hits this limit, it logs the
(view,owner,RRtype) involved?)
Infoblox advised that they found that if they increment the
max-records-per-type limit (what NIOS calls named_max_records_per_type)
from (NIOS' default of) 500 to 2000, my zone will load.
That implies that named believes my zone is hitting that limit.
I've audited the zone for potential max-records-per-type violations using the
following
(while running without the patch, so named loads the zone):
dig -t axfr example.org. SERVER| awk '{print $1,$4}' | sort | uniq -c |
sort -n
I expected to find some cases of (owner,RRtype) exceeding 500 (and below 2000).
There were none. My closest hit was under 450.
That suggests to me that named believes the limit is exceeded even when an AXFR
audit doesn't see that.
(NIOS did behave as expected for a trivial test case.
I created a test zone containing a case of (owner,RRtype) with 499 records; it
loaded.
I incremented it to 500 records; it loaded.
I incremented it to 501 increments, it refused to load.)
So I'm wondering if anyone else (running vanilla BIND version that has the
CVE-2024-1737 fix, or some other variant)
is encountering this as well.
If no one else running vanilla BIND is encountering it, maybe it's due to a bug
introduced in Infoblox's customized version of named.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
