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

From: Emily Shepherd <[email-masked]>
Date: Tue, 27 Sep 2016 00:39:38 +0100

Seems sensible to me.

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?

Also, as a nit-picky caveat: might there be a special case worth 
considering when a system is running a caching DNS server locally? In 
that case, it could theoretically be acceptable for a name resolution 
API / library to forward on the request.

> 2.  Item #4 is changed to read as follows:
>
>     Caching DNS servers MUST recognize localhost names as special,
>     and MUST NOT attempt to look up NS records for them, or otherwise
>     query authoritative DNS servers in an attempt to resolve
>     localhost names.  Instead, caching DNS servers 

Are we missing a 'MUST,' on the end of that last line?

Emily

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

---

From: Mike West <[email-masked]>
Date: Tue, 27 Sep 2016 10:16:08 +0200

Thanks for your feedback, Emily!

On Tue, Sep 27, 2016 at 1:39 AM, Emily Shepherd <[email-masked]>
wrote:

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

> considering when a system is running a caching DNS server locally? In that
> case, it could theoretically be acceptable for a name resolution API /
> library to forward on the request.
>

Yes. We are. Remind me to read drafts before uploading them. :)

I meant this to say something like "MUST generate an immediate negative
response."

-mike

---

From: Mike West <[email-masked]>
Date: Tue, 27 Sep 2016 19:39:16 +0200

On Tue, Sep 27, 2016 at 10:16 AM, Mike West <[email-masked]> wrote:

> https://github.com/w3c/webappsec-secure-contexts/issues/43 was a
> developer who was pointing `project1.localhost` to 127.0.0.1, and

Fixed in
https://www.ietf.org/rfcdiff?url2=draft-west-let-localhost-be-localhost-01.
Thank you!

-mike

---

From: "John Levine" <[email-masked]>
Date: 27 Sep 2016 18:48:45 -0000

>support. Any loopback address is fine with me.

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

R's,
John

---

From: Emily Shepherd <[email-masked]>
Date: Tue, 27 Sep 2016 22:12:08 +0100

>>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 :)

>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

---

From: "John R Levine" <[email-masked]>
Date: 27 Sep 2016 17:19:49 -0400

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

I don't see why.  You're allowed to use common sense when interpreting 
RFCs, and the message here is clearly that if you want to interoperate you 
do not send queries for *.localhost out of your computer. The twisty way 
my or your internal DNS setup works is out of scope.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Emily Shepherd <[email-masked]>
Date: Tue, 27 Sep 2016 22:28:11 +0100

On Tue, Sep 27, 2016 at 05:19:49PM -0400, John R Levine wrote:
>RFCs, and the message here is clearly that if you want to interoperate 
>you do not send queries for *.localhost out of your computer. The 
>twisty way my or your internal DNS setup works is out of scope.

Fair enough; it was more the concern that it might end up having 
problematic unintended side effects but I probably am just overthinking 
things :)

Emily

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Sep 2016 08:14:04 +1000

> Please consider the environment before reading this e-mail. https://jl.ly

Well we really should ensure that there is a break in the DNSSEC
chain of trust between the root zone and the localhost zone.

i.e. a insecure delegation for localhost gets added to the root
zone pointing back to the root servers or another set of servers.

At least this is only changing how localhost is handled in the
special names registry rather than attempting to add it.

http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

I would just be asking for IANA to be creating the delegation
described above and for DNS recursive server vendors to be adding
a default localhost zone with SOA, NS, A and AAAA records at the
zone apex if none is otherwise configured in a manner similar to
RFC 6303.

The following will be consistent with RFC 6303.

localhost. 0 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
localhost. 0 IN NS localhost.
localhost. 0 IN A 127.0.0.1
localhost. 0 IN AAAA ::1

One could also just do a "empty" zone.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Patrick McManus <[email-masked]>
Date: Fri, 30 Sep 2016 10:06:33 -0400

Hey Mike,

A few thoughts, sadly mostly about process rather than merits. sorry about
that.

1] You've got HttpBis at the top of that document - but I don't think this
is something httpbis would adopt (the word http does not appear anywhere
else in the doc other than url references) as its scope is really about DNS
libraries servers and registrars, not about the http protocol.

2] Given that this is about DNS libraries servers and registrars, don't you
think this should be part of the DNSOP wg discussion?

3] This seems to boil down to NEWRFC changes a bunch of RFC6761 SHOULD's to
MUST's. Obviously publishing NEWRFC doesn't make anyone non-compliant with
6761, so how does this help in making you confident enough in
localhost==127.0.0.1 to use that in secure contexts? i.e. what's the
indication the name is resolved according to NEWRFC rules?

4] you say '"localhost names will always resolve to the respective IP
loopback address". That suggestion, unfortunately, doesn't match reality.'
but you don't provide any background. That reality will be intentionally
prohibited by this document so I would like to understand the instances
where this happens a little better, what they are accomplishing, etc...
you've obviously got some examples. Thanks.

hth