On Thu, Jan 25, 2018 at 08:17:17PM -0500, Ted Lemon wrote: > On Jan 25, 2018, at 7:48 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > See my other upstream message quoted below. There are deployed > > uses of local "localhost" zones, and a mandate to break them is > > not well motivated in this draft. > > Okay, so if I understand you correctly, you are saying that: > > Rather than setting up a unique domain name to solve a problem > you had with postfix, you used localhost, for convenience > You believe that this practice, or similar practices, are widespread
I showed examples, of uses of "localhost". Some use the TLD itself for the usual local IPs, others employ subdomains of "localhost" as a sensibly convenient place to park "for my eyes only" local DNS data. These examples are not exhaustive. > I think you acknowledge that you can still do this hack even if > the document says you mustn't. You say that, and I don't deny that, but I am not saying it, because there should be no need to ignore a MUST in an RFC just to do as the administrator asks and serve locally configured data. > You also propose that recursive resolvers not forward localhost, but then > there's actually no way to reply with anything other than NXDOMAIN, No, a resolver can return any locally configured "localhost" data. Many resolvers (BIND, unbound, ...) can serve some local data on the side. > because a recursive resolver won't have authoritative information. Well, it BIND the data would be authoritative, while in unbound "local-data" can take a variety of forms. > Maybe you mean a hybrid server that is recursive for domains for > which it isn't authoritative? Yes. All the recursive servers I've used can also serve some local data. They should be able to continue to do that even when for the "localhost" TLD. I also note that the draft does not adequately discuss what to do with queries with the DO bit set[1]. Presumably a forged NXDOMAIN without appropriate root-zone NSEC records may not be adequate in that case. It probably (my opionion) makes more sense to obtain, and cache the NSEC and RRSIG records from the root servers, than to return a "bogus" reply. -- Viktor. P.S. [1] I expect such queries to be rare, many on this list may be aware of my stated preference to see DNSSEC handled almost always in a loopback iterative resolver, with applications relying on the returned AD bit, rather than doing their own DNSSEC validation. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop