Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

[Peter van Dijk <[e-mail]>]

tl;dr: No.

On Wed, 2021-07-07 at 13:54 -0400, Warren Kumari wrote:
> If resolving " _ldap._tcp.ad.example.com", once you hit the _tcp label
> you are quite likely in ENT territory, and some implementations
> (especially those behind firewalls / middleboxes) are still broken.

Then they shall suffer. It is not the job of the resolver vendors and
operators to keep working around broken auths. We'd like to remove more
workarounds from the resolver, not add more.

> There is also a performance hit.

This is fair.

> Version 10 of the document added:
> "Another potential, optional mechanism for limiting the number of
> queries is to assume that labels that begin with an underscore (_)
> character do not represent privacy-relevant administrative
> boundaries. For example, if the QNAME is "_25._tcp.mail.example.org"
> and the algorithm has already searched for "mail.example.org", the
> next query can be for all the underscore-prefixed names together,
> namely "_25._tcp.mail.example.org"."

This is good text, with the note that I like Peter Thomassen's
modification of only jumping to the next non-underscore label, instead
of immediately to the end the moment an underscore is found.

> What does the WG think? Does the privacy win of getting this deployed
> and enabled sooner outweigh the potential small leak if there *is* a
> delegation inside the _ territory of the name?

This looks like a false choice to me. I am unconvinced deployment is
hindered by the difference between MAY and SHOULD for this
recommendation. I also don't think the leak potential is very
interesting.

> Should the advice above be strengthened to SHOULD / RECOMMENDED?

No. MAY is a perfect level for this advice. It is good to let
implementers know that somebody thought of this trick, and it might
make sense for many implementations, but we should not be overly
prescriptive.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/