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

[Viktor Dukhovni <[e-mail]>]

On Thu, Jan 25, 2018 at 03:48:35PM -0500, Ted Lemon wrote:

> With all due respect, that's your stated opinion.   I asked if you have
> some specific use case in mind where what the draft says will cause a
> problem.   It sounds like the answer is no, but if I'm mistaken I'd like
> to hear what's motivating this opinion.

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.  It merely states a difficult to
justify assertion that returning NXDOMAIN will motivate adoption
of the recommendations in stub resolvers, but according to Tony's
data this is largely moot.

The minimally intrusive change is to require recursive resolvers
to not *forward* "localhost.", and *then* if they have no local
data to fall back on, return NXDOMAIN.  However, if they do
have a "localhost" zone (which arguably they should, but this
need not be the draft that promotes such action) they can and
should continue to serve it.

> > If it is going to happen anyway, why forbid it?
> 
> I think the answer is that the less it happens the better, and forbidding
> it is going to make it happen less.

The evidence for that is rather scant.  Indeed most already return
NXDOMAIN (by forwarding to the roots, ... and getting NXDOMAIN from
there and caching it).  However some actually serve "localhost" and
there's nothing wrong with that.

Thus for resolvers that don't have a local "localhost" zone this
draft is a NOOP.  And for the few that do, it is asking them to
stop serving explicit locally configured data.

Bottom line, we have a either a NOOP or collateral damage, and no
real evidence that the damage has any benefit.

> If it's just your personal preference not to do this,

> then the working group isn't saying you can't make an
> informed decision to go against what the spec says.   We're just saying
> that the correct behavior is to not answer queries on localhost.

The correct behaviour is generally to not *forward* "localhost"
queries, but definitely "answer".  The question is whether that
answer is required to be NXDOMAIN or not.  And it is generally fine
answer with NXDOMAIN *unless* there's explicit local data for
"localhost".

A tricky corner case is what to do with recursive queries for
"localhost" that request DNSSEC (DO bit).  Perhaps the right answer
in that case is to forward to the root servers and cache the NSEC
records and RRSIGS for the full RRSIG lifetime (ignoring the TTL),
or just handle it like any other domain.  There won't be many
recursive queries for localhost with the DO bit set, and in any
case caching will cause only a trickle of queries upstream.

> If you decide not to follow the working group recommendation, that would
> be you deciding that you do not agree with the consensus on what the
> correct behavior is.   It's still important for the working group to say
> what the correct behavior is (IMHO).

It seems to me that my objection is not so radical, and that it is
premature to reject it out of hand.  I have operational experience
running ".localhost" zones and don't anything in the draft that
makes doing so a sin.

See below for some of my previous detailed discussion.

On Thu, Jan 25, 2018 at 08:32:25PM +0000, Viktor Dukhovni wrote:
> On Thu, Jan 25, 2018 at 04:03:08PM +0000, Tony Finch wrote:
> 
> > > I am not nearly so enthusiastic about an important component of
> > > the draft.  Specifically, I'd like to suggest that while the
> > > requirement for recursive resolvers to return NXDOMAIN for "localhost."
> > > is well-intentioned, it will prove counter-productive to the
> > > motivating goals of this draft.
> > 
> > This is a legitimate worry, but it's based on incorrect information.
> > 
> > Stub resolvers already sink localhost queries themselves - they don't rely
> > on their recursive servers.
> 
> I don't see any mention of "localhost" in libresolv sources.  What
> is true is that they generally append the default domain suffix to
> "localhost", and some support a "no_tld_query" option that AFAIK is
> off by default.
> 
> > Recursive servers frequently do not implement the localhost requirement in
> > RFC 6761 - for example, BIND does not.
> 
> That's fine, but I've configured plenty of recursive resolvers that
> are authoritative for the "localhost" zone.  I don't why the draft
> should forbid resolvers from serving such zones.
> 
> > So in practice this draft is only a small tweak to current practice.
> 
> To be clear, I support requiring a short-circuit in stub resolvers.
> 
> My objection is to requiring NXDOMAIN from recursive resolvers.
> They should not forward "localhost." lookups, but they should be
> able to serve local answers for this zone.
> 
> The motivation of the draft is to make "localhost" behave more
> predictably.  Having resolvers provide the boilerplate replies as
> a last resort is as much or more compatible with that goal than
> mandating that they return NXDOMAIN.
> 
> Note also that there may be a "localhost" zone with other data for
> sub-domains of "localhost".  I've often used for private MX records
> on an MTA:
> 
> 	example.com.localhost. IN MX 0 mx1.example.com.localhost.
> 	example.com.localhost. IN MX 0 mx2.example.com.localhost.
> 	mx1.example.com.localhost. IN A 192.0.2.1
> 	mx2.example.com.localhost. IN A 192.0.2.2
> 
>     with a transport entry:
> 
> 	example.com relay:example.com.localhost
> 
> With localhost having local sub-domains, NXDomain is NOT an option,
> though one might return NoData, it makes more sense to complete the
> zone with:
> 
> 	@ IN NS localhost.
> 	@ IN A 127.0.0.1
> 	@ IN AAAA ::1
> 
> Note, for example, that the SMTP client in the Postfix MTA performs
> DNS lookups with the RES_DEFNAMES and RES_DNSRCH options unset (in
> order to avoid unwanted search path application to MX hostnames
> obtained from DNS).  Furthermore, for similar reasons, nexthop
> resolution is by default exclusively via DNS, not getaddrinfo(3).
> Consider that administrators may configure transport entries with
> "localhost" as the nexthop domain, and you now get queries for
> "localhost" sent to the local iterative resolver.  (Most Postfix
> administrators use "smtp:[127.0.0.1]" instead).
> 
> Based on this draft, Postfix should probably special-case "localhost"
> internally, but that's not currently the case, and if some users
> choose to implement a localhost zone in their iterative resolver
> there's nothing wrong with that.

-- 
	Viktor.