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

[Viktor Dukhovni <[e-mail]>]

On Fri, Jan 26, 2018 at 06:02:00PM -0600, Ted Lemon wrote:

> On Jan 26, 2018, at 5:03 PM, Viktor Dukhovni <[e-mail]> wrote:
> > Multiple participants in this discussion have pointed out that such
> > queries are rare.
> 
> Sigh.   Yes, such queries are rare.   The things that make those queries
> are the things that are vulnerable.   That such queries are rare is further
> evidence that responding to them when they come with NXDOMAIN is a safe
> choice to make.

Protecting the residual cases is already covered by the draft's
requirement on the platform's resolution library to short-circuit
"localhost".  There is no need to impose a mandate to break these
cases on the recursive resolver.

> > And, we must not forget that, absent local
> > overrides, the iterative resolvers are *already* returning NXDomain,
> > because the authoritative data from the root returns NXDomain.
> 
> That's a good point, of course.   However, I think we heard in the
> discussion prior to adoption that this is not in fact the default behavior
> for all recursive resolvers.

Once more, *absent local overrides*, all resolvers are already
returning NXDomain.  Many resolvers don't have local overrides,
some do.

> > Yes.  Keep the MUST for the platform library.  Downgrade the MUST for
> > the iterative resolver to a SHOULD (absent local data), and either
> > exempt DNSSEC or explain why "bogus" local NXDomain is better than
> > a cacheable validated NXDomain from the roots.
> 
> How about if it says "SHOULD" but explains what the exception is, and
> strongly advocates the position that only when that exception is applicable
> should this be treated as optional behavior.

Sure.  The main exception is when the resolver is serving only
loopback clients.  And I am not opposed to text that discourages
"shared" recursive resolvers from serving local data for "localhost".

What remains then beyond recommending NXDomain for non-DNSSEC queries,
is a well-reasoned recommendation for what to do with DNSSEC queries
(DO bit).  My recommendation, as mentioned a few times upthread, is
to cache and serve the root zone's validated NXDomain.

> I would say that the exception is "when answering queries for the local
> host" or something, but I don't understand the intricacies of your use
> case sufficiently to know what would satisfy it.   I thought I understood
> your use case to be the case where the stub resolver is on the same host
> as the recursive resolver, but I may have misunderstood.

"Whitelisting" loopback resolvers is largely sufficient, provided that
the language is changed from MUST to SHOULD.

On Sat, Jan 27, 2018 at 12:56:23PM -0500, Warren Kumari wrote:

> >  And, we must not forget that, absent local
> > overrides, the iterative resolvers are *already* returning NXDomain,
> > because the authoritative data from the root returns NXDomain.
> 
> ... do they?

Definitely, *absent local overrides"*.

> Google Public DNS:
> $ dig  +dnssec localhost @8.8.8.8
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62555

Google has no such overrides.  And yet, localhost queries continue,
so NXDomain responses are not proving to be an effective motivation
to short-circuit the issue upstream.

> Verisign Public DNS:
> $ dig +dnssec localhost @64.6.64.6
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8025
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; ANSWER SECTION:
> localhost. 10687 IN A 127.0.0.1
>
> Quad9:
> $ dig +dnssec localhost @9.9.9.9
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22677
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; ANSWER SECTION:
> localhost. 86170 IN A 127.0.0.1
>
> OpenDNS:
> dig +dnssec localhost @208.67.222.222
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14156
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; ANSWER SECTION:
> localhost. 604800 IN A 127.0.0.1

Verisign, Quad9 and OpenDNS do have the traditional "local overrides".

Perhaps when they become aware of this draft, they'll drop the
override zone, or perhaps they'll leave the short-circuit decision
to the platform library maintainers.  Time will tell.

In summary I see the following actions to move this forward:

    - Encourage (SHOULD) recursive resolvers to not serve local
      data for localhost, except perhaps when the resolver is a
      loopback only resolver.

    - Encourage (SHOULD) recursive resolvers that don't have local
      data for localhost to short-circuit insecure (no DO bit) localhost
      A/AAAA queries with NXDomain without forwarding these upstream
      to the roots.

    - Suggest that rather than returning "bogus" NXDomain responses,
      secure (DO bit set) queries should get secure NXDomain
      responses (thus forwarded to the root servers and cached).

-- 
	Viktor.