On Mon, Jul 17, 2023 at 12:20 PM John R Levine <jo...@taugh.com> wrote:
> Just to be clear, I think it's quite reasonable to encourage people to put > tokens at _name but I still see it as a matter of taste, not a technical > issue. > > On Mon, 17 Jul 2023, Brian Dickson wrote: > > TCP being triggered on resolver-auth is much more of concern, > particularly > > when the underlying cause (large RRsets) is preventable. > > I take your point, but we're not talking about a lot of traffic. If any > particular token is checked as often as once a day, that's a lot. At what > scale does the TCP traffic become an issue? > The stuffed apex does not only include those tokens, e.g. SPF and friends, which get queried A LOT. So, adding validation tokens to the apex causes collateral damage via non-token apex records. TCP traffic is several orders of magnitude more expensive than UDP. Anything that bumps up the proportion of TCP traffic in a statistically meaningful way causes issues. E.g. Suppose TCP is 1% of traffic. Something bumping it to 1.5% might seem benign, but in reality is causing 50% extra cost. Whatever the impact, if it does not have some corresponding benefit overall, or particularly relative to op-ex vs revenue, that's a bad outcome. DNSSEC is maybe a red herring, because there are operational benefits on the overall query ecosystem. Specifically, with aggressive NSEC, resolver-auth load (and particularly DOS/DDOS triggered load) actually goes down A LOT, in the worst case scenarios. > > >> The only somewhat plausible argument I see against stuffing the apex is > >> that if people are sloppy, they might invent tokens that could be > confused > >> with each other. > > > > The technical term would be "collision" rather than "confusion". > > One harm of collision is the impact on automation. Whether at the apex or > > in underscore prefixes, the collision "space" suffers from the "birthday > > paradox" scaling problem. > > The birthday paradox is relevant if you only have 366 birthdays, but not > if people are using 20 character identifier strings which give you a > 10^25 point name space. (See the Cisco TXT records in my previous > message.) This is an aesthetic preference, not a technical one. > In the absence of the aforementioned draft, there is no specific guidance that would lead ALL token issuers to use 20 character identifiers. And without doing so, the likelihood of some issuers having conflicting semantic choices (and thus token choices) is non-trivial. E.g. any mail package that gets used, or hosting software, or third party apps generally. E.g. I've seen a software vendor "foo" with their registered domain "foo.example", who have lots of customers running "foo" as a service. The vendor was given guidance to use "_foo_example" (an encoding of their domain) rather than "_foo", to protect themselves from collisions. But there is also a likelihood of some non-zero subset of operators of "foo as a service" picking "_foo" and causing collisions. The draft would provide sufficient guidance to reduce the latter from being relatively common (lots of assumptions etc., but better than no guidance.) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
