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

Ted Lemon <mellon@fugue.com> Thu, 01 February 2018 17:45 UTC

Return-Path: <mellon@fugue.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 BC58C12EB8C for <dnsop@ietfa.amsl.com>; Thu, 1 Feb 2018 09:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 xO81SZPDglXq for <dnsop@ietfa.amsl.com>; Thu, 1 Feb 2018 09:45:55 -0800 (PST)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8378112EB9E for <dnsop@ietf.org>; Thu, 1 Feb 2018 09:45:29 -0800 (PST)
Received: by mail-oi0-x22e.google.com with SMTP id c189so13297748oib.12 for <dnsop@ietf.org>; Thu, 01 Feb 2018 09:45:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nSmqSqkOtLiAYKDM4LemOu8n/GLFOmpsCMDMbIGCZto=; b=wBaWZF8hMsOZ2uCoav2ovBIlqnU8yOd/mhTF1hOtemGf8/psS1nki3ftHZ4CWoTy8D haysZ3zsOep7BWuE166O56VyiEB9231+2ShDRmYBmjK9JtJSpt29NMWyqnTUMGR3ff9q LAu4J3ALfitm6KSYfsBDM+ucvF4G7Lcjf/guJoZE3i1PNJ0AStkiCJWi+IY8n6ssF+eA khTVdvTtPZqCJwVo5srlP0S4CDFMmFMzODQryryaByERCOSEZnS0+xbXzi1DfIdyv8xV XeYxobzj4k2R0fN7CVxTnQZ2M+0d6S+W3N+JimDigv0PVVVjX/xduErSOt0yL+QdbL56 8UXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nSmqSqkOtLiAYKDM4LemOu8n/GLFOmpsCMDMbIGCZto=; b=r1Z7vAApKlT5KZpVZVdZXNR+AdBhNvEl+fVZUeOl7Uti5amUREI6NNGIOVCJV0+pDj vAiWhW8prufVmvMA6omo5aF63nt7nHCb6LP03Mjp6eGAWxdb1dL+bqHOkmiueBblY5ki pOJ4Lu4c/91wD7O2eIwQgKw/ATfbIRk2EnWSSLwCBqyS0AvvxRUARPknPWMMSMPRzjhC HCbIBayIELQU5ThjXCFB+yCF5g3mAgN5PFHXBe5MX4cGfOyopdjhEg/uiOQhDvIAdDnx WePjI7QO5jDg8JFnlTW4mcnqIQu5lso0qQ0VYyIA0TzE5pwXmJXMVrWvrKG0k3p+dvnD 38EQ==
X-Gm-Message-State: AKwxytequ+G5FMFLq1zISyolkeVzQabX9pPgdBA4I2HSFea/x3wgqkly uAsT76HLdGxlv1Ng9guNQh7kcJhx40E=
X-Google-Smtp-Source: AH8x224eTzzd5vPxT0iit5XpP5S1SxNRIDe7zGpkvrwTEhdlyjdXTSQfRmEDTjnUAb2Wh7mk8cdj8A==
X-Received: by 10.202.219.213 with SMTP id s204mr26143934oig.82.1517507128684; Thu, 01 Feb 2018 09:45:28 -0800 (PST)
Received: from cavall.lan (cpe-72-182-60-179.austin.res.rr.com. [72.182.60.179]) by smtp.gmail.com with ESMTPSA id z68sm53555oig.1.2018.02.01.09.45.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 09:45:28 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <1D7693F7-000C-451A-8F7A-45B94366240F@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_753D76A1-0A86-4BAA-B022-8AD53A6CA108"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 1 Feb 2018 11:45:26 -0600
In-Reply-To: <20180201172644.GD26453@mx4.yitter.info>
Cc: dnsop@ietf.org
To: Andrew Sullivan <ajs@anvilwalrusden.com>
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>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VxF740PeScm8xKYMyd_j19IQI8w>
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 17:45:59 -0000

On Feb 1, 2018, at 11:26 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> It has the notable advantage that it's what the RFC says to do.

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.   So a statement in the form you have used, while it may make sense when we are talking about whether or not an implementation of the RFC is correct, is meaningless when what we are talking about is whether the RFC is correct.

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."

It would be nice if there were an error code that said "you're looking in the wrong place for an answer," but there are two problems with this.   First, it's not actionable.   Looking for localhost in the DNS is a programming error.   When a program is broken, telling it that it is broken doesn't do any good.   What we want is to return a response that doesn't make things worse.   Returning REFUSED makes things worse.   Returning NXDOMAIN does not.

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.

Whether we should place special requirements on recursive resolvers is certainly something that is up for debate.   But what the right response is, if we don't place special requirements on recursive resolvers, seems extremely straightforward 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."