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

Tony Finch <dot@dotat.at> Mon, 14 August 2017 00:36 UTC

Return-Path: <dot@dotat.at>
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 C2B05134059 for <dnsop@ietfa.amsl.com>; Sun, 13 Aug 2017 17:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 s1oZB4RNNprM for <dnsop@ietfa.amsl.com>; Sun, 13 Aug 2017 17:36:54 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9029C133D46 for <dnsop@ietf.org>; Sun, 13 Aug 2017 17:36:54 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DD3C520B98; Sun, 13 Aug 2017 20:36:53 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 13 Aug 2017 20:36:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=2Ureohg2KfSkLQcYMejuKvEprdbqNzY2hYLX4gCQnkU=; b=bOKCW5Lo +BuAdOR0WSv6ThNhGfrHlkhxs5tlZed/4ebLpxWYSIAVzV+SMKFMfcpiLgnbnFHd AfB6nHs+hSboHmoKXOc00xpLCI0T1oB1WXgXpWaj42wmi7aL35mSu1UNY19jeTvb fiE5IgBWP+gGOGEMO9ZqMUS6kvwv7FCGX2OfHbjes5QxK4a/POOiJoJVt/GiP2BL MDUBkUni4zpS/u1l+P9lBYavcX156VGHKZEnWheIG3E5S6ztE2e08CF35F+OUHMd HHZBlRSDP9Ey1VInpVQ+BGUJClNhCIsPRq6GjnAJ6sLTnhSDgnE3EJFtrpaHnGc5 70voSpShY4KBpQ==
X-ME-Sender: <xms:pfCQWatyWbft_kofWjHRaRAiVoKF95s6dDrjO-85VvX3ElKGX1gZWA>
X-Sasl-enc: iPTucelgEfiFdiBQIdUiJUssK4fnDbldc1dih1tbTCCR 1502671013
Received: from [10.162.137.93] (92.40.248.31.threembb.co.uk [92.40.248.31]) by mail.messagingengine.com (Postfix) with ESMTPA id 76C0A2418A; Sun, 13 Aug 2017 20:36:53 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Tony Finch <dot@dotat.at>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <D4C0F17B-A939-41BD-855A-77A6E7986941@vpnc.org>
Date: Mon, 14 Aug 2017 03:36:49 +0300
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3617BEAA-8DCE-4BB5-9408-3AA78E986F27@dotat.at>
References: <20170812170958.14197.qmail@ary.lan> <B21C539E-75AF-43F1-B6B0-4BDC25C6D670@fugue.com> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> <C12D3CFC-74DF-49C1-8947-863D49EEEEA5@dotat.at> <D4C0F17B-A939-41BD-855A-77A6E7986941@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/e0DBdiLS0nJYJWE4-mxFGX1SoLI>
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: Mon, 14 Aug 2017 00:36:57 -0000

> On 13 Aug 2017, at 23:51, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> On 13 Aug 2017, at 10:19, Tony Finch wrote:
>> 
>> 
>> RFC 6761 requires recursive servers to return positive 127.0.0.1 and ::1 responses, not NXDOMAIN. I can't see an explanation in the draft for the change to NXDOMAIN.
> 
> And there should be. Proposed addition to the last paragraph of Section 1:
> 
> A consequence of the requirement that the resolver APIs MUST resolve "localhost." and any names falling within ".localhost." to loopback addresses is that caching DNS servers and authoritative DNS servers MUST NOT resolve those names at all, and always return NXDOMAIN.

Well, that isn't really the kind of text I wanted.

You have written a paragraph that is obvious from the internal logic of the draft, but it doesn't say why "a consequence" has changed from RFC 6761.

What we really need is an informed analysis of the consequences of different ways of sinking localhost queries on recursive servers. The de facto way is NXDOMAIN (same as what happens when there is no special case in the resolver, except without the recursion to the root servers). The RFC 6761 way is to return locally authoritative positive responses.

Either way, BIND (for instance) needs special configuration to be RFC 6761 compliant or NXDOMAIN compliant, so some kind of code change is needed to make the Right Thing the default, but which Thing's Rightness needs justification.

There are also missing security considerations. The whole draft is motivated by web security edge cases, so I would like to see a summary and citation of the same site scripting problem, and whatever other issues there might be.

Does the change from positive responses to NXDOMAIN have some connection to the web security motivation? It isn't clear to me and it ought to be.

There is also a weird compatibility awkwardness. RFC 6761 requires *.localhost to resolve to localhost, in stub and recursive resolvers. You can't implement this in traditional Unix libc resolvers. It's possible to implement this in a recursive server like BIND, but I realised this week that I had not implemented the wildcard in my config, so I bet proper RFC 6761 conformance is rare.

The upshot of the draft's current text is that full system behaviour will vary depending on libc version, recursor version, recursor config, etc.

I think it is still a good idea to tighten up the implementation requirements to MUST. That part of the draft is good, but trivial.

The interesting part is not stated in the current text: it is that application software that makes security assumptions about localhost MUST internally resolve localhost without relying on the shifting historical and operational variability of stub resolvers and recursive servers.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at