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

Paul Vixie <paul@redbarn.org> Mon, 22 January 2018 18:36 UTC

Return-Path: <paul@redbarn.org>
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 008AE126C26 for <dnsop@ietfa.amsl.com>; Mon, 22 Jan 2018 10:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 dMen5fRKrfl5 for <dnsop@ietfa.amsl.com>; Mon, 22 Jan 2018 10:36:27 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EDA124D37 for <dnsop@ietf.org>; Mon, 22 Jan 2018 10:36:27 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:25:18f3:ab89:c46d] (unknown [IPv6:2001:559:8000:c9:25:18f3:ab89:c46d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 3A27B7594C for <dnsop@ietf.org>; Mon, 22 Jan 2018 18:36:27 +0000 (UTC)
Message-ID: <5A662F29.5050303@redbarn.org>
Date: Mon, 22 Jan 2018 10:36:25 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.22 (Windows/20171208)
MIME-Version: 1.0
To: IETF DNSOP WG <dnsop@ietf.org>
References: <9DCE2F63-EE37-4865-B9D6-6B79BBE05593@gmail.com> <CA+nkc8A91gbqRqR_he4KqCgpfWXf3J-uuU6J2DZjSjfg=QAZjw@mail.gmail.com> <064DC24E-5642-4866-AD98-8C937DBCB701@fugue.com>
In-Reply-To: <064DC24E-5642-4866-AD98-8C937DBCB701@fugue.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VsluRKGDE_HieAaNUGEk9pwcU-o>
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: Mon, 22 Jan 2018 18:36:29 -0000

as a general principle, any time you have to reach outside of a 
connectivity boundary in order to learn how to reach inside of a 
connectivity boundary, it's a sign of bad design.

needing to talk to a root name server in order to reach a cctld name 
server so that you can talk to people inside your own country, is an 
example of this -- and adding root name servers in that country, or on 
the loopback interface, is a workaround for a bad design, and does not 
make the design good.

the same is true for needing to reach outside your own virtual cloud, or 
your laptop, or your house or office or campus or enterprise, to find 
the "delegation data" that will let you talk to inside servers in order 
to get the information you need to talk to other inside servers. many of 
us use "stub zones" to work around this bad design, but DNS itself is 
crippled by many things, and this is one of them.

needing to talk to an rdns server to figure out that localhost means ::1 
(or 127.0.0.1 on the legacy internet) is also a bad design.

a hard transition, where all RDNS servers stop answering for localhost 
as soon as possible, is what would be in my opinion the best way to 
escape the long-armed clutches of bad design.

however, RDNS operators might be worried about complaints from their end 
users, and may want to either work through a gentle transition, or more 
likely, leave all the "tough love" for their successors to implement, 
and simply never remove this, because it's not causing them any 
problems, whereas removing it definitely could cause them problems.

vixie