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

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 01 February 2018 20:48 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 7D93912EC90 for <dnsop@ietfa.amsl.com>; Thu, 1 Feb 2018 12:48:38 -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=PCIe6Wax; dkim=pass (1024-bit key) header.d=yitter.info header.b=aGIDDUmx
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 04k6MpyLncWc for <dnsop@ietfa.amsl.com>; Thu, 1 Feb 2018 12:48:36 -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 8AA7812D945 for <dnsop@ietf.org>; Thu, 1 Feb 2018 12:48:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id A8C09BE072 for <dnsop@ietf.org>; Thu, 1 Feb 2018 20:48:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1517518115; bh=Nvxit1Nbt9BjQ+MNOH2Uh2+t/87ZRCGUiGxHvOO9ufI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=PCIe6WaxV4GEsjwVGns8X+rPbfdaP2Hev+1Jy9OxHimCIXvWHp3FAPGYbc1MMFnyE N1OGWHbYh3h0Qf/mMHDx+chPQ42nBPMNG7QHn7lOUe5TG9jgLe2DpSbESSmUavGaP8 +M2kJRJ7ocInXJjosOQhas33nulChKZ96zCrXqYs=
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 6D8qBBH8FOc4 for <dnsop@ietf.org>; Thu, 1 Feb 2018 20:48:34 +0000 (UTC)
Date: Thu, 01 Feb 2018 15:48:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1517518114; bh=Nvxit1Nbt9BjQ+MNOH2Uh2+t/87ZRCGUiGxHvOO9ufI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aGIDDUmx8YAGGglSjkNJOZKU28rRl+AIa4ho7/zFr3JGJPEAHPExuziKZco1wyrmW jXWz7N4Wmn8q7vRS4oBEs19wCeRY1HtPrhcgQm+du9qBnaQPv7wBAR+AqbtZKVWGs0 TaTBrD1AzLVKjPqlEaKjdF+unwjVAcUL1mdt5+cY=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20180201204833.GA27125@mx4.yitter.info>
References: <9DCE2F63-EE37-4865-B9D6-6B79BBE05593@gmail.com> <20180129155112.GC16545@mx4.yitter.info> <5A6F5CF1.4080706@redbarn.org> <CA+nkc8D7tne5SxGOUhvJqstmDa=1=RmvcHQte1byAab5dUd5sQ@mail.gmail.com> <AE634FC4-0EAF-4F54-8860-61E41284F873@fugue.com> <20180130185919.GJ19193@mx4.yitter.info> <3b57a486-df8e-ca57-ab89-c167cea0dcc9@bellis.me.uk> <20180131161507.GP3322@mournblade.imrryr.org> <20180201172644.GD26453@mx4.yitter.info> <1D7693F7-000C-451A-8F7A-45B94366240F@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1D7693F7-000C-451A-8F7A-45B94366240F@fugue.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WT0j-75J04Sa_cHSAK44tkCrNH4>
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: Thu, 01 Feb 2018 20:48:38 -0000

On Thu, Feb 01, 2018 at 11:45:26AM -0600, Ted Lemon wrote:
> 
> As a general principle, when what the RFC says to do is not the right thing to do, the solution is to update the RFC, not to ignore the problem.

I strongly agree with this (as I think or anyway hope you know), and
if my response seemed to be an appeal to the mythical authority of the
RFC series then I apologise.  My intent was to point out, instead,
that RFC 6761 has a position about this, and it is quite clear and
also contrary to the behaviour of the root servers.  Since RFC 6761
has IETF consensus, I am not convinced that the response from the
roots is right.  Since an NXDOMAIN response causes the _very problem_
that the draft this thread is about is attempting to fix -- literally
by making the effect in question more ubiquitous -- it seems to me
that the burden of proof lies upon others.

> Your and Paul's responses to this seem to take the position that what matters is consistency.   We should not return NXDOMAIN, because localhost has meaning, and NXDOMAIN doesn't.   But this misunderstands what NXDOMAIN means.   What NXDOMAIN means is "there is no such name in the DNS."   It doesn't mean "there is no such name."
> 

But of course, there _is_ a name "localhost" in the DNS.  It's already
defined, in the RFCs, to this effect.  RFC 6761 defines
special-purpose domain names, not domain names that are outside the
DNS.  It so happens that this domain name _is_ in the DNS, precisely
because RFC 6761 recommends that it be so (unlike, for example, what
it says for .invalid or what RFC 6762 says for .local).  The point is
rather that localhost is a universal reference to the loopback
address.  Since it is a universal truth, it is true in the IN class,
and that means that any server on the Internet ought to know this.

> Returning REFUSED makes things worse.   Returning NXDOMAIN does not.

The goal in the draft is to make things break for the host making the
request, even though it should not have made that request.  Returning
REFUSED and returning NXDOMAIN both have that effect.  But returning
NXDOMAIN also breaks the semantics of DNS, which I think it worse.

> Second, there's no trust model for such a response.   The trust model for NXDOMAIN is clear, and we know how to do it.   The trust model for e.g. REFUSED is nonexistent.
> 

Nonsense.  The trust model for refused is, "You asked and were
denied."  Signable denial of service strikes me as possibly the most
abusable service on the Internet :)

> Whether we should place special requirements on recursive resolvers is certainly something that is up for debate.

RFC 6761 _already_ places such requirements, it seems to me.

> If you believe that the right response is not NXDOMAIN, your reason needs to be something more than "that's what the RFC says to do."
>

I believe I offered such reasons in rather more detail in a different
message (one to which you did not respond) where I reviewed the draft
at greater length.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com