Ted Lemon <mel...@fugue.com>于2018年2月6日周二 上午12:52写道:

> On Feb 5, 2018, at 1:51 AM, Mark Andrews <ma...@isc.org> wrote:
> No it is not! The browser knows where the name came from.
> Walk me through it.   How does the browser know where the name came from?

we can return NXDOMAIN for localhost. , little influence.

If we decide to ban localhost.example,  there is an assumption we have
accepted: the "localhost" subdomain to is fault, because of http
cookie flaw.
The divergence is:  where is the best postion to ban it / mitigate it ?
1) dns :  this draft.
2) browser: browser can ban the request to localhost.example, or even the
request to subdomain xxx.example whose ip address is .
3) http protocol:  CA Single Sign-On (CA SSO) ,  Token Binding for TLS, etc.

There are some security policy effect concerns:
1) how many security accidents have caused by this "localhost.example", is
it a serious security problem with low attack cost ?
As far as I can see, this attack's successful preconditions:
- servers doesn't sperate diffferent website.
- attacker must gain the server privilege, open a unusually port to give a
local http service. ---- this is a high risk alarm trait.
- attacker must fraud users to visit the flaw url.

2) is this the most important http cookie expose disaster area ?
As far as I can see,  many recursive resolvers hijack nxdomain, and return
an A record for advertising, similar with this cookie expose and more

3) If we ban localhost.example, will the operators use another abbreviation
to replace localhost, such as " localmachine" ?
operators are usually lazy, hardly to stop search list, and might hardly to
avoid abbreviation.
致礼  Best Regards

潘蓝兰  Pan Lanlan
DNSOP mailing list

Reply via email to