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

Tony Finch <> Thu, 25 January 2018 15:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4931212E896 for <>; Thu, 25 Jan 2018 07:56:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UrPo4iZQh-OW for <>; Thu, 25 Jan 2018 07:56:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F0B912E88D for <>; Thu, 25 Jan 2018 07:56:50 -0800 (PST)
X-Cam-AntiVirus: no malware found
Received: from ([]:54336) by ( []:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eejtP-00102n-dk (Exim 4.90) (return-path <>); Thu, 25 Jan 2018 15:56:47 +0000
Date: Thu, 25 Jan 2018 15:56:47 +0000
From: Tony Finch <>
To: Bob Harold <>
cc: Suzanne Woolf <>, IETF DNSOP WG <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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, 25 Jan 2018 15:56:52 -0000

Bob Harold <> wrote:

> My concerns:
> Do we need to make sure stub resolvers get updated before we update DNS, to
> avoid breaking things?
> Do we know what current stub resolvers do?

Based on a few stats I gathered in September, stub resolvers already
handle localhost themselves. More details at

Regarding the draft, I have looked through it and I have one suggestion:

The second paragraph of section 5.2 (security considerations - localhost
labels in subdomains) should be beefed up. Localhost entries in subdomains
are risky so they should be discouraged - I wrote about why we deleted
ours at

I think it's misleading to say "could affect their resolution in
practice". It would be more accurate to say "in theory" because in
practice, localhost queries are already absorbed by /etc/hosts (or
equivalent) before the search list gets a look in.

So I suggest the following replacement for the second paragrph of section 5.2:

   In theory, the admonition against searchlist usage could affect their
   resolution, as discussed in Section 3; in practice, stub resolvers
   already handle queries for "localhost" as specified in this memo.

   Although localhost entries were encouraged by RFC 1537, that suggestion
   was removed from its successor RFC 1912. They are now discouraged
   because they can be used to subvert security restrictions such as the
   web browser same origin policy, especially on multi-user systems

f.anthony.n.finch  <>  -  I xn--zr8h punycode
Irish Sea: Southwest veering northwest 5 to 7. Moderate or rough. Showers.