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

Petr Špaček <petr.spacek@nic.cz> Fri, 26 January 2018 11:47 UTC

Return-Path: <petr.spacek@nic.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8CB12E891 for <dnsop@ietfa.amsl.com>; Fri, 26 Jan 2018 03:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.03
X-Spam-Level:
X-Spam-Status: No, score=-7.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpJrwD0fBIK8 for <dnsop@ietfa.amsl.com>; Fri, 26 Jan 2018 03:47:31 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2CE12D957 for <dnsop@ietf.org>; Fri, 26 Jan 2018 03:47:31 -0800 (PST)
Received: from [IPv6:2001:1488:fffe:6:9894:11ff:fe44:fce9] (unknown [IPv6:2001:1488:fffe:6:9894:11ff:fe44:fce9]) by mail.nic.cz (Postfix) with ESMTPSA id 90CC964F23 for <dnsop@ietf.org>; Fri, 26 Jan 2018 12:47:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516967249; bh=KUMfmIZQSA+EzWjiXCDkbLdgETFkLoOIey/4Z3UPrRI=; h=To:From:Date; b=i7P9t0R5vV7n9Kwb7WxWEReF0ei7vfgrU1LD3jAzqXcRAICAYjwEDPXhsEypxoXgQ oy+CP87mrWJqpvDQWOInKhRAdN2CkwL43tMtMo5x0F2dFZwxk075w143dhKFT+fSjq 1TqY7XG2s0RyzlLS7fl3I0k4PveUCQJGo4r7FaGk=
To: dnsop@ietf.org
References: <9DCE2F63-EE37-4865-B9D6-6B79BBE05593@gmail.com> <CAJE_bqcSirZyfr7PKhf=ttMxf=DeMVeJPNPn=R-HS2cH3Z-nPw@mail.gmail.com>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <8e69dac2-359b-d528-45e5-05604f4dbf90@nic.cz>
Date: Fri, 26 Jan 2018 12:47:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CAJE_bqcSirZyfr7PKhf=ttMxf=DeMVeJPNPn=R-HS2cH3Z-nPw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nvps-PVvDinJwrpmTNuit4zuJcU>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2018 11:47:34 -0000

On 25.1.2018 20:23, 神明達哉 wrote:
> At Mon, 22 Jan 2018 11:18:08 -0500,
> Suzanne Woolf <suzworldwide@gmail.com> 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