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

Jacob Hoffman-Andrews <jsha@eff.org> Wed, 02 August 2017 21:06 UTC

Return-Path: <jsha@eff.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 E56E2132179 for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 14:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 4N0dnxyidUFA for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 14:06:21 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC71132177 for <dnsop@ietf.org>; Wed, 2 Aug 2017 14:06:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=R/O3JxHm+59boKJqdz9BtkxzKgN1IT+/YIo6pJpezi8=; b=laJlsHlWa/hJIl95qKHHtBujxxKszxD7mdBkztbP0yZ1ZwHrsS45N3FADuCZPR/a56rEa7UFnkSiYQIZYCPiOtpLhCByH87TPLZnAN1iAFVR+hEAQR20/9dTKUOH2tvreLQaKVRTfJ2FWnmYSGxXmoa/4+x7SKwaIqwm3FqSf8E=;
Received: ; Wed, 02 Aug 2017 14:06:19 -0700
To: Matthew Pounsett <matt@conundrum.com>
Cc: Mark Andrews <marka@isc.org>, dnsop <dnsop@ietf.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>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org>
Date: Wed, 02 Aug 2017 14:06:20 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAAiTEH9=RNDrUmSOs8Rg2Ea4+as9pg=j5jnU6Y=nc8A4Z1aPog@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Received-SPF: skipped for local relay
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8X16yRXGKKysMBUJJjUCg3Dh3fk>
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 21:06:23 -0000

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.