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)
ond...@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.tillm...@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
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
