Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Viktor Dukhovni <[e-mail]>]

On Thu, Jan 25, 2018 at 08:17:17PM -0500, Ted Lemon wrote:

> On Jan 25, 2018, at 7:48 PM, Viktor Dukhovni <[e-mail]> 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.