Re: [DNSOP] Status of "let localhost be localhost"?

Robert Edmonds <> Wed, 02 August 2017 18:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBBB4129417 for <>; Wed, 2 Aug 2017 11:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m6X2nI-IFKEL for <>; Wed, 2 Aug 2017 11:02:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C494126E3A for <>; Wed, 2 Aug 2017 11:02:22 -0700 (PDT)
Received: by (Postfix, from userid 1000) id D7BB712C0F92; Wed, 2 Aug 2017 14:02:21 -0400 (EDT)
Date: Wed, 2 Aug 2017 14:02:21 -0400
From: Robert Edmonds <>
To: Ted Lemon <>
Cc: Mike West <>, Richard Barnes <>, dnsop <>, Jacob Hoffman-Andrews <>, william manning <>
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] Status of "let localhost be localhost"?
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: Wed, 02 Aug 2017 18:02:24 -0000

Ted Lemon wrote:
> But we are arguing that "localhost" should be treated specially by every piece of software that looks at it, when its default meaning is "look up localhost in the DNS and connect to one of the addresses that you get in response."

RFC 6761 §6.3 already says that "localhost" should be treated specially
by pretty much every piece of software that looks at it. But especially:

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

   3.  Name resolution APIs and libraries SHOULD recognize localhost
       names as special and SHOULD always return the IP loopback address
       for address queries and negative responses for all other query
       types.  Name resolution APIs SHOULD NOT send queries for
       localhost names to their configured caching DNS server(s).

(In practice, "localhost" already does get treated specially, especially
by operating systems that place a "Name Service Switch" or similar
component in front of the DNS stub resolver. If you put
"http://localhost/" into your browser bar, you shouldn't see a DNS query
for "localhost" leave your machine.)

Doesn't "Application software MAY recognize localhost names as special"
already give more than enough permission for browser developers to treat
"localhost" (and any subdomain of "localhost") specially, for instance
by hardcoding the names to a loopback address, or filtering the result
from the system's name resolver to verify that only a loopback address
is used? Or only allowing the "Secure Context" flag to be set when the
localhost name resolves to a loopback address.

draft-west-let-localhost-be-localhost-03 upgrades the requirements in
RFC 6761 §6.3 to make them much stricter, for all applications,
converting SHOULDs to MUSTs, etc. So we're not arguing about whether
localhost "should" be treated specially, but whether it MUST be treated
specially, by all applications. Can the W3C not impose stricter
requirements on browser developers even if 6761 doesn't impose mandatory
treatment for "localhost"?

Maybe a smaller addition to RFC 6761 §6.3 would be sufficient for the
W3C? Something like:

    Application software specifications MAY require that application
    software recognize localhost names as special.

But that seems weird because it's arguably just a specific case of
requirement #2.

Robert Edmonds