Question about "too many records"

[Tim Daneliuk]

On 8/1/24 17:14, John Thurston wrote:
> After reading the CVE description, it isn't clear to me how the degraded performance is manifest.
> 
> If 300 A-records exist for the name 'foo', do we expect:
> 
>  1. queries for A-records for 'foo' will be slower than expected
>  2. all queries for 'foo' will be slower than expected
>  3. every query to the server will be slower than expected
>  4. something else
> 


I also have a basic confusion about this general topic.

I got bit by this when I updated to .28 because I had some fairly
large round robin pools within our non-routable network.

In my (admittedly brief) research, I was under the impression that
the limitation was total number of records per type to reduce
the risk of cache poisoning, not for performance reasons.

If that's so, there needs to be a way to disable it by policy/option
for the local horizon in a split horizon implementation where one
might need a lot of records and the risk of cache poisoning is
essentially zero.

If someone would please help deconfuse me, I would be deeply appreciative.


> 
> --
> Do things because you should, not just because you can.
> 
> John Thurston    907-465-8591
> John.Thurston at alaska.gov
> Department of Administration
> State of Alaska
> 
> On 8/1/2024 2:03 PM, James Stegemeyer wrote:
>> J,
>>
>> This issue has been covered by earlier threads, and is mentioned on the
>> BIND 9.18.28 release notes.
>> Starting with BIND 9.18.28 changes were made to mitigate performance
>> impact CVE-2024-1737 BIND database will be slow if if a very large
>> number of RRs exist at the same name.
>>
>> If you find yourself in this situation, you can increase the
>> "max-records-per-type" parameter which was introduced in bind 9.18.28.
>> I find that it is common for large Active Directory zone to have a large
>> quantity of RR with the same name which concentrates at the domain APEX
>> and for the LDAP SRV records. Increasing this parameter dilutes the
>> protection you will receive against CVE-2024-1737 the default value of
>> 100 was chosen based on a performance knee which occurs at around 100
>> records.
>>
>> You can use the following command, if you have access to a Linux based
>> system to create a histogram of number of RRs for the same name.
>>
>> dig -t axfr $zone  @$server | awk '{print $1,$4}' | sort | uniq -c | sort -n
>>
>>
>> Thanks,
>> --James Stegemeyer
>>
>> On 8/1/24 17:09, J Doe wrote:
>>> Hi,
>>>
>>> I run my own validating recursive resolver with BIND 9.18.28.
>>>
>>> In the resolver logs I noticed:
>>>
>>>
>>>     01-Aug-2024 10:30:22.294 query-errors: info: client @0xec879280280
>>>         127.0.0.1#14435 (bf10x.hubspotemail.net): query failed (too many
>>>         records) for bf10x.hubspotemail.net/IN/A at query.c:7842
>>>
>>>
>>> The client in this case was my mail server software.  What does "query
>>> failed (too many records) ..." mean ?
>>>
>>> Is this BIND saying that the client (the mail server software),
>>> requested too many records or that the result of the query yielded too
>>> many records or something else ?
>>>
>>> Thanks,
>>>
>>> - J
>>
>