On Tue, Sep 27, 2016 at 10:16 AM, Mike West <mkwst(_at_)google(_dot_)com> wrote:
Thanks for your feedback, Emily!
On Tue, Sep 27, 2016 at 1:39 AM, Emily Shepherd
<emily(_at_)emilyshepherd(_dot_)me>
wrote:
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.
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?
Yes. We are. Remind me to read drafts before uploading them. :)
I meant this to say something like "MUST generate an immediate negative
response."
Fixed in
https://www.ietf.org/rfcdiff?url2=draft-west-let-localhost-be-localhost-01.
Thank you!
-mike