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

Mike West <> Mon, 07 August 2017 08:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEB5713218E for <>; Mon, 7 Aug 2017 01:41:42 -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, SPF_PASS=-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 leSUZDIZo7V7 for <>; Mon, 7 Aug 2017 01:41:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1C7613218D for <>; Mon, 7 Aug 2017 01:41:40 -0700 (PDT)
Received: by with SMTP id x3so59939287oia.1 for <>; Mon, 07 Aug 2017 01:41:40 -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=2GphdkdW/ftm7iXUrKrPoj38S/FowSwPpNfY+Yqqu24=; b=RNCn0lEKWA3ARszbhqlr9NtIBVNqli/XCnECnuKG3VZVvGU94T8GcFmkxd8WXDaTLk ac7lO+7lZAIRr+LXOjSkRkhj1ZkeIwhyH0Ye+oGU56S9u0Dc5XqxQ1N+t/NIR4bfQWVT graVqY1nqO3k99ORPkiPsSIfU9s1I/KOsmatfBv2ocLq2TB55k2CSMNN1yYLPpxbEFDf Xn0610GaAX+2IkwfbP9keIITNO57cBolzQOlCnl8a4pM+IGz6KF7V+XrLGL8klTHVp0o GpSFZfaxLl8aVLbggPSxB3t7Uz5OqsjVyR1QZCYcLebm+ijSnPEz2bhukN86gcWfXZWG DyMg==
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=2GphdkdW/ftm7iXUrKrPoj38S/FowSwPpNfY+Yqqu24=; b=hD74lsdWjhl/xyZRzpiqRU0z0iodkb7dAGrt91FiK1G8ge4Q1n7geiB0OUaA6tpsfy 5Penw7Zlpnc2I4aeqahw4HwV1+9rABmU9wi2Z+RHxU6PjpCa8ckecYSxJq/TaP5KLw8P bFPbM1Nht//iEbOpAzjMKWQJz4mGHTaf4CK/s4kKglaHsSRMYISFQPlbGlG81RamFZMf 0obAMhjTSWU32vuE9Fjb0x4OhuteNRE8Wpxgl1Y5NhZN4WREh43FlwRStRpfcjB2QC+0 30WSaMaz9XoKuvDwY8wc7ZLgJdF6mxJw6Sam6ThrvWW9zMOEbkEyWqOsByeqNqABgSZa LC9A==
X-Gm-Message-State: AHYfb5gjX0ORNyS3BfWT53A0nN0cjUxyPi1P34m+7aGydfkc4p+wzVk0 eKcRc6e3esfhMLGb2eGs6ur/J2PHIeskv6w=
X-Received: by with SMTP id a25mr6146866oic.296.1502095299326; Mon, 07 Aug 2017 01:41:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 7 Aug 2017 01:41:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Mike West <>
Date: Mon, 7 Aug 2017 10:41:18 +0200
Message-ID: <>
To: dnsop WG <>
Cc: Joe Abley <>, Jacob Hoffman-Andrews <>, Richard Barnes <>
Content-Type: multipart/alternative; boundary="001a114091a8bcd0c8055625d0db"
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: Mon, 07 Aug 2017 08:41:43 -0000

On Wed, Aug 2, 2017 at 3:44 PM, Mike West <> wrote:

> On Wed, Aug 2, 2017 at 3:38 PM, Richard Barnes <> wrote:
>> 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
> e-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.)

I poked at the draft a bit over the weekend, reworking it into a
stand-alone document in
draft-west-let-localhost-be-localhost-04. I think it ends up being clearer
overall, and hopefully y'all agree.

Regarding the outstanding question of DNSSEC and insecure delegations, this
new draft takes the same approach as the ".onion" RFC, as Richard
suggested. I'm willing to run with whatever the group agrees upon on this
point, but this seems like a reasonable approach that's both simple to
explain and consistent with existing recommendations.

Feedback on that new draft would be very welcome indeed!