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 127.0.0.1 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 127.0.0.1 . 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 widely. 3) If we ban localhost.example, will the operators use another abbreviation to replace localhost, such as "127.0.0.1 localmachine" ? operators are usually lazy, hardly to stop search list, and might hardly to avoid abbreviation. -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
