Mark Andrews <ma...@isc.org>于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: http://seclists.org/bugtraq/2008/Jan/270 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 <rharo...@umich.edu> wrote: > > > On Thu, Feb 1, 2018 at 4:26 PM, Ted Lemon <mel...@fugue.com> wrote: > >> On Feb 1, 2018, at 2:48 PM, Andrew Sullivan <a...@anvilwalrusden.com> >> 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@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
