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

Ted Lemon <mellon@fugue.com> Wed, 02 August 2017 13:10 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 9544D1320A9 for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.774
X-Spam-Level:
X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 5B3KRbhKzX5L for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:10:49 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 A5907132091 for <dnsop@ietf.org>; Wed, 2 Aug 2017 06:10:49 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id 16so26414203qtz.4 for <dnsop@ietf.org>; Wed, 02 Aug 2017 06:10:49 -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=EbSeJO0n/e6OaCDBY/gFQh3Jpo0RQvR/WxfsPljSC8E=; b=Cgg84RYoCCsWHRMiUDKNrNxw5hYhXY8uySU1GXorKLPC+3ALtuPkNyYfyYzgNJqk+V hmA+p69dANW4gXJBAvMH8AX57/sQ4tHQDLHpoQf6hxf7SbQQGmV7VN6oS6LEdXKOPRcH Gsfdmh8v3FThx9LW6Ib3mnWWM8fAffviuVcyHF0/TDS8LqnYHk7nmnxL7wvB6OF0G1dF hJxOtR22Spkt2rF2tldEbyTQworIdEol8rxV2Vu6r1BvVLNshtDJber9pTZluKwN402l SwtMMwtz3gtI39nmQJqdifl03sZ4O/RCvB0LEN9Xd9U1N4bbCqQ8GnFtBSMTdiQl6M6D oW1Q==
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=EbSeJO0n/e6OaCDBY/gFQh3Jpo0RQvR/WxfsPljSC8E=; b=OAFZAe/fUFKIsgrZeoNeiMVa5zAWBU+IP/NHlvFcVqzuGAbOsUbbpzoJLYyYY1Ma0s OITMH0R0D8KiMFBjwomFSmjdvFs6I1IwCSMe+J5ZeGZFb2EgeT95kkv07ijYz3Qn6M4q zZYJWcjt5LHgYOsrF5t8neMyHawIVkQA2qGox2+VBMnw9vgLPcDZic71Lc4eTcnLQKHE /0cT2xH/5xHxiAEB0C0QtClMzbha0egfQJYH8tedt4QdsJ6wRo+SoCyvqIr2W1by+CU8 2EDo60T3NPydrUbZNQfcYVWxfBGAnJcUCryDzRP4jFO2NL2H6eLFywNWm+QprrIKgM/J ZOHA==
X-Gm-Message-State: AIVw112OYrPcgMd3c41r0It3CmtpcYgisQYO4nK+ZegryhLnd7k82swY mvM+ut1CVlTISnjB
X-Received: by 10.200.56.48 with SMTP id q45mr30542491qtb.36.1501679448728; Wed, 02 Aug 2017 06:10:48 -0700 (PDT)
Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n14sm703068qtc.28.2017.08.02.06.10.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 06:10:48 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <7066211F-69B4-4B69-840B-A811D19980BF@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AE6D2235-E817-4DBE-ACB9-FFFD4EC3EC4F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 2 Aug 2017 09:10:45 -0400
In-Reply-To: <CAL02cgQ2z9Fze-Q2QWQ=+PHJEO_S3bTaq1fPJ6XSEwFUQ=ftvw@mail.gmail.com>
Cc: william manning <chinese.apricot@gmail.com>, dnsop <dnsop@ietf.org>, Jacob Hoffman-Andrews <jsha@eff.org>
To: Richard Barnes <rlb@ipv.sx>
References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <CAKXHy=ctB=LZkX9j=8-Jy0NkTAs2tAesa4gmFhfp94O5=9U4TA@mail.gmail.com> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <CACfw2hiX7U74n9+defcYiD7jLKZeLhtLM6WP5YM_WuAoA8ecYQ@mail.gmail.com> <CAL02cgRg6k7=b7berKr9J+9aL8PTS81nJ_yXQO8QTYqgiqXSbg@mail.gmail.com> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <CAL02cgQ2z9Fze-Q2QWQ=+PHJEO_S3bTaq1fPJ6XSEwFUQ=ftvw@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F85rBQl0sB_IU23-mKlaexbL5dU>
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:10:50 -0000

On Aug 2, 2017, at 9:02 AM, Richard Barnes <rlb@ipv.sx> wrote:
> But of course having IP addresses in URLs is both a PITA for developers and an anti-pattern more generally.

While true, I would argue that this is actually a problem.   E.g., I actually literally cannot surf to a link-local URL without having a DNS record for it, because http://[ <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/>fe80::1806:ec37:3d5f:9580%en0]/ <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/> has an interface identifier in it, and modern browsers consider this an anti-pattern, I guess.   And you don't want to put link-local addresses in DNS, even if it made sense to do so, so what is one to do?   I'm not convinced that this anti-pattern is the wrong anti-pattern, but here we have two examples of it being problematic, in the least.

> If "localhost" were properly defined to be loopback, then applications could just hard-wire resolution, and not depend on the good graces of the platform resolver.  As, for example, Firefox does with ".onion" today:

Right.   But there was actually a long discussion on why that's problematic when we were doing the .onion RFC.   The reason is that one can't count on any particular piece of application software correctly interpreting the rightmost label.   We can write RFCs encouraging it, but if I am writing a URL into a piece of HTML, I have no idea whether the thing that interprets the HTML will or will not do the right thing.

We just accept that as a risk with .onion because we don't have a better option, but for localhost we definitely do have a better option.   That's all I'm saying.