Hi Philip
On Thu, Jul 11, 2024 at 08:50:57AM +0200, Philip Homburg wrote:
> > Even RFC 1034 says "Bound the amount of work", but explicitly
> > prescribed numbers in an RFC may end up being arbitrary.
> >
> > When there is a difference between something working well and not
> > working well, it may either be due to too much work (too much NS
> > lookup indirection for example) or implementation inefficiency (use
> > of data structures that are inefficient, or resource limits on that
> > particular platform such as amount of memory available).
>
> That is a different issue. The issue is that recursive resolvers implement
> arbitrary default limits to avoid issues. Any zone that exceeds those
> limits is in trouble.
>
> At any moment a popular resolver can release a new version of the software
> with lower limits. Breaking zones that worked before.
>
> That is a very unstable situation that in can be avoided mostly by only
> increasing limits.
>
> But when new attacks suggest that limits need to be lowered, this becomes
> a real risk.
>
> > So a limit on section counts may be appropriate, but the limit that
> > an implementation is able to perform well with is best decided by
> > its implementors. There may be implementations that may perform
> > well with thousands of RRs on commodity hardware and support very
> large RRsets.
>
> How that help a zone owner? A zone that only works with some resolvers?
Operations may be better served by a minimum expected level than a
maximum.
Mukund
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
