An odd pattern of DNS failures began appearing in the logs yesterday: May 20 15:05:19 PDT named[345]: wrong ans. name (uzmores.com != ns5.uzmores.com) May 20 15:05:19 PDT named[345]: wrong ans. name (uzmores.com != ns4.uzmores.com) May 20 15:05:19 PDT named[345]: wrong ans. name (uzmores.com != ns3.uzmores.com) May 20 15:05:19 PDT named[345]: wrong ans. name (uzmores.com != ns2.uzmores.com) May 20 15:05:19 PDT named[345]: wrong ans. name (uzmores.com != ns13.uzmores.com) ... May 20 11:10:00 PDT named[345]: wrong ans. name (loptran.com != ns8.loptran.com) May 20 11:10:00 PDT named[345]: wrong ans. name (loptran.com != ns7.loptran.com) May 20 11:10:00 PDT named[345]: wrong ans. name (loptran.com != ns6.loptran.com) May 20 11:10:00 PDT named[345]: wrong ans. name (loptran.com != ns4.loptran.com) May 20 11:10:00 PDT named[345]: wrong ans. name (loptran.com != ns2.loptran.com) ... May 20 10:12:25 PDT named[345]: wrong ans. name (dsinlet.com != ns7.dsinlet.com) May 20 10:12:25 PDT named[345]: wrong ans. name (dsinlet.com != ns5.dsinlet.com) May 20 10:12:25 PDT named[345]: wrong ans. name (dsinlet.com != ns9.dsinlet.com) May 20 10:12:25 PDT named[345]: wrong ans. name (dsinlet.com != ns12.dsinlet.com) May 20 10:12:25 PDT named[345]: wrong ans. name (dsinlet.com != ns3.dsinlet.com) ... (All multiplied by a factor of 10) Very odd to see a dozen nameservers for several new and obscure domains. Does this look like a rat? The apparently misconfigured domains are served by a single registrar, estdomains.com. (whois -h whois.estdomains.com ..., Registration Service Provided By: N/A, Contact: +876.784848888). Certainly smells like a rat. Most of the individual nameservers do not answer queries, the ones that do are open to recursion, and all are hosted in cable/dsl/dial-up address space with correspondingly rfc-illegal reverse zones. Running 'host -at ns' a few times shows the list of nameservers is rotated every few seconds, and occasionally returns "server localhost". Obviously a rat, but the pattern brings up a number of questions. Are these spoofed queries and replies? If not, have any root nameservers been hacked? Do the queries exploit known named vulnerabilities? What ICANN policy might address this? Finally, what, if anything, are DNS admins doing about it? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
If not, have any root nameservers been hacked?
To partly answer my own question, no. The data returned by root (gtld) nameservers is not changing rapidly. Thanks for the pointers to "fast flux" too. Wasn't familiar with this attack or terminology. All the same, it would seem to be an easy and cheap abuse to address, at the gtlds. Why are these obvious trojans are being propagated by the root servers anyhow? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Sun, 20 May 2007, Roger Marquis wrote:
If not, have any root nameservers been hacked?
To partly answer my own question, no. The data returned by root (gtld) nameservers is not changing rapidly. Thanks for the pointers to "fast flux" too. Wasn't familiar with this attack or terminology.
All the same, it would seem to be an easy and cheap abuse to address, at the gtlds. Why are these obvious trojans are being propagated by the root servers anyhow?
the root servers are responsible how exactly for the fast-flux issues? Also, there might be some legittimate business that uses something like the FF techniques... but, uhm... how are the root servers involved again?
All the same, it would seem to be an easy and cheap abuse to address, at the gtlds. Why are these obvious trojans are being propagated by the root servers anyhow?
the root servers are responsible how exactly for the fast-flux issues? Also, there might be some legittimate business that uses something like the FF techniques... but, uhm... how are the root servers involved again?
Nobody's saying that the root servers are responsible, only that they are the point at which these domains would have to be squelched. In theory registrars could do this, but some would have a financial incentive not to. Also I don't believe registrars can update the roots quickly enough to be effective (correct me if I'm wrong). Given the obvious differences between legitimate fast flux and the pattern/domains in question it would seem to be a no-brainer, technically at least. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Sun, 20 May 2007, Roger Marquis wrote:
All the same, it would seem to be an easy and cheap abuse to address, at the gtlds. Why are these obvious trojans are being propagated by the root servers anyhow?
the root servers are responsible how exactly for the fast-flux issues? Also, there might be some legittimate business that uses something like the FF techniques... but, uhm... how are the root servers involved again?
Nobody's saying that the root servers are responsible, only that they
but you said it: "at the gtlds. Why are these obvious trojans are being propagated by the root servers anyhow?"
are the point at which these domains would have to be squelched. In theory registrars could do this, but some would have a financial incentive not to. Also I don't believe registrars can update the roots quickly enough to be effective (correct me if I'm wrong).
I think you really mean 'TLD' not 'root'... I think, from playing this game once or twice myself, the flow starts with the registrar to the registry (in your example estdomains is the registrar and Verisign is the registry). i think it pretty much stops there. i suppose you COULD get ICANN to spank someone, but that's going to take a LONG time to accomplish. (I think atleast)
Given the obvious differences between legitimate fast flux and the pattern/domains in question it would seem to be a no-brainer, technically at least.
hrm... I don't think it's a technical stumbling block, though trying to pre-know who's bad and who's not might get you in trouble (say I register the domain lakjdauejalkasu91er.com and fast-flux it for my own 'good' use, how's that different from 'uzmores.com' ?). Anyway... I don't disagree that there ought to be a hammer here and it ought to be applied. I'm just not sure it's as simple as it appears at first blush.
On Sun, 20 May 2007 22:19:30 PDT, Roger Marquis said:
Nobody's saying that the root servers are responsible, only that they are the point at which these domains would have to be squelched. In theory registrars could do this, but some would have a financial incentive not to.
Some have a financial incentive not to do it. Some others have no financial incentive to do it. Almost none have a financial incentive to do it. Nobody should be surprised at the outcome....
On Sun, May 20, 2007 at 10:19:30PM -0700, Roger Marquis wrote:
All the same, it would seem to be an easy and cheap abuse to address, at the gtlds. Why are these obvious trojans are being propagated by the root servers anyhow?
the root servers are responsible how exactly for the fast-flux issues? Also, there might be some legittimate business that uses something like the FF techniques... but, uhm... how are the root servers involved again?
Nobody's saying that the root servers are responsible, only that they are the point at which these domains would have to be squelched. In theory registrars could do this, but some would have a financial incentive not to. Also I don't believe registrars can update the roots quickly enough to be effective (correct me if I'm wrong).
ok... so you suggest that the roots squelch these domains? i check the contents of the root zone and find that the closest the roots come to being able to squelch these zones is to remove .com from the zone (since these other entries are not in the root but in the com zone). if you can get concensus to remove .com, i'm sure the roots would be willing to help out. --bill
Given the obvious differences between legitimate fast flux and the pattern/domains in question it would seem to be a no-brainer, technically at least.
-- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Mon, 21 May 2007, Chris L. Morrow wrote:
On Sun, 20 May 2007, Roger Marquis wrote:
If not, have any root nameservers been hacked?
To partly answer my own question, no. The data returned by root (gtld) nameservers is not changing rapidly. Thanks for the pointers to "fast flux" too. Wasn't familiar with this attack or terminology.
All the same, it would seem to be an easy and cheap abuse to address, at the gtlds. Why are these obvious trojans are being propagated by the root servers anyhow?
the root servers are responsible how exactly for the fast-flux issues? Also, there might be some legittimate business that uses something like the FF techniques... but, uhm... how are the root servers involved again?
Small note: For regular fastflux, yes. for NS fastflux, not so much.
On Mon, 21 May 2007, Gadi Evron wrote:
On Mon, 21 May 2007, Chris L. Morrow wrote:
the root servers are responsible how exactly for the fast-flux issues? Also, there might be some legittimate business that uses something like the FF techniques... but, uhm... how are the root servers involved again?
Small note: For regular fastflux, yes. for NS fastflux, not so much.
For regular FF 'yes' but for ns FF not much? Hrm, not much legit purpose? or not much the root/tld folks can do? I ask because essentially akamai's edgesuite (and I might have their product names confused some) seems to do FF ... or the same thing FF does. Doesn't it? -Chris
On Mon, 21 May 2007, Chris L. Morrow wrote:
On Mon, 21 May 2007, Gadi Evron wrote:
On Mon, 21 May 2007, Chris L. Morrow wrote:
the root servers are responsible how exactly for the fast-flux issues? Also, there might be some legittimate business that uses something like the FF techniques... but, uhm... how are the root servers involved again?
Small note: For regular fastflux, yes. for NS fastflux, not so much.
For regular FF 'yes' but for ns FF not much? Hrm, not much legit purpose? or not much the root/tld folks can do?
I ask because essentially akamai's edgesuite (and I might have their product names confused some) seems to do FF ... or the same thing FF does. Doesn't it?
Sorry, I didn't write in a clear fashion. There is a difference between fastfluxing the A record and the NS record. I don't know of many if any who change the NS record quite so frequently without being bad guys.
-Chris
On Mon, 21 May 2007, Gadi Evron wrote:
On Mon, 21 May 2007, Chris L. Morrow wrote:
On Mon, 21 May 2007, Gadi Evron wrote:
Small note: For regular fastflux, yes. for NS fastflux, not so much.
For regular FF 'yes' but for ns FF not much? Hrm, not much legit purpose? or not much the root/tld folks can do?
I ask because essentially akamai's edgesuite (and I might have their product names confused some) seems to do FF ... or the same thing FF does. Doesn't it?
I don't know of many if any who change the NS record quite so frequently without being bad guys.
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 :( -Chris
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.
Not a good justification for doing nothing while this sort of trojan propagates. As analogy, it is also true we cannot see how email-based trojans may be desirable tomorrow, but that doesn't stop us from protecting ourselves against their detrimental effects today.
It's possible that as a way to 'better loadshare' traffic akamai (just to make an example) could start doing this as well.
Actually not. There is no legitimate purpose for this dns hack.
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'
Except that there's a lot more to this pattern than simply changing NS at a rate other than normal, enough that it can be easily identified for what it is. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Mon, 21 May 2007, Roger Marquis wrote:
Except that there's a lot more to this pattern than simply changing NS at a rate other than normal, enough that it can be easily identified for what it is.
I'm not in the mood to argue, but 'do tell'. Perhaps someone from ICANN will implement this in policy for the TLD folks to use.
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?
-Chris
At 3:50 PM -0500 5/21/07, Gadi Evron wrote:
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?
Although I rarely find analogies useful when trying to explain something, I want to use one now to see if I understand this. Let's say you rob convenience stores as a career choice. Once your deed is done, you need to get away fast. So moving fast is a real help to criminals. Since moving fast is rarely helpful for decent folk, maybe we should just slow every one down - this certainly would make it easier for law enforcement to catch the criminals. If the above is not an accurate analogy to the NS fastflux issue, I'd like to know what the deviations are. I don't doubt there are any, but from what little I've gathered, the problem isn't the NS fastflux but the activity that it hides - if it is indeed hiding activity. As in, not every one speeding around town is running from the law. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale.
On 5/21/2007 at 2:09 PM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:
At 3:50 PM -0500 5/21/07, Gadi Evron wrote:
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?
Although I rarely find analogies useful when trying to explain something, I want to use one now to see if I understand this.
Let's say you rob convenience stores as a career choice. Once your deed is done, you need to get away fast. So moving fast is a real help to criminals. Since moving fast is rarely helpful for decent folk, maybe we should just slow every one down - this certainly would
make it easier for law enforcement to catch the criminals.
There are these things called speed limits on all[0] public streets (in the USA, at least). Also things like stop signs and traffic lights. People exceeding the limit and driving recklessly can and regularly are stopped by police. When such drivers attempt to evade police, they are chased, even though it is dangerous to the police, bystanders, and the people being pursued, because there is a good chance that they are running because they've done something else, something worse. So, yeah. We do have speed limits. And suspicion of nefarious activity is put on anyone who grossly exceeds them.
If the above is not an accurate analogy to the NS fastflux issue, I'd
like to know what the deviations are. I don't doubt there are any, but from what little I've gathered, the problem isn't the NS fastflux
but the activity that it hides - if it is indeed hiding activity. As
in, not every one speeding around town is running from the law.
No, but it's still prohibited. But yeah, it's just an analogy. And like many, you can bend it to support either side. [0] Last I knew, the experiments with speed-limitless roads after the drop of the federal 55 mph limit had all gone back to some arbitrary limits. Even Montana. B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
apropos of this...
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?
...i just now saw the following on comp.protocols.dns.bind ("bind-users@"): +--- | From: "Wiley Sanders" <bind@wsanders.net> | Newsgroups: comp.protocols.dns.bind | Subject: Hooray, glue updates are instantaneous! | Date: Tue, 22 May 2007 12:08:13 -0700 | X-Original-Message-ID: <e0e823c0705221208p68d5984crfc1fbe02f0c86f00@mail.gmail.com> | X-Google-Sender-Auth: fbac9c128e6c36c7 | | Well, maybe I've been out of the loop for a while but I just changed the IP | address of one of our authoritative name servers on Network Solutions' web | site and it propagated to all the gtld servers within 5 minutes. | | I don't know how this got "fixed" but for all readers out there who may | contributed to making this magic happen, my hat is off to you, and I will | quaff a brew (or more) in your honor as I consider this a significant | contribution to the march of civilization. | | -W Sanders | http://wsanders.net +--- in general, we ought to be willing to implement almost anything if free beer is going to be offered by non-criminal beneficiaries. -- Paul Vixie
On 22 May 2007, Paul Vixie wrote:
apropos of this...
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?
...i just now saw the following on comp.protocols.dns.bind ("bind-users@"):
+--- | From: "Wiley Sanders" <bind@wsanders.net> | Newsgroups: comp.protocols.dns.bind | Subject: Hooray, glue updates are instantaneous! | Date: Tue, 22 May 2007 12:08:13 -0700 | X-Original-Message-ID: <e0e823c0705221208p68d5984crfc1fbe02f0c86f00@mail.gmail.com> | X-Google-Sender-Auth: fbac9c128e6c36c7 | | Well, maybe I've been out of the loop for a while but I just changed the IP | address of one of our authoritative name servers on Network Solutions' web | site and it propagated to all the gtld servers within 5 minutes. | | I don't know how this got "fixed" but for all readers out there who may | contributed to making this magic happen, my hat is off to you, and I will | quaff a brew (or more) in your honor as I consider this a significant | contribution to the march of civilization. | | -W Sanders | http://wsanders.net +---
in general, we ought to be willing to implement almost anything if free beer is going to be offered by non-criminal beneficiaries.
If it's once in a long while like with this guy... may not be worth it. :P If it's every 10 minutes like fast fluxers... I want in on that action.
-- Paul Vixie
Gadi.
On Mon, 21 May 2007, Gadi Evron wrote:
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?
well, so it's not explicitly denied in the current operations policy things, so people may depend on it for some reason(s). They might have turned on a service that depends on it, something not related to email or web or other things. DNS is basic internet plumbing, messing with it without LOTS of study is bound to bring out wierd uses. Especially where there is no prohibition on this today, making an arbitrary limit tomorrow is going to cause problems. -Chris
On Mon, 21 May 2007, Chris L. Morrow wrote:
On Mon, 21 May 2007, Gadi Evron wrote:
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?
well, so it's not explicitly denied in the current operations policy things, so people may depend on it for some reason(s). They might have turned on a service that depends on it, something not related to email or web or other things. DNS is basic internet plumbing, messing with it without LOTS of study is bound to bring out wierd uses. Especially where there is no prohibition on this today, making an arbitrary limit tomorrow is going to cause problems.
Quite. And yet watching for such changes at the registrar level may be interesting. A couple of years ago some DNS experts disagreed. I'll try and raise this idea again and if it holds water, see if some of the registrars are game (which in itself hints to another problem). As an old boss of mine used to say: "In Hebrew we say, 'one cow, one cow'". (One cow at a time ... )
-Chris
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. People are suggesting it become the rule because nobody is trying anything else. -David Ulevitch
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
Gadi Evron wrote:
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?
People should try putting the intelligence that we have into software and hardware. Why can't we put Gadi into an edge device? I say this tongue-in-cheek, but am a bit serious. You (Gadi) are very good at looking at interesting trends and more than saying it's a problem, you are able to come up with a report like the botnet rat-out reports. We know who the C&C's are. We know who the compromised drones are. We know all of this. Today. But very few people (okay, not nobody) are saying, "Hey, why should I allow that compromised windows box that has never sent me an MX request before all of the sudden be able to request 10,000 MX records across my resolvers?" "Why am I resolving a domain name that was just added into the DNS an hour ago but has already changed NS servers 50 times?" These questions, and more (but I'm biased to DNS), can be solved at the edge for those who want them. It's decentralized there. It's done the right way there. It's also doable in a safe and fail-open kind of way. This is what I'm talking about.
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.
I disagree. DNS is the enabler for many many issues which are edge issues. (Botnets, spam, etc) -David Ulevitch
Gadi.
-David Ulevitch
On Tue, 22 May 2007, David Ulevitch wrote:
<snip>
These questions, and more (but I'm biased to DNS), can be solved at the edge for those who want them. It's decentralized there. It's done the right way there. It's also doable in a safe and fail-open kind of way.
This is what I'm talking about.
Agreed.
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.
I disagree. DNS is the enabler for many many issues which are edge issues. (Botnets, spam, etc)
There you did it, you said the B word. Now all the off-topic screamers will flame. :) Botnets, spam, etc. are symptoms, and DNS is abused to help them along. DNS abuse, i.e. abuse of DNS, is a DNS issue. David, we agree - just talking of similar issues which are.. different. Gadi.
On May 22, 2007, at 2:16 PM, Gadi Evron wrote:
On Tue, 22 May 2007, David Ulevitch wrote:
These questions, and more (but I'm biased to DNS), can be solved at the edge for those who want them. It's decentralized there. It's done the right way there. It's also doable in a safe and fail-open kind of way.
This is what I'm talking about.
Agreed.
Gadi, What is the downside of a "preview" of zones being published by a TLD? Previews could be on a 12 or 24 hour cycle. This would enable defenses at the edge by disabling fast-flux outright. There could be exceptions, of course. When millions of domains are in rapid flux daily, few protective schemes are able to sustain or afford the dispersion of raw threat information. In addition, these raw updates arrive too late at that. A "preview" would not change how the core works, only how fast changes occur, while also dramatically reducing the amount data required for comprehensive protections at the edge. This would be a policy change at the core that enables defenses at the edge. -Doug
Douglas Otis wrote:
On May 22, 2007, at 2:16 PM, Gadi Evron wrote:
On Tue, 22 May 2007, David Ulevitch wrote:
These questions, and more (but I'm biased to DNS), can be solved at the edge for those who want them. It's decentralized there. It's done the right way there. It's also doable in a safe and fail-open kind of way.
This is what I'm talking about.
Agreed.
Gadi,
What is the downside of a "preview" of zones being published by a TLD? Previews could be on a 12 or 24 hour cycle. This would enable defenses at the edge by disabling fast-flux outright. There could be exceptions, of course. When millions of domains are in rapid flux daily, few protective schemes are able to sustain or afford the dispersion of raw threat information. In addition, these raw updates arrive too late at that. A "preview" would not change how the core works, only how fast changes occur, while also dramatically reducing the amount data required for comprehensive protections at the edge.
This would be a policy change at the core that enables defenses at the edge.
Lots of people already track newly added domains. Rick Wesson runs a feed called Day old bread that is just such a feed. Again, good idea, but doesn't belong in the core. If I register a domain, it should be live immediately, not after some 5 day waiting period. On the same token, if you want to track new domains and not accept any email from me until my domain is 5 days old, go for it. Your prerogative. -david
-Doug
On 5/24/07, David Ulevitch <davidu@everydns.net> wrote:
Again, good idea, but doesn't belong in the core. If I register a domain, it should be live immediately, not after some 5 day waiting period. On the same token, if you want to track new domains and not accept any email from me until my domain is 5 days old, go for it. Your prerogative.
Well then - all you need is to have some way to convince registrars take down scammer domains fast. Some of them do. Others dont know (several in asia) or are aware and dont care - theres some in russia, some stateside that mostly kite domains but dont mind registering a ton of blog and email spammer domains. -srs
On Thursday 24 May 2007 03:13, Suresh Ramasubramanian wrote:
On 5/24/07, David Ulevitch <davidu@everydns.net> wrote:
Again, good idea, but doesn't belong in the core. If I register a domain, it should be live immediately, not after some 5 day waiting period. On the same token, if you want to track new domains and not accept any email from me until my domain is 5 days old, go for it. Your prerogative.
Well then - all you need is to have some way to convince registrars take down scammer domains fast.
Some of them do. Others dont know (several in asia) or are aware and dont care - theres some in russia, some stateside that mostly kite domains but dont mind registering a ton of blog and email spammer domains.
-srs
Very true - If this is going to work, it's goign to have to be on a global scale, Not just one country of registrars can be made to correct the problem as people who maliciously register domains will just do what the spyware companies do, go to a country that doesn't care and do business there.
On Thu, 24 May 2007, Kradorex Xeron wrote:
Very true - If this is going to work, it's goign to have to be on a global scale, Not just one country of registrars can be made to correct the problem as people who maliciously register domains will just do what the spyware companies do, go to a country that doesn't care and do business there.
isn't that why we have ICANN? Shouldn't we ask for policy at the ICANN level that penalizes registrys who can then penalize registrars for bad behaviour? From the beginning of this discussion there's ben the point made that without financial incentives this is all moot. That supposed policy should include financial penalties it would seem. -Chris
On May 24, 2007, at 6:14 AM, Chris L. Morrow wrote:
On Thu, 24 May 2007, Kradorex Xeron wrote:
Very true - If this is going to work, it's goign to have to be on a global scale, Not just one country of registrars can be made to correct the problem as people who maliciously register domains will just do what the spyware companies do, go to a country that doesn't care and do business there.
isn't that why we have ICANN? Shouldn't we ask for policy at the ICANN level that penalizes registrys who can then penalize registrars for bad behaviour? From the beginning of this discussion there's ben the point made that without financial incentives this is all moot. That supposed policy should include financial penalties it would seem.
How much more, per-domain registration or renewal, would you be prepared to pay to cover the due-diligence requirements, the additional skilled staff, the legal and PR costs when domains are cancelled due to false accusations (or true ones) and so on? (I'd be prepared to pay quite a bit more, if it were to actually work, but I know it wouldn't). Cheers, Steve
On Thu, 2007-05-24 at 12:43 +0530, Suresh Ramasubramanian wrote:
Well then - all you need is to have some way to convince registrars take down scammer domains fast.
It should be the registries responsibility to keep their registrars in line. If they fail to do so their delegation should be transferred elsewhere. Of course, to impose decent rules you'd need a root-operator whose primary goal is to act in the community's best interest with contractual terms subject to public scrutiny. You'd have to make some real draconian rules not to have anybody wanting to operate popular TLDs. Was DNS designed as a tool for internet-protocol users, or was it intended as a mechanism to distribute access to revenue-sources? //per
On 5/24/07, Per Heldal <heldal@eml.cc> wrote:
It should be the registries responsibility to keep their registrars in line. If they fail to do so their delegation should be transferred elsewhere.
Of course, to impose decent rules you'd need a root-operator whose
Moving right back to where we started off .. the core, or at least operation of the core :) This is something that can't be solved at the edge. Unfortunately. srs
On 5/24/07, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
On 5/24/07, David Ulevitch <davidu@everydns.net> wrote:
Again, good idea, but doesn't belong in the core. If I register a domain, it should be live immediately, not after some 5 day waiting period. On the same token, if you want to track new domains and not accept any email from me until my domain is 5 days old, go for it. Your prerogative.
Well then - all you need is to have some way to convince registrars take down scammer domains fast.
Some of them do. Others dont know (several in asia) or are aware and dont care - theres some in russia, some stateside that mostly kite domains but dont mind registering a ton of blog and email spammer domains.
I'm late to this party... Unresponsive registries and registrars is a huge problem wrt phishing. I am aware of at least 4 domains off the top of my head that are used exclusively for phishing which have been up for over a month since being reported to the registry and registrar. The Anti Phishing Working group has a committee working on educating these reg folks and my own employer is spending significant money at the next ICANN meeting to do the same. If you're an network operator and you'd consider null routing IPs associated with nameservers used only by phishers, please let me know and we'll be happy to provide the appropriate evidence. -John
On 5/25/07, John LaCour <johnlacour@gmail.com> wrote:
If you're an network operator and you'd consider null routing IPs associated with nameservers used only by phishers, please let me know and we'll be happy to provide the appropriate evidence.
Half of them are on fastflux so nullroutes wouldnt help. Some mailservers (recent postfix) allow you to block by NS, or there's always the good old expedient of bogusing these out in your bind resolver config, or serving up a fake zone for them. -- Suresh Ramasubramanian (ops.lists@gmail.com)
On Tue, 22 May 2007, David Ulevitch wrote:
Putting that aside, what do you think nobody should try at the edge?
People should try putting the intelligence that we have into software and hardware. Why can't we put Gadi into an edge device?
Um, where you gonna find a 48U chassis? :-) -Hank
Why are people trying to solve these problems in the core?
Because that's the only place it can be done.
These issues need to and must be solved at the edge.
Been there, done that, with smtp/spam, netbios, and any number of other protocols that would also be ideally addressed at the source or edge but, in reality, cannot.
These issues should not be "solved" by the registry operators or root server operators, that's very dangerous.
Do you know that it is dangerous to fix problems at the core or are you speculating? If you can cite specific examples please do. Simply saying it is dangerous is indistinguishable from any other verisign astroturfing.
People are suggesting it become the rule because nobody is trying anything else.
Can you say what that 'anything else' might consist of? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Tue, 22 May 2007, Roger Marquis wrote:
Why are people trying to solve these problems in the core?
Because that's the only place it can be done.
it is A PLACE, not necessarily THE PLACE. With every decision as to where there are tradeoffs, be prepared to accept/defend them.
These issues need to and must be solved at the edge.
Been there, done that, with smtp/spam, netbios, and any number of other protocols that would also be ideally addressed at the source or edge but, in reality, cannot.
maybe this is also a definition problem? "what is the core" and "what is the edge" in this discussion?
These issues should not be "solved" by the registry operators or root server operators, that's very dangerous.
Do you know that it is dangerous to fix problems at the core or are you speculating? If you can cite specific examples please do. Simply
it is dangerous, making assumptions about how people use a basic plumbing service is what gets people into trouble, ask verisign about sitefinder. much of this discussion of mitigating this issue revolves around the 'belief' that 'no one should/would ever want to rotate NS records around every five minutes'. Making statements that include absolutes is bound to be problematic. What if, for some reason unknown today, people thought that pushing around NS records regularly was helpful to their application? What if it were automated into a product like bittorrent or other widely deployed thing? What if the usage wasn't for 'where is www.sun.com' but as a signalling method or metric/best-path decision process that was never revealed to the end users? you simply can't know what options folks might use in future applications when it comes to basic plumbing things. people expect basic plumbing to 'just work' and 'just work according to the standards'. giving back falsified information is bound to generate problems (see sitefinder for a quick/simple example).
Can you say what that 'anything else' might consist of?
Sure work on an expedited removal process inside a real procedure from ICANN down to the registry. Work on a metric and monetary system used to punish/disincent registrys from allowing their systems to be abused. Work on a service/solution for the end-user/enterprise that allows them to take action based on solid intelligence in a timely fashion with tracking on the bits of that intelligence. three options, go play :) -Chris
On 5/21/07, Chris L. Morrow <christopher.morrow@verizonbusiness.com> wrote:
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 :(
Well, you can autosquish IF there's enough correlation to malware traffic and botnet hosting, like the NS set the OP posted for example. -- Suresh Ramasubramanian (ops.lists@gmail.com)
On Sun, May 20, 2007 at 09:25:37PM -0700, Roger Marquis <marquis@roble.com> wrote a message of 15 lines which said:
If not, have any root nameservers been hacked?
To partly answer my own question, no.
I cannot find the original message in my mailbox. (Not on NANOG mailing list archives.) What was the issue?
The data returned by root (gtld) nameservers is not changing rapidly.
Now, I understand nothing. Is there a problem with the root nameservers or with some gTLD nameservers???
In article <20070521081322.GA741@nic.fr> you write:
On Sun, May 20, 2007 at 09:25:37PM -0700, Roger Marquis <marquis@roble.com> wrote a message of 15 lines which said:
If not, have any root nameservers been hacked?
To partly answer my own question, no.
I cannot find the original message in my mailbox. (Not on NANOG mailing list archives.) What was the issue?
The data returned by root (gtld) nameservers is not changing rapidly.
Now, I understand nothing. Is there a problem with the root nameservers or with some gTLD nameservers???
There isn't a problem with the root or tld servers. There is a problem with the server for these zones. They don't speak RFC 1034, hence the error messages about garbage responses. Note the answer doesn't match the question. ; <<>> DiG 9.5.0a2 <<>> @76.183.141.203 ns6.loptran.com +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36800 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns6.loptran.com. IN A ;; ANSWER SECTION: loptran.com. 0 IN A 24.218.122.218 ;; Query time: 212 msec ;; SERVER: 76.183.141.203#53(76.183.141.203) ;; WHEN: Mon May 21 19:05:58 2007 ;; MSG SIZE rcvd: 60 There is a problem with the whole delegation process in that no one involved in the delegation seems to care that absolute garbage is being injected into the DNS. A few simple checks, like above, would have show that the servers were not RFC 1034 compliant. That the glue was not a copy of the records in the child zone. The parent *is* required by RFC 1034 to check this. RFC 1034, 4.2.2. Administrative considerations, paragraph 3. As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. These zones should be pulled. Mark
On Mon, 21 May 2007, Stephane Bortzmeyer wrote:
On Sun, May 20, 2007 at 09:25:37PM -0700, Roger Marquis <marquis@roble.com> wrote a message of 15 lines which said:
If not, have any root nameservers been hacked?
To partly answer my own question, no.
I cannot find the original message in my mailbox. (Not on NANOG mailing list archives.) What was the issue?
The data returned by root (gtld) nameservers is not changing rapidly.
Now, I understand nothing. Is there a problem with the root nameservers or with some gTLD nameservers???
There is the issue of fastflux, and the possible solution of blacklisting at the TLDs. Both completely separate issues for discussion-sake, as flames can be avoided. Gadi.
On 5/20/07, Roger Marquis <marquis@roble.com> wrote:
Most of the individual nameservers do not answer queries, the ones that do are open to recursion, and all are hosted in cable/dsl/dial-up address space with correspondingly rfc-illegal reverse zones. Running 'host -at ns' a few times shows the list of nameservers is rotated every few seconds, and occasionally returns "server localhost".
They're likely not name servers, or at least not all name servers.. I'd venture a guess as to these being part of a "Snowshoe" spammer network... I've been getting hit by similar domains for a few weeks now.. Blocking seems to be the best way to handle them.. Looks like some of these are running nginx (http://nginx.net/) as a web server... I've seen others with centos installs.. My guess is that the web servers are for management of the spamming software..
Roger Marquis
-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com http://blog.godshell.com
On Mon, 21 May 2007, Jason Frisvold wrote:
They're likely not name servers, or at least not all name servers.. I'd venture a guess as to these being part of a "Snowshoe" spammer network... I've been getting hit by similar domains for a few weeks now.. Blocking seems to be the best way to handle them..
Fastflux does seem to be a tool in some spammer's kits but these particular domains are probably not being used for that, at least not effectively, since they have no MX records. Are there sites that accept mail from domains without a valid MX/A record? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Mon, 21 May 2007 11:54:36 PDT, Roger Marquis said:
Are there sites that accept mail from domains without a valid MX/A record?
Depends what you call "valid". A lot of sites get *real* confused when they find out that the MX for foo.com is where foo.com's *inbound* mail servers live, and that their *outward* facing mail servers are someplace totally different (yes, there's *still* places that get this wrong - obviously, not being able to talk to any of the 800-pound gorillas or even the 200-pound dachsunds out there doesn't cause the sites to acquire kloo). Then there's all the "valid" issues caused by "domain on MAIL FROM doesn't match the EHLO and/or PTR lookups" that SPF and similar schemes haven't succeeded in curing... But in general, if a non-null MAIL FROM: arrives, and the purported domain comes up NXDOMAIN or similar *totally* unreachable (as opposed to just hinky), you're totally justified in either 4xx or 5xx'ing the sucker, because if you 250 it and then have to generate a bounce, you're left holding the bag. But again, just because it's a bad idea doesn't mean there's probably lots of places that still do it... Or as a co-worker who lurks here said the other day: "212.150.245.56 resolves to 212.150.245.56.245.150.212.in-addr.arpa And they want to know why we block it."
44.0.0.0/8 is assigned to amateur radio operators. I'm a technician licensee in good standing (callsign K0BSD) and I'd like to start using portions of this space for an access project. I've been casting around with the Google for a little bit and I can't find any central authority from which to request a prefix. Does anyone on here know how this is done? Can I expect full reachability or will prefixes from this /8 be treated as a bogons? route-views.oregon-ix.net>sh ip ro 44.0.0.0 Routing entry for 44.0.0.0/8, 3 known subnets Variably subnetted with 2 masks B 44.0.0.0/8 [20/629] via 64.125.0.137, 3d14h B 44.16.15.0/24 [20/20] via 129.250.0.11, 04:55:18 B 44.130.99.0/24 [20/0] via 134.55.200.1, 2w0d .
Neal R wrote:
44.0.0.0/8 is assigned to amateur radio operators. I'm a technician licensee in good standing (callsign K0BSD) and I'd like to start using portions of this space for an access project. I've been casting around with the Google for a little bit and I can't find any central authority from which to request a prefix. Does anyone on here know how this is done? Can I expect full reachability or will prefixes from this /8 be treated as a bogons?
route-views.oregon-ix.net>sh ip ro 44.0.0.0 Routing entry for 44.0.0.0/8, 3 known subnets Variably subnetted with 2 masks
B 44.0.0.0/8 [20/629] via 64.125.0.137, 3d14h B 44.16.15.0/24 [20/20] via 129.250.0.11, 04:55:18 B 44.130.99.0/24 [20/0] via 134.55.200.1, 2w0d
.
I can't speak for the overall reachability of the netblock, but you can find out more at http://hamradio.ucsd.edu/ and find a coordinator here: http://noh.ucsd.edu/~brian/amprnets.txt -- ~Andy Brezinsky On Mon, 2007-05-21 at 17:09 -0500, Neal R wrote:
44.0.0.0/8 is assigned to amateur radio operators. I'm a technician licensee in good standing (callsign K0BSD) and I'd like to start using portions of this space for an access project. I've been casting around with the Google for a little bit and I can't find any central authority from which to request a prefix. Does anyone on here know how this is done? Can I expect full reachability or will prefixes from this /8 be treated as a bogons?
route-views.oregon-ix.net>sh ip ro 44.0.0.0 Routing entry for 44.0.0.0/8, 3 known subnets Variably subnetted with 2 masks
B 44.0.0.0/8 [20/629] via 64.125.0.137, 3d14h B 44.16.15.0/24 [20/20] via 129.250.0.11, 04:55:18 B 44.130.99.0/24 [20/0] via 134.55.200.1, 2w0d
The last time I looked into this there wasn't anything being done with the block, but now I see lots of people assigned to do various things - should have looked before I said anything, but in 2001 this was totally dead, at least in Iowa/Nebraska. Andy Brezinsky wrote:
I can't speak for the overall reachability of the netblock, but you can find out more at
and find a coordinator here:
http://noh.ucsd.edu/~brian/amprnets.txt
-- ~Andy Brezinsky
On Mon, 2007-05-21 at 17:09 -0500, Neal R wrote:
44.0.0.0/8 is assigned to amateur radio operators. I'm a technician licensee in good standing (callsign K0BSD) and I'd like to start using portions of this space for an access project. I've been casting around with the Google for a little bit and I can't find any central authority from which to request a prefix. Does anyone on here know how this is done? Can I expect full reachability or will prefixes from this /8 be treated as a bogons?
route-views.oregon-ix.net>sh ip ro 44.0.0.0 Routing entry for 44.0.0.0/8, 3 known subnets Variably subnetted with 2 masks
B 44.0.0.0/8 [20/629] via 64.125.0.137, 3d14h B 44.16.15.0/24 [20/20] via 129.250.0.11, 04:55:18 B 44.130.99.0/24 [20/0] via 134.55.200.1, 2w0d
Neal R wrote:
The last time I looked into this there wasn't anything being done with the block, but now I see lots of people assigned to do various things - should have looked before I said anything, but in 2001 this was totally dead, at least in Iowa/Nebraska.
I've had an address for considerably longer than that :) To answer the original poster: net 44 generally isn't directly routable to the Internet, because there are severe restrictions on the kind of traffic that can be carried over ham radio bands. net 44 is intended to be an internet constructed using radio links. However, there are several gateways, and net 44 currently uses several tunnels over the Internet backbones to join geographically separated radio networks. There's a whole lot of stuff going on there (including some IP addressable satellites). -- Harald
participants (23)
-
Andy Brezinsky -
bmanning＠karoshi.com -
Chris L. Morrow -
Crist Clark -
David Ulevitch -
Douglas Otis -
Edward Lewis -
Gadi Evron -
Hank Nussbacher -
Harald Koch -
Jason Frisvold -
Joel Jaeggli -
John LaCour -
Kradorex Xeron -
Mark Andrews -
Neal R -
Paul Vixie -
Per Heldal -
Roger Marquis -
Stephane Bortzmeyer -
Steve Atkins -
Suresh Ramasubramanian -
Valdis.Kletnieks＠vt.edu