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

[Mike West <[e-mail]>]

It seems like there's clear agreement that `localhost` "should" map to
loopback addresses. That's what the RFC already says, after all, and it
matches my anecdata from conversations with developers (I haven't talked to
anyone (outside this group) who expected `localhost` to ever resolve
anywhere else). So, that's a good place to start.

Some folks in this thread (including me) think that "should" is too weak,
and that it would be helpful to make a stronger guarantee that `localhost`
matches its colloquial meaning. I think there are some pretty reasonable
arguments for this position:

1.  RFC6761 says <https://tools.ietf.org/html/rfc6761#section-6.3> that
users "may assume that IPv4 and IPv6 address queries for localhost names
will always resolve to the respective IP loopback address". It violates the
principle of least astonishment to allow the underlying platform to behave
at odds with that assumption. I'd suggest that we should either harden the
requirements below, or stop inviting users to make incorrect assumptions.
Given the widespread acceptance of those assumptions, the former seems like
the right course of action to me. :)

2.  Various bits of software behave in various (and inconsistent) ways when
presented with a DNS query for `localhost`. "Should" has not been as
effective as I'd like in creating an environment in which user expectations
are met. Chrome is the client I'm most familiar with, and it takes
advantage of the "should"'s and "may"'s in some circumstances to hard-code
resolution of `localhost`. That behavior isn't consistent across platforms,
however, and, as Richard notes, it would be helpful in our decision-making
if we clarified the guarantees the platform ought to provide.

3.  Groups like SUNSET4 are actively opposed to hard-coding IP addresses
like `127.0.0.1`, but if that's the only way that developers can really
ensure users' expectations are met, that's what they'll end up doing. As
Richard has noted a few times in this thread: that would be a worse outcome
than making stronger guarantees about the meaning of an mapped label.

If y'all decide that this is really just something that browsers need to
care about, then it's of course possible to address Chrome's use case by
overriding RFC 6761 in a W3C spec. If that's the course of action y'all
would prefer, I can do that. It seems like taking browsers' handling of
`localhost` out of the hands of DNSOP/IETF would be a bad outcome for this
group, but it's certainly an option.

With regard to DNSSEC delegations, my intuition is that Jacob's assessment
is reasonable, but I recognize that I don't know nearly enough about DNSSEC
to have a meaningful opinion. I'm happy to accept the group's assessment on
this point.

Thanks for continuing the conversation!

-mike

On Thu, Aug 3, 2017 at 1:27 AM, Richard Barnes <[e-mail]> wrote:

>
>
> On Wed, Aug 2, 2017 at 4:27 PM, Ted Lemon <[e-mail]> wrote:
>
>> On Aug 2, 2017, at 2:02 PM, Robert Edmonds <[e-mail]> wrote:
>>
>> draft-west-let-localhost-be-localhost-03 upgrades the requirements in
>> RFC 6761 §6.3 to make them much stricter, for all applications,
>> converting SHOULDs to MUSTs, etc. So we're not arguing about whether
>> localhost "should" be treated specially, but whether it MUST be treated
>> specially, by all applications. Can the W3C not impose stricter
>> requirements on browser developers even if 6761 doesn't impose mandatory
>> treatment for "localhost"?
>>
>>
>> It should be MUST in both cases.   But writing that in an RFC doesn't
>> make it so.   Bear in mind when you look at the W3C document that it is
>> talking about what would be ideal, not what is actually present in browsers.
>>
>> As an app developer worried about security footprint, I would be wiser to
>> be cautious and use ::1 or 127.0.0.1, rather than using localhost and
>> relying on the name resolution infrastructure.   But the use case that I
>> would be most skeptical about is using localhost in a URL.   I think that
>> should be MUST NOT.   Apparently there is not wholehearted agreement on
>> this topic, however... :)
>>
>
> You have this backwards.  Browser today do take the more cautious,
> IP-based approach.  It sucks for developers.  They want to be able to use
> "localhost", but in order to do it safely, they will need to hard-wire it
> internally (since as you say, writing an RFC doesn't make resolvers
> change).  And they don't want to hard-wire unless that's the clear semantic
> because standards are what make the web work.
>
> --Richard
>
>