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

Mike West <> Wed, 02 August 2017 13:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC1B713209A for <>; Wed, 2 Aug 2017 06:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QT_VXVaBX2ct for <>; Wed, 2 Aug 2017 06:44:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F285A131C58 for <>; Wed, 2 Aug 2017 06:44:24 -0700 (PDT)
Received: by with SMTP id x3so44714021oia.1 for <>; Wed, 02 Aug 2017 06:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id r5mr13951049oih.321.1501681464024; Wed, 02 Aug 2017 06:44:24 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 2 Aug 2017 06:44:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Mike West <>
Date: Wed, 2 Aug 2017 15:44:03 +0200
Message-ID: <>
To: Richard Barnes <>
Cc: Joe Abley <>, dnsop WG <>, Jacob Hoffman-Andrews <>
Content-Type: multipart/alternative; boundary="94eb2c0956503b32a50555c576e0"
Archived-At: <>
Subject: Re: [DNSOP] Status of "let localhost be localhost"?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Aug 2017 13:44:27 -0000

On Wed, Aug 2, 2017 at 3:38 PM, Richard Barnes <> wrote:

> On Wed, Aug 2, 2017 at 9:34 AM, Joe Abley <> wrote:
>> Hi Mike,
>> On Aug 2, 2017, at 09:54, Mike West <> 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 '
>>' and ''.")?
>> 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.

I'm pretty sure this is what the draft we're discussing attempts to do. See
#2 under
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.)