At Wed, 6 Sep 2017 10:00:01 -0400, tjw ietf <[email protected]> wrote:
> When the idea of having a Call for Adoption for this document came up, we > thought long and hard about this one. However, the comments from the > working group focused this document to address the specific issue of the > local hostname. > > This starts a formal Call for Adoption for > draft-west-let-localhost-be-localhost > > The draft is available here: > https://datatracker.ietf.org/doc/draft-west-let-localhost-be-localhost/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. I've read draft-west-let-localhost-be-localhost-06.txt. I don't have a strong opinion on whether to adopt it, but if it's adopted I'm willing to review subsequent versions. I have one high-level comment: I wonder whether the name can be different from "localhost". My impression on some of the controversy on this proposal is related to compatibility with the existing practice with this name (e.g., some people may want to have their preferred AAAA or A RDATA at their own risk). If it can be a completely new TLD we at least don't have to worry about that type of conflict. Of course this will require more procedural overhead such as new registration for the special-use registry and doesn't help any existing practice that assumes 'localhost' always means a loopback address. But such a practice is not 100% safe today anyway (and in my understanding that's why this draft was written) and even if the proposed new semantics for 'localhost' is standardized its deployment will take time (and I suspect non-compliant behavior will stay quite long). So it might be even safer to introduce a new name and have applications that need this property gradually migrate to it. It's just a thought, I'm not pushing the idea. But in any case, it may be worth explaining in the draft why the name must be 'localhost'. I have a couple of other minor comments on the current version. All of them are somehow related to how authoritative servers are supposed to behave in the context of this draft: - Section 1 In addition, recursive and authoritative DNS servers are required to return "NXDOMAIN" for such queries. This increases the likelihood Should authoritative servers other than the root server really be required to return NXDOMAIN? Except for the root server, if an authoritative server receives a query for a name that doesn't belong to any zone it serves, it's generally considered a (some sense of) bogus query, and my understanding of common response to this kind of query is either REFUSED or a referral to the closest ancestor zone known to the server. I don't see a reason for changing the behavior of these servers specifically for 'localhost'. - Section 3 5. Authoritative DNS servers MUST respond to queries for localhost names with NXDOMAIN. Same comment applies. - Section 4.2.1 This document requests that a DNSSEC insecure delegation (that is, a delegation with no DS records) be inserted into the root-zone, delegated to "blackhole-[12].iana.org". This would violate the above 'MUST'. If we choose this option (and if we also generally keep this MUST) some more clarification (such as making an exception) will be needed. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
