[ Resending complete message, previous draft was incomplete... ]
> On 12 Jul 2021, at 11:18 am, Paul Hoffman <paul.hoff...@icann.org> wrote:
>
> The current text is sufficient to tell resolver developers, and resolver
> operators, why they should even think about underscore labels when they
> create a QNAME minimisation strategy. Elevating such a strategy to a SHOULD
> as a work-around for broken middleboxes that might (hopefully!) be fixed in
> the future seems like a very wrong direction for the WG.
If this were just a work-around for breakage, I'd be more inclined
to agree, but it is also a solid opportunity to improve performance,
because privacy-relevant changes of administrative control across
special-use labels should be very rare to non-existent.
So short-circuiting qname minimisation when a special-use label is
encountered seems like a win-win.
Measuring qname minimisation for TLSA RRs I see that today breakage
of qname minimisation is rare. An example is:
https://dnsviz.net/d/_tcp.u24.altospam.com/YOx4nQ/dnssec/
https://dnsviz.net/d/_25._tcp.u24.altospam.com/YOx4IA/dnssec/
In which many (but not all) of the nameservers return NXDOMAIN for the
ENT. Out of 150k RRsets, O(10) have ENT-related issues.
So one might reasonably neglect the breakage, but it is not clear that
we need to go looking for it, just to "punish" the operators in question.
There's an opportunity here to make qname minimisation more performant for
SRV, TLSA, ... lookups, speeding up Domain Control and LDAP server lookups,
email delivery, ...
Of course if the WG cannot come to consensus on "SHOULD"/"RECOMMENDED", I'll
gratefully settle for the current "MAY" (thanks for the document update)...
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
