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

Lanlan Pan <> Sun, 04 February 2018 03:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C60E126DEE for <>; Sat, 3 Feb 2018 19:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 BnPK83etumTg for <>; Sat, 3 Feb 2018 19:32:04 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EA1D12420B for <>; Sat, 3 Feb 2018 19:32:03 -0800 (PST)
Received: by with SMTP id r71so20003664wmd.1 for <>; Sat, 03 Feb 2018 19:32:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3wlV6ahadnLGkh3ue4VGqG9oB6QPUyN93iBhUUqQyo=; b=tQIh06tb3BZKTaoFwBWAAa1gL2GZ/GWJN3bJX0eCGM6NH3q953M6Tm7ZBUhFPUP5Cq PubyfcKIF9einWU4WARxe7WpsLu67kvTO5KnOyYVIbMJGAl7Kstp+tEZWH/zLHPvS4fY F/CoCX+k8S68Gk06vgmQ8lGN4l7EWen/1+YWFYl6Jn+BdoIULRV7VI/UpQ26Aix51vYo 6NX/rTaKLri1rivCHXr7ZqWtJPYcpFjxmQM7Psd9Ilvg29MnA+ihiE+Fp7pPQUyBDosp eAyYbqNn6OZV8LtX3boc6dlQBkggXqqsI6IHbjxcjOvfNL1aON8apKTI37U6RsbczmKE s+MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m3wlV6ahadnLGkh3ue4VGqG9oB6QPUyN93iBhUUqQyo=; b=KyTl/h+AAl1Xo1PzVrrX0pyxQVadBA5FBFYFLKpgF5lb7oIg99SDgNiMaJk+3eIM4t bFS+NkAWoIWxV0I1kA9Z9LSd8ZS6Gt+dHE8WALMd7aquA4EytL9r5y69NSpLgjyq4ZQ4 OAfqLOdYJ6Gh7ol2QEA5W1gwUtBA1/0RwdubXUCOnyoaa7x+wdtEUCpIwVrSk58LUFYe yoZrUGRSEC71NutHHQ7rcvUi+W7FyGbnVOntXNIHF3H9ADOrgzT6Fk0rxX+Q7aixu6ry cr1L0kynQM0xCsJ958OziAT2vTx9Es+5yLUVe7sn+lHx2GNQqavqowzmjVi8NGl8TF6I EIag==
X-Gm-Message-State: AKwxyteD9jKHc5sjRK6XAX/OXa5jOdu9ZWaVD9jm+XVR/WHfRf7A+Q/n OSlEYbYuKgBR/FEU8j5HYoPt6Wi+ZjB6wlM/8mRV4Q==
X-Google-Smtp-Source: AH8x225JmQtvqO6l+rIwSfFEaAzAB2Gshd9SJtAWm30yHTLGQL517uC9DlsBIn/hiYzKW5wlH9UequxesDap4K4bYMY=
X-Received: by with SMTP id x10mr66923030edj.118.1517715121888; Sat, 03 Feb 2018 19:32:01 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Lanlan Pan <>
Date: Sun, 04 Feb 2018 03:31:51 +0000
Message-ID: <>
To: Mark Andrews <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="089e08222b4cb5e1df05645a9682"
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: Sun, 04 Feb 2018 03:32:07 -0000

Mark Andrews <>于2018年2月3日周六 上午4:11写道:

> The problem is that search lists are being applied when “localhost” is
> being entered into name lookup APIs and is being matched against
> localhost.example which isn’t expected to  to a address on the current
> machine and that the search list may be auto constructed or come from a
> untrusted source.

If only consider about http:
Web browser can also ban this "localhost.example".
CA Single Sign-On might help to solve the "same site" cookie expose problem.

> There is also a small risk that hotspots will return something other than
> a local address if a address lookup for .localhost is made.
> This is all in the context of processing  urls.
> Localhost is the last remanent of the pre hierarchical host scheme.
> The risks are eliminated if the name APIs use local lookup sources in
> those contexts.
> Then you have legacy clients. As long as the servers for the namespace on
> the public Internet don’t return A or AAAA records for localhost the issue
> is addressed there.
> You then have the recursive server where you would like it, by default,
> return a answer without contacting the root servers.  The only safe way to
> do that is to have it serve a empty zone for localhost.  As this zone isn’t
> linked into the global DNSSEC chain of trust the root zone needed a
> insecure delegation for localhost.
> --
> Mark Andrews
> On 3 Feb 2018, at 05:25, Bob Harold <> wrote:
> On Thu, Feb 1, 2018 at 4:26 PM, Ted Lemon <> wrote:
>> On Feb 1, 2018, at 2:48 PM, Andrew Sullivan <>
>> wrote:
>> As a general principle, when what the RFC says to do is not the right
>> thing to do, the solution is to update the RFC, not to ignore the problem.
>> I strongly agree with this (as I think or anyway hope you know)
>> Yes, I will admit I was a bit surprised that you put it that way,
>> although as you say, your position is more clear in your formal review of
>> the document.
>> 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.   You are a much more experienced DNS expert than I
>> am, so for me to argue you away from those opinions is a tall order—I don't
>> think you've really expressed the underlying belief that is the keystone to
>> the whole edifice.
>> 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.   We've
>> had that discussion before.   We even published a document about it, which
>> hasn't quite made its way out of the RFC editor queue yet.   It seems to me
>> that it is demonstrably the case that these two sets are disjoint.
>> 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.   So if
>> we were to succeed in understanding why we disagree on this point, it would
>> be necessary to dig down into that.
>> Having seen you give keynotes at the plenary, I know that you are deeply
>> concerned about computer security.   The reason that I am in favor of the
>> behavior I'm propounding is that I think it closes a small security gap
>> through which a truck might some day be driven, to our woe.   So to me, the
>> need to leave that gap, which I admit is small, open, seems inconsistent
>> with what I know of you.
>> So clearly you value this idea that localhost is a name that exists in
>> the DNS, even though it doesn't exist in the DNS.   It might be fruitful to
>> explore that further.   It might also be a waste of time.   I don't
>> honestly know.   But that is, I think, the key to our disagreement.
> Could someone explain the security problem?  If it really is bigger than
> the problems that will be caused by changing resolvers to answer with
> NXDOMAIN, then you might convince me.
> --
> Bob Harold
> _______________________________________________
> DNSOP mailing list
> _______________________________________________
> DNSOP mailing list
致礼  Best Regards

潘蓝兰  Pan Lanlan