Question about "too many records"
John Thurston
john.thurston at alaska.gov
Thu Aug 1 22:14:19 UTC 2024
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
--
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240801/473490d8/attachment-0001.htm>
More information about the bind-users
mailing list