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

[Mike West <[e-mail]>]

On Wed, Aug 2, 2017 at 3:38 PM, Richard Barnes <[e-mail]> wrote:

> On Wed, Aug 2, 2017 at 9:34 AM, Joe Abley <[e-mail]> wrote:
>
>> Hi Mike,
>>
>> On Aug 2, 2017, at 09:54, Mike West <[e-mail]> wrote:
>>
>> What would you like to see in the document in order to address this
>> concern? A requirement that a `localhost` zone be created and delegated as
>> an insecure delegation, using some of the language from the draft above
>> (e.g. "This delegation MUST NOT be signed, MUST NOT include a DS record,
>> and MUST point to one or more black hole servers, for example '
>> blackhole-1.iana.org.' and 'blackhole-2.iana.org.'.")?
>> Any such delegation would be lame, and is a bad idea just for that
>> reason. There's no foolproof way to add or drop zones hosted on the whole
>> AS112 server ssystem due to the lack of coordination between AS112 node
>> operators -- despite the good communication between many such operators,
>> there's no good way to tell what nodes you don't know about.
>>
>> If you really wanted to sink queries in the top-level domain LOCALHOST a
>> better approach would to use DNAME (see RFC 7535). But note that I'm not
>> expressing an opinion on whether that's a good idea, either philosophically
>> or practically, in this specific example.
>>
>
> It seems like the desired behavior for the DNS infrastructure here is the
> same as for .onion -- return NXDOMAIN.  After all, these are queries that
> should never leave the end host, so anything not on the host should handle
> them as an error.
>
> cf. https://tools.ietf.org/html/rfc7686#section-2
>

I'm pretty sure this is what the draft we're discussing attempts to do. See
#2 under
https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03#section-3.
It could be more explicit about the response, however... I can address that
in a -04 if folks agree with the approach.

(I also wonder whether it would be a better idea to reframe this draft as
something akin to the "onion" RFC: that is, defining the behavior as a
stand-alone document rather than monkey-patching RFC 6761.)

-mike