On Wed, Jul 10, 2024 at 05:10:47PM +0200, Yorgos Thessalonikefs wrote:
> Hi Mukund,
>
> On 10/07/2024 16:57, Mukund Sivaraman wrote:
> > The current DNS protocols have been able to evolve so well since 1987
> > because of their flexibility. I suggest that limits be left to
> > implementations rather than be set in stone in RFC. It could result in
> > surprises when DNS data is extra-ordinary depending upon the
> > implementation. But I feel it's better to leave the flexibility of the
> > protocol as it is.
> I agree about the flexibility and evolution in general but with my
> implementer hat on I don't want those kind of limits to be left to
> implementations because implementations cannot back arbitrary limit choices
> without documents/research. CVEs help with that though :)
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).
A recent CVE had to do with O(N^2) linked list traversals that was
problematic when parsing large DNS messages. A different implementation
could have parsed such messages somewhat more efficiently. DNS messages
are not well suited to be parsed efficiently as their contents have to
be scanned sequentially to get at further data, and matched up (e.g., in
building RRsets). So even an efficient implementation may not perform
well on thousands of RRs in a message. 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.
I cannot describe other CVEs that are in the works, but some of them are
due to deficient data structures that need not affect other
implementations.
There are already limits that are in place in implementations for a
variety of functions. A draft can document cases that may be limited
with details of what would happen without limits so implementors are
aware. My only suggestion is that prescribing numbers seems like it
might go too far.
Mukund
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
