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

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 29 January 2018 15:53 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 91479131974 for <dnsop@ietfa.amsl.com>; Mon, 29 Jan 2018 07:53:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=fGsOWVFb; dkim=pass (1024-bit key) header.d=yitter.info header.b=i0+DsCp3
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 E3a9UolhQhzf for <dnsop@ietfa.amsl.com>; Mon, 29 Jan 2018 07:53:28 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B35F12EC76 for <dnsop@ietf.org>; Mon, 29 Jan 2018 07:51:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id B36C2BE072 for <dnsop@ietf.org>; Mon, 29 Jan 2018 15:51:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1517241078; bh=X+C52tR/le/8tyPmzuMGxl21/YHMvjGcshqG30tYJiQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fGsOWVFbh2BbYD2MWHDNO6NljaIFgkYeF0Xnmm4PYy7/+GDo6uYbQRz/DfJ80PRbA 9RvB4Z4eDYhahPaWRA+l3hCNI+28gg8HTWytZbE6p7Vr/P8b7qLDcKtoMipR45T0xR OA9cEgP8cqtKR+QDI8FZh6smOy49bVY0KO2V+Ouc=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxAaQQa5aYxg for <dnsop@ietf.org>; Mon, 29 Jan 2018 15:51:13 +0000 (UTC)
Date: Mon, 29 Jan 2018 10:51:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1517241073; bh=X+C52tR/le/8tyPmzuMGxl21/YHMvjGcshqG30tYJiQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=i0+DsCp3QFH0AxUPQspj6mhKqF2+LwCOJ7mnJJ89UHhoy+d0aBBLfXSNFjjzWId+P hZzmh3NV4uBYGQSjL2RyL4XGxuuQy0nV2YoOCwSXgdiXCviVqDorMWcZfBJ7Sq8nGa je9VPZR7/GsktoRyc2ygaQVjiDV9L0ANAWjp9sn0=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20180129155112.GC16545@mx4.yitter.info>
References: <9DCE2F63-EE37-4865-B9D6-6B79BBE05593@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9DCE2F63-EE37-4865-B9D6-6B79BBE05593@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qs2X-Yo8dWaxbF9NLMRaO0nTp_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, 29 Jan 2018 15:53:33 -0000

Dear colleagues,

On Mon, Jan 22, 2018 at 11:18:08AM -0500, Suzanne Woolf wrote:
> Hi all,
> 
> This is the opening of the Working Group Last Call for "Let 'localhost' be localhost” (https://www.ietf.org/id/draft-ietf-dnsop-let-localhost-be-localhost-02.txt).
> 

I have read this document.

Let me begin by saying that I am sympathetic to what the document
wants to do and why it wants to do it.  I nevertheless think the
proposal here is incorrect, and that it has bad consequences for the
DNS and for the RFC 6761 special-use registries.

I am at least a little troubled by the assertion, early in the
document, that RFC 6761 empowers anything to send queries anywhere.
This is the text in RFC 6761:

   3.  Name resolution APIs and libraries SHOULD recognize localhost
       names as special and SHOULD always return the IP loopback address
       for address queries and negative responses for all other query
       types.  Name resolution APIs SHOULD NOT send queries for
       localhost names to their configured caching DNS server(s).

That does not sound to me like "empowering" clients to send queries to
a resolver.  It sounds to me like something being advised against, and
strongly.  In RFC 2119, "SHOULD" does not mean, "This is mostly
preferable."  It means you ought to do it unless there "exist valid
reasons in particular circumstances to ignore" that constraint.

Nevertheless, people sometimes misread the SHOULD.  Perhaps the
section of RFC 6761 dealing with localhost could use the following
clarification:

   3.  Name resolution APIs and libraries SHOULD recognize localhost
       names as special and SHOULD always return the IP loopback
       address for address queries and negative responses for all
       other query types.  Name resolution APIs SHOULD NOT send
       queries for localhost names to their configured caching DNS
       server(s).  The only exception to this stricture is in the case
       where a node is known not to have a loopback interface
       configured and the local network is known to provide some
       replacement service.  For practical purposes, libraries will
       never use such functionality, and resolution API and library
       programmers are encouraged to treat these requirements and
       mandatory behaviour.

I'd even be prepared to countenance an argument that the SHOULDs
really ought to be MUSTs in this item.

I am really very troubled by the idea that any DNS server should
return RCODE 3 to a query for "localhost".  (This is items 4 and 5 in
section 3.)  This is not even wrong: the name _does_ exist, and indeed
any server on the Internet would know that (since it would itself
serve the answer _to_ itself of what localhost means; whether it
should serve it to anyone else might be a different question, but it
certainly should not respond with RCODE 3).

The draft's IANA considerations are wrong, I think, because it does
not make clear that this reservation is of the label "localhost"
anywhere in the DNS at all.  That is the consequence of item 2 under
section 3: since the bare label localhost, which is a relative name,
is treated as root-relative under all circumstances.  I am pretty sure
this is an update to STD13: I can't think of any case where relative
qualification is treated so strangely (if example.com does not get
resolution as example.com., then the fallback to the search list
happens, but not before).  This seems to be in tension with section
5.2.  I understand the goal, but I don't think it is possible to
achieve it in the DNS.

The advocacy in section 5.1, that applications should do the work
themselves, seems to me to be leading in the opposite direction to an
ostensible goal of the document.  In section 1 we see a note that
applications have hard-coded loopback addresses.  But the complexities
of resolution are such that any application in the future that is
supposed to do its own resolution might just wire up a shortcut to a
loopback addresses, thereby enshrining the very "hard coding" into
protocol-specified behaviour for applications.

I am sorry that cannot support advancing the draft in its current
state.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com