Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Petr Špaček <[e-mail]>]

On 25.1.2018 20:23, 神明達哉 wrote:
> At Mon, 22 Jan 2018 11:18:08 -0500,
> Suzanne Woolf <[e-mail]> wrote:
> 
>> Please focus feedback on: Is this draft ready to go to the IESG for
>> approval as an RFC? If not, can you suggest specific changes it
>> needs?
> 
> I myself don't have a particular opinion on whether to send it to the
> IESG, but I don't think it's ready for it based on my understanding of
> the WG discussion so far.  In particular, I don't think I saw a wg
> consensus about one major objection to the idea: "I'd like to keep my
> right of configuring my DNS servers (authoritative or recursive) to
> return whatever I want to 'localhost' queries".  Again, I personally
> don't claim this right, but I see the concern.  If my observation is

Software is still free to provide knobs to deviate its behavior from
RFC, which is nothing unusual when it comes to DNS(SEC).

Is there a real problem to solve? My understanding is that this document
is stating what software should do by default.

DNS software has so many knobs which are either not described in any RFC
that I do not see why this document needs special treatment.

Petr Špaček  @  CZ.NIC


> correct and the WG has actually not reached a clear consensus on this,
> I believe it should first achieve it.  If I miss a reached consensus,
> I wouldn't oppose to it, but I believe the draft should discuss
> how/why it justifies dismissing such concerns.
> 
> Some specific comments on the 02 version follow.
> 
> - (editorial) Section 1:
>    This increases the likelihood
>    that non-conformant stub resolvers will not go undetected.
> 
>   This is a kind of double negation ('not...undetected') and it was
>   difficult to me to understand it on a first read.  I'd suggest
>   revising it to, e.g:
> 
>    This increases the likelihood
>    that non-conformant stub resolvers will go detected.
> 
> - Section 2
> 
>    The domain "localhost.", and any names falling within ".localhost.",
>    are known as "localhost names".
> 
>   I'm afraid this definition can be a bit ambiguous.  It could read as
>   if "a.localhost.example.' is a 'localhost name'.  I'd suggest:
> 
>    The domain "localhost.", and any names ending with "localhost.",
>    are known as "localhost names".
> 
> - Section 3
> 
>    1.  Users are free to use localhost names as they would any other
>        domain names.
> 
>   It's not clear to me what this sentence means.
> 
> - Section 3
> 
>    7.  DNS Registries/Registrars MUST NOT grant requests to register
>        localhost names in the normal way to any person or entity.
> 
>   It's a bit awkward to me to use an RFC2119 keyword for what
>   registries/registrars should (or should not) do.
> 
> - Section 5.1
> 
>    In this
>    case, the requirement that the application resolve localhost names on
>    its own may be safe to ignore, but only if all the requirements under
>    point 2 of Section 3 are known to be followed by the resolver that is
>    known to be present in the target environment.
> 
>   I don't understand this sentence, especially the phrase "if all the
>    requirements under point 2 of Section 3 are known to be followed by
>    the resolver".  Point 2 of Section 3 talks about application
>    behavior (and I interpret "application" is a user of resolver, not
>    resolver itself), so what does it mean by "known to be followed by
>    the resolver"?
> 
> - Section 5.2
> 
>    Hosts like "localhost.example.com" and
>    "subdomain.localhost.example.com" contain a "localhost" label, but
>    are not themselves localhost names, as they do not fall within
>    "localhost.".
> 
>   I suggest: 'as they do not end with "localhost.".' (see my comment on
>   Section 2 above).
> 
> - Section 6.1
> 
>    Some application software differentiates between the hostname
>    "localhost" and the IP address "127.0.0.1".
> 
>   You might also want to refer to ::1 here.
> 
> --
> JINMEI, Tatuya