|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Interesting new dns failures
On Tue, 22 May 2007, David Ulevitch wrote: > Gadi Evron wrote: > > On Mon, 21 May 2007, Chris L. Morrow wrote: > >> ok, so 'today' you can't think of a reason (nor can I really easily) but > >> it's not clear that this may remain the case tomorrow. It's possible that > >> as a way to 'better loadshare' traffic akamai (just to make an example) > >> could start doing this as well. > >> > >> So, I think that what we (security folks) want is probably not to > >> auto-squish domains in the TLD because of NS's moving about at some rate > >> other than 'normal' but to be able to ask for a quick takedown of said > >> domain, yes? I don't think we'll be able to reduce false positive rates > >> low enough to be acceptable with an 'auto-squish' method :( > > > > Auto-squish on a registrar level is actually starting to work, but there > > is a long way yet.. > > > > As to NS fastflux, I think you are right. But it may also be an issue of > > policy. Is there a reason today to allow any domain to change NSs > > constantly? > > Why are people trying to solve these problems in the core? > > These issues need to and must be solved at the edge. In this case the > edge can be on customer networks, customer resolvers, or at the > registrar. It's dangerous to fix problems at the core where visibility > is limited and data is moving quickly. > > These issues should not be "solved" by the registry operators or root > server operators, that's very dangerous. > > There are, of course, exceptions where it's helpful when a registry > operator steps in to help mitigate a serious Internet disturbance, but > that's the exception and should not be the rule. > Amen. > People are suggesting it become the rule because nobody is trying > anything else. I was with you up to this sentence. Obviously avoiding the core is key, but should we not have the capability of preventing abuse in the core rather than mitigating it there? Allowing NS changes with no other verification or limitation is silly imo, but I am unsure if it is relevant as a solution? And who is nobody and why doesn't he try something else? That is a bit insulting to nobody. :) Putting that aside, what do you think nobody should try at the edge? After all, nobody's security being affected by the edge of some end-user machine on the other side of the world is irrelevant to my edge security. FUSSP. DNS abuse is mostly not an edge issue. Gadi. > > -David Ulevitch > >
|