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

Ted Lemon <mellon@fugue.com> Sat, 12 August 2017 19:35 UTC

Return-Path: <mellon@fugue.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 C5E1A131D1E for <dnsop@ietfa.amsl.com>; Sat, 12 Aug 2017 12:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fugue-com.20150623.gappssmtp.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 gm9uVYza14Fc for <dnsop@ietfa.amsl.com>; Sat, 12 Aug 2017 12:35:21 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 C3DD412EAF7 for <dnsop@ietf.org>; Sat, 12 Aug 2017 12:35:20 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id x191so34904362qka.5 for <dnsop@ietf.org>; Sat, 12 Aug 2017 12:35:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=H+fG91OML64LQl1yYLj7gh/lRX8aAS21HTIbCN2x09o=; b=cHf97cH2IB/Xi/cSq6RDNGogF0bnK29CTha1p2NeIbi25UxW5I2uEeP/nznYerRW87 5cHRkYZftvIiBuEQQWIjQ67CzV3QOrdH1y18ENAxXQkGByegXRFwk3ognruK13qhSlk5 SIx+gApIF+KYJ0EvUZ0R2golULRG21W5tmzrnhgI/YlsEpE59DmOAtDyPZOQsll41n7Y HyxJnu9BpYB0ODmYThVqchJg7vNBgzAApB3ALEppQm4x95jNTrJ9Q5on+Yqu/6XPud2H NSJ4AGw3TAbIfkF+/LaMIk/KJtj286Adwlz+GoQoyjSHSHmoIgVKNu2UVxIoyLlThke8 glkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=H+fG91OML64LQl1yYLj7gh/lRX8aAS21HTIbCN2x09o=; b=h9we+EUKdj4/SUR5s+U4nODmwE5pcbOZ4J5F0C+xrQxjk6jENjYJdbYISRf1a5wxEB DGg1yFWc0c6Bx56DC4PzZ6kw+hx0izcDk7EXNvY+lDUrP6+1ZSqWfVjfV2ntFDjUJ2qH 9ccmMywiBApiHxZjC1fIblJXujuV/VQjfeWL1RRhQdiMGftPnT/tmi6yogAPh2LB9y85 NQzVzlfhPHXXJNfbb496fa3eygWACdUvAw10usEP9SD7hWa2P5uOtTu6ph6DPPNuPlbt 4hcJnZ9JeUvw2SK0hfUpTSqfVgCtA5j2IwStdQzkRrBAymcGOtl9jTJiP9nPv2SP+b5E cAiw==
X-Gm-Message-State: AHYfb5jfgVFCJ9e70fRnRZM4w1vE/OQDwMc9q1a6TXE6Im6DdrOnsS/i bd4XXU5PS0qlogltCgS99w==
X-Received: by 10.55.81.139 with SMTP id f133mr24216733qkb.194.1502566519862; Sat, 12 Aug 2017 12:35:19 -0700 (PDT)
Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id j81sm2485487qke.19.2017.08.12.12.35.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2017 12:35:19 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5CDCA84F-6805-40E7-9431-60DA0E121813"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sat, 12 Aug 2017 15:35:17 -0400
In-Reply-To: <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org>
Cc: dnsop <dnsop@ietf.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <20170812170958.14197.qmail@ary.lan> <B21C539E-75AF-43F1-B6B0-4BDC25C6D670@fugue.com> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/z_dPK7vDw_L_5a6QDn9iqAzbVk8>
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: Sat, 12 Aug 2017 19:35:23 -0000

El 12 ag 2017, a les 14:36, Paul Hoffman <paul.hoffman@vpnc.org> va escriure:
> It's security through interop. It's causing systems that want to hope that "localhost" has a particular meaning that has security implications to have a better chance that their hope is fulfilled.

Yes, I get that, and I'm not sure that it's wrong, but you still haven't addressed the point that I raised.   That's fine—I don't know that you really need to.   But for some reason people keep replying to my point with statements that don't contradict it, as if they think they have contradicted it, which puzzles me.

To recap, my point is that fixing localhost and then relying on it doesn't fail safe, and there is reason not to be confident that implementations will conform, because they will appear to work even if they don't.   If we think that localhost is the right identifier to use to refer to the local host, then we ought to be taking steps to make it not be the case that broken implementations will appear to work: we should be systematically trying to ensure that as many environments in which such applications might run as possible produce failure when a broken resolver forwards a query for localhost to the local recursive resolver.

The document does the right thing on that front, as far as that goes, but if this is to be effective I think that it shouldn't be an aside, but should be the main point of the document.   That is, the title of the document should be "DNS servers should return NXDOMAIN for localhost" and the abstract should say why, and then the bit about stub resolvers translating "localhost" to a reachable identifier for the localhost such as 127.1 or ::1 should be the thing that's mentioned as an aside.

And then we should be socializing this to operators and filing bugs against it in the bug tracking systems of our favorite distros.

And after doing that, it will still be the case that references to "localhost" don't fail safe, but it will be more likely that they won't happen, so maybe my point will have been adequately addressed.   But I still think that it would be better to recommend some identifier that can't be looked up in the DNS.