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
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
