On Mon, Jun 15, 2020 at 10:47 AM John Levine <jo...@taugh.com> wrote:
> In article < > cah1iciouffmryorewhhtbqfnnserw3rvups8pzc8cvnehys...@mail.gmail.com> you > write: > >E.g. use an FQDN belonging to you (or your company), so the namespace > would > >be example.com.zz under which your private names are instantiated. > > The obvious question is if an organization is willing to use > example.com.zz, why wouldn't they use zz.example.com with split > horizon DNS to keep that subtree on their local network? > There are lots of reasons that are subtle. The main one is failure modes and the implications. I.e. Attempting to use a third-party resolver, or if a VPN disconnects, etc. should only send queries to the root servers (and get NXDOMAIN responses). Similarly, any operational failure on the split-brain itself has the same result (root servers only). Another one is search lists. Using search lists with domains that terminate in one of these non-TLDs (e.g. zz) ensures that the same semantics applies (root only). This is one place where QNAME minimization is also significantly beneficial. Independent of this proposal, I think it would be good to delegate these non-TLDs to the AS112++ servers (RFC 7535), to limit impact on the root servers. Also independent of that, I also think it might be worth considering whether/how to upgrade RFC 7534 to use a signed zone and securely delegating to that from as112.arpa. One completely bonkers idea would be to deploy a wildcard delegation in the root zone to AS112++ servers, rather than doing piecemeal delegations, but that's not a hill I'm willing to die on. :-) > For whatever reason, people like short names where short means two > components. > Yes, and people like ponies. The only time short names have any applicability is when connecting to hosts directly, e.g. with SSH, and where some form of search list appends the rest of the name. That practice is better handled within SSH config files rather than in DNS search lists. Someone should write that up as a BCP. :-) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
