<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>After reading the CVE description, it isn't clear to me how the
degraded performance is manifest.</p>
<p>If 300 A-records exist for the name 'foo', do we expect:</p>
<ol>
<li>queries for A-records for 'foo' will be slower than expected</li>
<li>all queries for 'foo' will be slower than expected</li>
<li>every query to the server will be slower than expected</li>
<li>something else<br>
</li>
</ol>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a class="moz-txt-link-abbreviated" href="mailto:John.Thurston@alaska.gov">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
<div class="moz-cite-prefix">On 8/1/2024 2:03 PM, James Stegemeyer
wrote:<br>
</div>
<blockquote type="cite" cite="mid:f6eab41b-d2e2-44e4-87cb-746a50ba1f97@stegemeyer.net">J,
<br>
<br>
This issue has been covered by earlier threads, and is mentioned
on the
<br>
BIND 9.18.28 release notes.
<br>
Starting with BIND 9.18.28 changes were made to mitigate
performance
<br>
impact CVE-2024-1737 BIND database will be slow if if a very large
<br>
number of RRs exist at the same name.
<br>
<br>
If you find yourself in this situation, you can increase the
<br>
"max-records-per-type" parameter which was introduced in bind
9.18.28.
<br>
I find that it is common for large Active Directory zone to have a
large
<br>
quantity of RR with the same name which concentrates at the domain
APEX
<br>
and for the LDAP SRV records. Increasing this parameter dilutes
the
<br>
protection you will receive against CVE-2024-1737 the default
value of
<br>
100 was chosen based on a performance knee which occurs at around
100
<br>
records.
<br>
<br>
You can use the following command, if you have access to a Linux
based
<br>
system to create a histogram of number of RRs for the same name.
<br>
<br>
dig -t axfr $zone @$server | awk '{print $1,$4}' | sort | uniq -c
| sort -n
<br>
<br>
<br>
Thanks,
<br>
--James Stegemeyer
<br>
<br>
On 8/1/24 17:09, J Doe wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
I run my own validating recursive resolver with BIND 9.18.28.
<br>
<br>
In the resolver logs I noticed:
<br>
<br>
<br>
01-Aug-2024 10:30:22.294 query-errors: info: client
@0xec879280280
<br>
127.0.0.1#14435 (bf10x.hubspotemail.net): query failed
(too many
<br>
records) for bf10x.hubspotemail.net/IN/A at query.c:7842
<br>
<br>
<br>
The client in this case was my mail server software. What does
"query
<br>
failed (too many records) ..." mean ?
<br>
<br>
Is this BIND saying that the client (the mail server software),
<br>
requested too many records or that the result of the query
yielded too
<br>
many records or something else ?
<br>
<br>
Thanks,
<br>
<br>
- J
<br>
</blockquote>
<br>
</blockquote>
</body>
</html>