Dear Fujiwara-san,
On 13/03/2025 10:12, Kazunori Fujiwara wrote:
The wording "desirable upper limit" and the low values on the table in
section 5 caught me off guard.
Could I suggest that it is renamed to "observed max value"?
Unless I completely misunderstand the concept.
Which I may do as I see "number of CNAME/DNAME chains" with a value of
1.
I intended "Desirable upper limit" to be the value
recommended as a good DNS setting.
Is there a better term?
I believe "recommended upper limit" would be clearer, for me at least.
But then the looming question for me is that there can only be one limit
realistically.
The protocol limit is well understood and I leave it out of the discussion.
Now we are left with two limits:
- the recommended one, where we advise people to use and realistically
translates to "software is guaranteed to process up to this limit",
- the hard limit, which realistically translates to "software will
produce a failure if that limit is reached".
So there is a gap between the two where any value there could be
supported or not depending on software implementation.
And realistically operators will go for the recommended value because
they would like consistency and predictability.
And that is why I was caught unaware with the low values used in the
table because a limit of 1 CNAME indirection does not seem realistic to
me in the currently observed operational practice.
I also understand that no value in the "hard limit" column means
unlimited.
Would it be better to explicitly say there are no limit ?
No, this is fine. I was just noting my understanding of the table before
presenting my feedback.
- number of RRs in an RRSet; this can be limited to a few hundreds I
suppose,
a hundred is too large, I think. but many domain names use too many TXT RRs.
I am looking at those limits from a DoS perspective (that we get a lot
of research the last couple of years).
"A couple of hundreds" as a limit, in my opinion at least, strikes a
good balance between our intention to put limits on resources but still
keep them reasonable for current operational practices while leaving
space for future developments without requiring software updates.
The DoS factor is also kept manageable/acceptable and such attacks are
not interesting anymore.
Best regards,
-- Yorgos
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
