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/ _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
