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

Warren Kumari <> Wed, 16 August 2017 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26900132743 for <>; Wed, 16 Aug 2017 14:42:46 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tam3PvLo50AZ for <>; Wed, 16 Aug 2017 14:42:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20F75132744 for <>; Wed, 16 Aug 2017 14:42:41 -0700 (PDT)
Received: by with SMTP id x43so27708601wrb.3 for <>; Wed, 16 Aug 2017 14:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QL3NGVOB6+JZ3ukxMkukBF9jEY+KnmO5ms9/toR+m6I=; b=Nf1tw/1RkjBDQ3cqDpVNKtNlcCmT/5iWpcudokJwlcQmMTLrJZTWTpfmDIJE/AO0fp y4eZjs+D92SkdxRMcnGSroxhKPA+zZf72A4NNuLw+hmOyvLW6v+zzlGTvsoebLdf/peu ykdDf/j4JEx1JfC8B6ypfcvKSY30CW0IvSWcbCXm5b7rvQ8lr/TaOSTuJokcxEfIvgt4 iD7ZnGlp4NpyIi8tHAv0Qz1m98Ds3XzE1GsDMaExz39K2AoswxDVe3Nvbu9q9APnokDS OoZb7TWsWKvZBN/OVHOVZZurbQOCG+nrp7LyljFdY3Z1z+TyQlcaWJ8bnWK2UvyvPNri weqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QL3NGVOB6+JZ3ukxMkukBF9jEY+KnmO5ms9/toR+m6I=; b=ntwBlSTkLFEaRPH2K5diWjGtSeDn6ZIrdLZ/y6n2CvVlfPlvk+VWg1loaU0UmOaQa0 2XWjIi5Pa5dausOZ/fnHHWhHDEjiU92Zasy/OzFNeTh15TTx62ciEmhVaZv3iwK+tjyo Th+YjgB/lqqwKUmUWSvr/yfMa9IiTKzCCQnu82qYoFAoRNSIbOna5QTzlEZFqs/XIarN WJfwDd49YpAjcJ0nToPNBtsavRdyeKVwcPLIGVH4IvcZ05blHa5VettiENFxvO4ErBG2 0ncNAdcBonq99Br40pz9OFkK2TC0a6hFEsmhG9TEiRBk254BAEhW9ISSTh6ro7lL5qzJ s5bg==
X-Gm-Message-State: AHYfb5hKWVFcvAPte89jqZdaiBPYvJnnDA+7auAvj5NLCCaBwh6nJ+UU ti8z6D13iBVQn+a5vKqyOryjE7WhehqB
X-Received: by with SMTP id f5mr1873356wra.194.1502919759468; Wed, 16 Aug 2017 14:42:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 16 Aug 2017 14:41:58 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Warren Kumari <>
Date: Wed, 16 Aug 2017 17:41:58 -0400
Message-ID: <>
To: Robert Edmonds <>
Cc: Ted Lemon <>, Richard Barnes <>, Mike West <>, william manning <>, dnsop <>, Jacob Hoffman-Andrews <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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, 16 Aug 2017 21:42:46 -0000

On Wed, Aug 2, 2017 at 2:02 PM, Robert Edmonds <> wrote:
> 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.

Yup, you would think so -- unfortunately, this seems less true than
we'd expect (or hope!)

Around 0.3% of responses from Google Public DNS are for "localhost".
As an honest DNSSEC-validating resolver, Google Public DNS returns
NXDOMAIN for queries of localhost. (and all its subdomains). If you
ask with DO set, it returns the root NSEC records proving there is no
such domain (yes, this disagrees with the SHOULD in 6.3.4 of RFC6761).

As with many things in the DNS, the real world is messier than we'd --
I would have hoped that most systems would be answering locally for
queries for localhost, and never asking the DNS, but this turns out
not to be as true as we would have liked. I think that this supports
the case for the localhost document; this behavior should be firmed
up. It also exposes the fact that an application naively resolving
"localhost" and trusting the answer (for security purposes) is not
currently safe.


> 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
> _______________________________________________
> DNSOP mailing list

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.