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

Mike West <mkwst@google.com> Wed, 02 August 2017 13:44 UTC

Return-Path: <mkwst@google.com>
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 DC1B713209A for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 QT_VXVaBX2ct for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:44:25 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F285A131C58 for <dnsop@ietf.org>; Wed, 2 Aug 2017 06:44:24 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id x3so44714021oia.1 for <dnsop@ietf.org>; Wed, 02 Aug 2017 06:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YN/vaZcjBbAzmKoF6LJsTGmHhExKe6IlDHP2rbVI1dY=; b=J7p6uuBwy04tu+Qrupsz1nN5wo5gvk/CAQxVngN90pF/OO1pYkssItNUOr8trilCUh q3/URJuvTxiQ3XKymE9hEfFohDM3HQxtuMO6ZGsh1VWkkoZCuDVmpPwg63mnrzJyoKVm MPQ7twh+HEPhdGgZ9BXjarmRlAbmigpX+dXciYj5Pn0nj2eay4aIppWiw6z/H+QkkVm7 ONMsnxjjCLOv9fKZJhH1tQw8lIkmj1nxavLky9yPG0DZMp34qCALU/3zgKJksf+RF6+N ssmNanTYAcG0y1h2uUZwODN03GtqmIsrWCXRsiCX4Qf5qcliv7EgpBEA/3MR+tkGLHPd mmUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YN/vaZcjBbAzmKoF6LJsTGmHhExKe6IlDHP2rbVI1dY=; b=umX8eaeLDRvk5GcGlUp27caVi2Rrpbb++IjbyWzPGXI59YTQ1uupjnMhx46+3vZhxQ 9DpXng4tCruQNIgpGtDjVj2X03iz9MLckltti0oDOPdi8aDq2F/2vVyuyubETUIzLA4X HDKEsITSoGS1g0VM+GxahzYqMeH49LmMmYsFAtRq5DDbSmTBQPzN7KdEhfH9p6NKpn7J FHbm8C+atv2N2xu+J4qDH0XWbxDfEIH575K9bptId6+aNAet+XFiu4hXD3JwTliYd9Hw YStUzE/shy8BG8EDMV5S7WpM/ACerA07qw4LN3KXsb/t9oSJe5SMaHZTgBJaZQp9BTX1 XRJQ==
X-Gm-Message-State: AIVw1135+PznFN5GN9wGM79srrHbTtRJaRR0p/y2x4236SQKJVOcY3KP 6iuw604bfC5h4tf9HUk6ANz9ne+gXmE3G/oc+w==
X-Received: by 10.202.243.5 with SMTP id r5mr13951049oih.321.1501681464024; Wed, 02 Aug 2017 06:44:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.47.5 with HTTP; Wed, 2 Aug 2017 06:44:03 -0700 (PDT)
In-Reply-To: <CAL02cgQoS4r33WypArMFQHuRD38XcLfV2Y2qju+ooqykYc2ATw@mail.gmail.com>
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> <CAKXHy=e48CqjPPj-kXu34ptqSipgvJDRkVjHRwwDezCKvepFtQ@mail.gmail.com> <7019539A-48B1-4FA2-801D-20A78D85B339@hopcount.ca> <CAL02cgQoS4r33WypArMFQHuRD38XcLfV2Y2qju+ooqykYc2ATw@mail.gmail.com>
From: Mike West <mkwst@google.com>
Date: Wed, 2 Aug 2017 15:44:03 +0200
Message-ID: <CAKXHy=cZ2o4OCzAYG=Jmf2qJGK_JwdeRt3uUi7-V3Jy+cJLWqA@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: Joe Abley <jabley@hopcount.ca>, dnsop WG <dnsop@ietf.org>, Jacob Hoffman-Andrews <jsha@eff.org>
Content-Type: multipart/alternative; boundary="94eb2c0956503b32a50555c576e0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ok0V8y3AhgD748nxY0THIvSP4JM>
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 13:44:27 -0000

On Wed, Aug 2, 2017 at 3:38 PM, Richard Barnes <rlb@ipv.sx> wrote:

> On Wed, Aug 2, 2017 at 9:34 AM, Joe Abley <jabley@hopcount.ca> wrote:
>
>> Hi Mike,
>>
>> On Aug 2, 2017, at 09:54, Mike West <mkwst@google.com> wrote:
>>
>> What would you like to see in the document in order to address this
>> concern? A requirement that a `localhost` zone be created and delegated as
>> an insecure delegation, using some of the language from the draft above
>> (e.g. "This delegation MUST NOT be signed, MUST NOT include a DS record,
>> and MUST point to one or more black hole servers, for example '
>> blackhole-1.iana.org.' and 'blackhole-2.iana.org.'.")?
>> Any such delegation would be lame, and is a bad idea just for that
>> reason. There's no foolproof way to add or drop zones hosted on the whole
>> AS112 server ssystem due to the lack of coordination between AS112 node
>> operators -- despite the good communication between many such operators,
>> there's no good way to tell what nodes you don't know about.
>>
>> If you really wanted to sink queries in the top-level domain LOCALHOST a
>> better approach would to use DNAME (see RFC 7535). But note that I'm not
>> expressing an opinion on whether that's a good idea, either philosophically
>> or practically, in this specific example.
>>
>
> It seems like the desired behavior for the DNS infrastructure here is the
> same as for .onion -- return NXDOMAIN.  After all, these are queries that
> should never leave the end host, so anything not on the host should handle
> them as an error.
>
> cf. https://tools.ietf.org/html/rfc7686#section-2
>

I'm pretty sure this is what the draft we're discussing attempts to do. See
#2 under
https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03#section-3.
It could be more explicit about the response, however... I can address that
in a -04 if folks agree with the approach.

(I also wonder whether it would be a better idea to reframe this draft as
something akin to the "onion" RFC: that is, defining the behavior as a
stand-alone document rather than monkey-patching RFC 6761.)

-mike