Question about "too many records"

[Petr Špaček]

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 expected
Query like that will consume more CPU time - and thus make everything 
else also slower.

The limit is controlled by max-records-per-type configuration statement.
See 
https://bind9.readthedocs.io/en/v9.18.28/reference.html#namedconf-statement-max-records-per-type

The more you allow the slower it will become.

>>  2. all queries for 'foo' will be slower than expected
This can happen too, when 'foo' has large number of RR _types_ on it, 
like TYPE1000, TYPE1001, ..., TYPE1100.

Mitigation/limit for this is controlled by max-types-per-name 
configuration statement. See 
https://bind9.readthedocs.io/en/v9.18.28/reference.html#namedconf-statement-max-types-per-name

The more you allow the slower it will become.

>>  3. every query to the server will be slower than expected
... while query for 'foo' is being processed.

>>  4. something else

This is potential attack vector for resolvers: An attacker can always 
create large RRset on authoritative server under attacker's control and 
then query resolver for the humonguous RRset repeatedly - slowing down 
everything.

> 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.

This is not related to cache poisoning, see above.

-- 
Petr Špaček
Internet Systems Consortium