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

Andrew Sullivan <> Fri, 09 February 2018 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 891A3128959 for <>; Fri, 9 Feb 2018 14:55:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=ZLJo4rcG; dkim=pass (1024-bit key) header.b=aUEtPMgf
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id THFegDKU8BgU for <>; Fri, 9 Feb 2018 14:55:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 517EF129515 for <>; Fri, 9 Feb 2018 14:55:12 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 842D0BD363 for <>; Fri, 9 Feb 2018 22:55:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1518216911; bh=7BTi3CUMRhDAGHBg/1ABPwWiELkPMqo4cto2bBmnzis=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ZLJo4rcGnqKzBNd8RCOHzyZWFtGvmFzVassVympQ5CC+wAsHCiwRKCQL0URAosi8D pLyXUqDFV8Ds7+0u8RN4m+XKmY5BgyxSXLdvuvjXliPAU/xJgdkSZD2uo7GtxJk8y1 iXRhnEGn6Vrk8+avoCLHDSGbHF0jU4wCM1EoOK88=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vB3ag6e_oDXf for <>; Fri, 9 Feb 2018 22:55:10 +0000 (UTC)
Date: Fri, 9 Feb 2018 17:55:08 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1518216910; bh=7BTi3CUMRhDAGHBg/1ABPwWiELkPMqo4cto2bBmnzis=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aUEtPMgf4vxPF5WNFWgKoUG5HB5kS5YEnkX8chhXTh8Ch+pOo5w4Rk4AiTmkbX0JP qUTsMPH+J1LgdKNEu2wYzs85zRYmxLBMBe/OBNLcwcHQELdBn6+23LhBNAU5zqPMab 4id/9GsOKbVh8tN4iy5DNgyiReu4SBxWT7h56KkI=
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: Fri, 09 Feb 2018 22:55:15 -0000


On Tue, Feb 06, 2018 at 12:50:18AM -0500, Ted Lemon wrote:
> That's pretty clear.   This document is not forbidding the appearance of such names in the DNS, nor the resolution of such names.

Instead, it is wanting to have its cake and eat it too.  Because…

>    Note, however, that the admonition against searchlist usage could
>    affect their resolution in practice, as discussed in Section 3

…of the "admonition" (or whatever you want to call it).  In effect,
the document requires special-casing of "localhost" as a label in
every searchlist context.

If the goal is to say, "The search list is evil, and should not be
used," then say that.  Otherwise, what this document is _really_ doing
is altering STD13's search list processing, to include special-casing
of down-tree names.  I think that is the case despite this bit:

>        Application software MUST NOT use a searchlist to resolve a
>        localhost name.  That is, even if DHCP's domain search option
>        [RFC3397 <>] is used to
>        specify a searchlist of "" for a given network,
>        the name "localhost" will not be resolved as
>        "" but as "localhost.", and
>        "subdomain.localhost" will not be resolved as
>        "" but as
>        "subdomain.localhost.".

The reason I think that is because of the earlier part:

   2.  Application software MAY recognize localhost names as special, or
       MAY pass them to name resolution APIs as they would for other
       domain names.

If you can just pass this to a resolution API, then it's actually the
resolution API that needs to know to handle the search list rules
according to this new specification (this part of the specification
does not say that you can only use the API if you can tell the API not
to use search lists, &c).

I really do sympathise with the goal of the document, but I think it
is making a bigger change than it seems to understand.  And anyway, I
don't understand how the original 6761 text is the wrong approach:
given that it isn't even being followed on the Internet today, there's
no reason to suppose that this alternative approach is going to make
things any better.

Best regards,


Andrew Sullivan