Hi Libor Just one point:
On Fri, Jul 12, 2024 at 12:08:06PM +0200, libor.peltan wrote:
> Actually, this is nothing new, for example RFC 9460 (introduction of SVCB)
> already introduces such limit:
>
> "To avoid unbounded alias chains, clients and recursive resolvers MUST
> impose a limit on the total number of SVCB aliases they will follow for each
> resolution request. This limit MUST NOT be zero, i.e., implementations MUST
> be able to follow at least one AliasMode record. The exact value of this
> limit is left to implementations."
>
> I'd say this is the precedence that we should follow.
The text above says that the exact value of the limit is left to
implementations. It's not that various functions are currently not
limited in implementations. As pointed out in an earlier message in this
thread, even RFC 1034 suggests that work be bounded. As a few examples,
a typical resolver implementation has limits such as timeouts of how
long it is waiting for responses from upstream NSes, how many iterations
it will perform when resolving, the amount of NS indirection it will
follow, the number of NSDNAMEs it will use in an RRset, the number of
NSEC3 iterations it will perform when validating, etc. It'd be good to
have a document that describes all these cases to watch out for, and
what happens if such functions were not bound.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
