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

Richard Barnes <rlb@ipv.sx> Wed, 02 August 2017 13:18 UTC

Return-Path: <rlb@ipv.sx>
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 9DA451320C5 for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:18:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.473
X-Spam-Level:
X-Spam-Status: No, score=-1.473 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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 zrafixbnYVUZ for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 06:18:28 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c: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 9A9941320B9 for <dnsop@ietf.org>; Wed, 2 Aug 2017 06:18:27 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id k20so30152341wmg.0 for <dnsop@ietf.org>; Wed, 02 Aug 2017 06:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/086kHfQh7YjoOjcozxaMirWdFgCQH2R4aABNk1z72Y=; b=Y9J46SlwaDu9bKZD0dhS2NsgVsm/5MIaTy40CRrzeOrkBA8p2l7q0kQkBFi6zo6254 EjimU4NLpTfhGJw9DBuloFoYNHlBRkaJpxCONKj88EROcvZ2c7PJDYeBbYslLlT4G182 easBLv4/zmP12C2HfQCdTC4HUmcssX6Hg1w1A56eyC+bd3pRenhwu6sCcXgzrBk4grFF mSxmU+8oCCAHx/eZEY+CZ9Hiu03DNgWV5lNiDJ4e69eHf6x7Vv+AkFLxa1wQSTelNmxD n0UDY6N9CaU8GXgHVe6qRaV4en8vOkO8P5Zs3Hy3eIXuWEs5ogWONBMjuTaATZzh/lky jV8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/086kHfQh7YjoOjcozxaMirWdFgCQH2R4aABNk1z72Y=; b=Trd9kYoddzTyDe3wtEMPNrRTMUGGKX0oGtXdHURopdAMI9KR252g6y1aOkcWxnK3ll MMAcwfgI6VLyVvDVWuhPMgoc5y7UjR3LjPIL16P4w/A3oI7IckYbK2TExYTVHgdgWpY1 hWEg6kY1x+/JxjYw7exTBlV4wyGTO1lM2gg+0+VXYYdcmvlPrykZEuLQRmX9XHJqOOFj n9kf1+SQT6vC69XyaKvfd9shU44pzBIkeBW50Md+8Q0BDyJwtALrskkI0XNawAFLVo1K N7Mi1gXKPlJAJPasMA/7M+r3eyfm3/S4lXGejL3v+HdK+yx0AnhVObNl382bHXd/+sNP JmAg==
X-Gm-Message-State: AIVw111I8ig+Rkkp5ZcLYTlFGEFLichyy8slFnfA0fKHxVxHt5RGfLlp LO8BOUVyccPmEe8CdaHrh/Z6S9iBtyPm
X-Received: by 10.28.129.205 with SMTP id c196mr3827239wmd.120.1501679905864; Wed, 02 Aug 2017 06:18:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.225.5 with HTTP; Wed, 2 Aug 2017 06:18:25 -0700 (PDT)
In-Reply-To: <7066211F-69B4-4B69-840B-A811D19980BF@fugue.com>
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> <7066211F-69B4-4B69-840B-A811D19980BF@fugue.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 2 Aug 2017 09:18:25 -0400
Message-ID: <CAL02cgShGOix14+QqmDur1kD6xsvV2J1p+MEnbHuEvVw_aut+w@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: william manning <chinese.apricot@gmail.com>, dnsop <dnsop@ietf.org>, Jacob Hoffman-Andrews <jsha@eff.org>
Content-Type: multipart/alternative; boundary="001a1142486e5b49940555c51908"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eAMkgqXoUbODnM5hn7aKjlVB3IA>
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:18:30 -0000

On Wed, Aug 2, 2017 at 9:10 AM, Ted Lemon <mellon@fugue.com> wrote:

> 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.
>

The point you're missing here is that the application is both the thing
relying on the definition of "localhost" and the thing empowered to enforce
the RFC.  If the application doesn't care whether "localhost" resolves to
anything special, then it can pass it to the platform and take its
chances.  If it does, it can hard-wire it to loopback.


> 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.
>

Using IP addresses is not a better option.

--Richard