On 2024-08-02 04:30, Petr Špaček wrote:
On 02. 08. 24 0:52, Tim Daneliuk wrote:
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
On 02. 08. 24 0:52, Tim Daneliuk wrote:
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
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
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
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
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
6 matches
Mail list logo
