encountering "too many records" loading authoritative zone even when AXFR report shows nothing exceeding max-records-per-type

[Ondřej Surý]

Hi Irwin,

BIND 9.16 is end-of-life, and we also don't provide support for commercial appliances
based on BIND 9.

Since you didn't provide any actionable details (like the contents of the zone), I would
suggest you try to reproduce the issue you have with supported version of BIND 9.
Either BIND 9.18.28 or BIND 9.20.0 - both are freely available from our site.

Ondrej
--
Ondřej Surý (He/Him)
ondrej at isc.org

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 13. 8. 2024, at 13:18, Irwin Tillman <irwin.tillman3 at gmail.com> wrote:
> 
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users