Re: [DNSOP] Status of "let localhost be localhost"?

Mark Andrews <marka@isc.org> Wed, 02 August 2017 23:39 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225F0131C51 for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 16:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzFWAZvXrH_y for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 16:39:27 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E6F1294A2 for <dnsop@ietf.org>; Wed, 2 Aug 2017 16:39:27 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 645D234BCDC; Wed, 2 Aug 2017 23:39:25 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 49CB5160051; Wed, 2 Aug 2017 23:39:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 27266160050; Wed, 2 Aug 2017 23:39:25 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JfcQDfFr5r4c; Wed, 2 Aug 2017 23:39:25 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B64E216003A; Wed, 2 Aug 2017 23:39:24 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BEDA280D9BB0; Thu, 3 Aug 2017 09:39:21 +1000 (AEST)
To: Jacob Hoffman-Andrews <jsha@eff.org>
Cc: Matthew Pounsett <matt@conundrum.com>, dnsop <dnsop@ietf.org>
From: Mark Andrews <marka@isc.org>
References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <CAKXHy=ctB=LZkX9j=8-Jy0NkTAs2tAesa4gmFhfp94O5=9U4TA@mail.gmail.com> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <121adcc6-55c5-4f90-2797-999f3f1f1ef8@eff.org> <CAAiTEH9=RNDrUmSOs8Rg2Ea4+as9pg=j5jnU6Y=nc8A4Z1aPog@mail.gmail.com> <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org>
In-reply-to: Your message of "Wed, 02 Aug 2017 14:06:20 -0700." <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org>
Date: Thu, 03 Aug 2017 09:39:21 +1000
Message-Id: <20170802233921.BEDA280D9BB0@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DT7tGLC-Bfhm_hN3d5wh_1GdKXE>
Subject: Re: [DNSOP] Status of "let localhost be localhost"?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2017 23:39:29 -0000

In message <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org>rg>, Jacob Hoffman-Andrew
s writes:
> On 08/02/2017 12:09 PM, Matthew Pounsett wrote:
> > In the case where 'localhost' is being passed to DNS resolution
> > software, a validating stub (for example inside a web browser)
> Ah, this may be where we are finding a disconnect. I believe web
> browsers never operate validating stub resolvers, but generally ask the
> operating system resolver library. Do you have a counter-example?
> 
> I think it's also rare for operating system resolver libraries to
> validate DNSSEC (rather than leaving it to an upstream recursive
> resolver). However, even if we take it as a given that operating system
> stub resolvers should implement DNSSEC validation, they clearly already
> treat localhost specially, so there is no reason to believe that they
> would start trying to validate it with DNSSEC once this document is
> finalized.

The deployment goal of DNSSEC was to have *every* machine/application
validating DNSSEC responses or to have a crytographically secure
path to one that did for which you knew and accepted its security
policy.  DNSSEC was designed with this in mind.  DNSSEC also requires
recursive servers to validate responses or else you can't handle
certain threats DNSSEC is designed to handle.  Turning on DNSSEC
in resolvers also provides some protection from some threats to
non-validating clients.  Getting validation turned on in recursive
servers is the first step in this multi-year plan.  We are at about
the 60% level for recursive servers and a few percent (maybe) for
the machine/application level.

Most OS's don't treat localhost specially.  It is just a entry in
/etc/hosts and/or a zone in the local recursive server and/or
localhost.<zone> in a zone on the search list.  The last of these
is how localhost is actually resolved on my machine (MacOS 10.12.6)
as the resolver doesn't treat "localhost" as special.  It's processed
the same way as any other single label name.

When you look at foo.localhost the resolution mechanisms /etc/hosts
and/or a zone in the local recursive server.  If you are mad you
apply the search list.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org