ietf
[Top] [All Lists]

Re: I-D Action: draft-west-let-localhost-be-localhost-00.txt

2016-09-27 16:12:40
As this proposal is in the name of consistency, is there an argument we
should be strict and explicitly define *which* loopback address DNS servers
must return when queried?

I was intentionally vague on that point, as one of the scenarios raised in
https://github.com/w3c/webappsec-secure-contexts/issues/43 was a developer
who was pointing `project1.localhost` to 127.0.0.1, and
`project2.localhost` to 127.0.0.2 in /etc/hosts (and presumably had a
server configured accordingly). It seems like that's a reasonable thing to
support. Any loopback address is fine with me.

Sorry, my question was unclear - I was referring to point 3 about authoritative nameservers rather than local setups; I agree that locally developers should be allowed to use whatever local addresses they want. Anyway, that's been cleared up by fixing the typo so that's no longer an issue :)

On Tue, Sep 27, 2016 at 06:48:45PM -0000, John Levine wrote:
I use multiple IPv4 127/8 addresses all the time.  For example, I run
a funky local stunt DNS server on 127.0.1.1 and configure my local DNS
cache to use it for a branch of the name tree.  So yes, any loopback
address will do.  (We can save the question about a link-local IPv6
address on a loopback interface for later.)

Clearly this is a sensible and perfectly legal setup, however I worry that this proposal may interfere with it. If name resolution APIs are forbidden from forwarding localhost queries onto their DNS servers, how would they know that, in this case, the stunt DNS server *should* receive requests so it can route things to your preferred link local addresses?

I'm probably not explaining myself well so I'll give an example. In the setup above, let's say you've set 127.0.1.1 to be your local DNS server, meaning that you might expect the following commands to work: $ dig mysite.localhost
   mysite.localhost IN A 127.0.0.1

   $ dig myothersite.localhost
   myothersite.localhost IN A 127.200.200.200

But, under this proposal wouldn't dig be obliged to refuse to forward the request onto 127.0.1.1? How does dig (or your browser or any other resolving API) know the difference between a bog standard caching DNS server and a local DNS server that has explicitly been set up to route local lookups?

It's possible that I'm overcomplicating matters, and dig would never actually refuse to forward on such a request, but my fear is that the writers of browsers may use such a proposal to simply hard code "localhost" to resolve to 127.0.0.1 and then clever local setups like these would end up breaking.

We could possibly add some kind of exemption in the case of local DNS servers, eg: Name Resolution APIs and Libraries SHOULD send queries for localhost names to their configured caching DNS server(s) if and only if such server is itself running on a link local address.

Emily

--
Emily Shepherd
Computer Science Graduate, MEng (Hons)
W: https://emilyshepherd.me/
M: +44(0)7575 721 231

Attachment: signature.asc
Description: PGP signature