On 14. 07. 21 5:13, Brian Dickson wrote:
On Tue, Jul 13, 2021 at 10:01 AM Viktor Dukhovni <[email protected]
<mailto:[email protected]>> wrote:
> On 13 Jul 2021, at 6:22 am, Petr Špaček <[email protected]
<mailto:[email protected]>> wrote:
>
> As Viktor pointed out in
https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/
<https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/>
, it seems that this problem plagues roughly tens out of 150k
domains he surveyed. I think this makes further discussion about
_necessity_ of the workaround kind of moot.
The plural of anecdotes is not data... unfortunately.
So, I don't recall who presented it, where, or when, but it was some
time in the last couple of years, maybe at an IETF or OARC meeting.
But, the gist of the presentation was that the presenters studied query
sources from a number of vantage points, over a period of years, and
concluded there are approximately 3 million resolvers.
Those resolvers are not all directly connected to the Internet, and
some/many are configured as forwarders (with potentially multiple
forwarders in chains/trees).
The point here is, that Viktor represents one out of three million
vantage points, which undoubtedly have different characteristics in
terms of resolver software and version, and intermediate servers (e.g.
forwarding to resolvers, or forwarding to forwarders).
Additionally, Viktor's data set was TLSA, which is already a niche set
that is self-selected to be on DNSSEC-signed zones, meaning relatively
new and mainstream code bases (possibly over-generalizing admittedly.)
Examining larger data sets on domains that are not DNSSEC-signed, may
show a different prevalence of the ENT problem.
The other distinction is that the problems leading to bad ENT results,
may not be on the authoritative servers, but may be in front of them
(close to the authoritatives), or may be other middle-boxes closer to
the resolvers, or between forwarders and resolvers, etc. Thus the scope
of the ENT problem may vary based on the vantage point being used to
collect results.
Thus, in the absence of any statistically meaningful data, I disagree
with the mootness of the issue.
That doesn't mean we can't reach consensus, of course, and given that
this is a -bis document, and we are discussing how to handle the corner
case of underscore ENTs, some focus should be given to the impact rather
than the prevalence. This includes both the impact on code paths, and on
the effects to client apps affected by ENT broken-ness.
It may be helpful to note that the draft itself already differentiates
behavior by the number of labels, in section 2.3 (in a MAY context)
using the MAX_MINIMIZE_COUNT logic. Thus, if an implementation is
already doing that work, adding underscore handling might not be a large
burden (and might mesh nicely in terms of coding). For example, in
evaluating the break-points when partitioning the labels to limit the
total number of queries, the sequence COULD treat any contiguous
sequence of underscore labels as if it were a single label, and then do
its partitioning of labels using the same relative logic.
The main point being, if the implementer is already doing anything other
than literally iterating over all the labels one at a time, under all
circumstances, then adding underscores into its handling isn't likely
significantly burdensome.
Maybe, or maybe not. We cannot know for sure until it's implemented in a
real resolver. In my experience, major resolver implementations contain
little but important details that make even seemingly simple tweaks way
harder to implement than it looks on paper.
Not having running code to support this proposal this late in
publication process is IMHO another reason why it should stay at MAY level.
Petr Špaček
The difference between the many-labels problem and the underscore
situation, is the difference between weakness against attacks and
inefficiency (many labels), versus actual brokenness (for some
indeterminate fraction of the namespace from some indeterminate portion
of the resolvers on the Internet).
I'm hoping to advance the discussion even if no one is persuaded.
Brian
Full disclosure, I only tested TLSA records. I can't speak to what
one might expect with SRV or other record types. Yes, failures are
not that common, for what is worth another example:
https://dnsviz.net/d/_tcp.mail.ncsc.de/YO3DpQ/dnssec/
<https://dnsviz.net/d/_tcp.mail.ncsc.de/YO3DpQ/dnssec/>
https://dnsviz.net/d/_25._tcp.mail.ncsc.de/YO3Bsw/dnssec/
<https://dnsviz.net/d/_25._tcp.mail.ncsc.de/YO3Bsw/dnssec/>
Here the "A" query for the ENT was unexpectedly "REFUSED". :-(
If implementations at least seriously consider the advice to treat
special-use labels *specially*, I'll declare victory...
--
Viktor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
