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

Andrew Sullivan <> Thu, 01 February 2018 21:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60ABB126BF3 for <>; Thu, 1 Feb 2018 13:41:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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: (amavisd-new); dkim=pass (1024-bit key) header.b=TUYZn4B3; dkim=pass (1024-bit key) header.b=kID7nX1n
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RuaA61Z2wsRF for <>; Thu, 1 Feb 2018 13:41:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9650C124B18 for <>; Thu, 1 Feb 2018 13:41:05 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0906FBE072 for <>; Thu, 1 Feb 2018 21:41:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1517521265; bh=nIxJfi81fCc5A+S71HhYWBBspQc3N02L+/KZkNbW4IU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=TUYZn4B3B4D75ay/Cgj6Iwqp5rf/je6IlY+PZpILouPnscKjpkEx5pXZdGUY9WHm3 tnrugW1RNYG/FIK2020v8ndGABlVNA2paGTLBYsBPAuWTiKCC96UWg5o5A1n819tgT i5DWQRWileWqDJr+/ONJ+9oa9qA6izNR+o8w1eeU=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XcW627-xfkOM for <>; Thu, 1 Feb 2018 21:41:03 +0000 (UTC)
Date: Thu, 01 Feb 2018 16:41:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1517521263; bh=nIxJfi81fCc5A+S71HhYWBBspQc3N02L+/KZkNbW4IU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=kID7nX1nRek8dM+3OftiYcrbHgoZgETiGJaSJhtYGPQvsN8Id9K+jw6iMae2a0AOI 39WtkTyu/Q6ibzjKQpqGFmixK+QkV+bBEqZj+XAgbsNVjTehk413c7ZYnvi3S25v7X 2C3gi/UebICUhfyy85kptc6uqCS02sgwvYaGSFlQ=
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Feb 2018 21:41:07 -0000


On Thu, Feb 01, 2018 at 03:26:40PM -0600, Ted Lemon wrote:
> As for why I responded to this and not to the formal review, the answer is that the formal review was a bit overwhelming.  You made a lot of assertions of fact that didn't sound like fact to me—they sounded like strongly-held opinion.

Hmm.  I should do better.  I apologise.

> The problem I have is that to me it's dead obvious that the name hierarchy and the set of names in the DNS are not the same thing.

Me too.  Hence the distinction with local and invalid compared to localhost.

> But you explain your reasoning on the basis that clearly they are the same set, and that they are the same set is left unexamined.

No, I'm arguing that the _existing behaviour_ according to RFCs and
long-standing practice (including that of the BSD resolver) is that
the distinction between the global DNS zones and the handling of
localhost is not observed in the way that it most certainly (by
documentation) should be for local.  I don't think it's ok to try to
legislate by RFC, and I think that this is an example of attempting to
do so: to make a name that already appears today in the DNS
(localhost) go away.  Every root server on the planet, _for its own
purposes_, ought to be authoritative for localhost.  There is no
reason therefore that it should present a lie (NXDOMAIN) when asked by
someone else.  That's different from local, where in fact in the DNS
there _is_ no zone beneath local.

I hope that at least explains what I'm worried about.  I do think that
keeping the distinction between "domains in the DNS" and "domains" is
useful.  I think we may disagree about the boundary.


Andrew Sullivan