ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-ff-pdp-may08] Jump start on answering GNSO questions regarding fast flux

  • To: "gnso-ff-pdp-May08@xxxxxxxxx" <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] Jump start on answering GNSO questions regarding fast flux
  • From: Marc Perkel <marc@xxxxxxxxxx>
  • Date: Wed, 02 Jul 2008 08:25:20 -0700

I'd like to make the suggestion that perhaps one of the solutions to fast flux might be in providing more information about domains rather than just adding restrictions like rate limiting changes. I am in the spam filtering business (http://www.junkemailfilter.com) and I've found that it is much easier to detect phishing by the behavior of the spammer than by the content of the message. Thus the more information I have the better I can detect phishing.

Spammers are always on the run and having to change to avoid detection. If a spammer were on a stable IP address that IP would quickly make all the popular DNS based blacklist and nothing they sent would make it through anyone's filters. In the spam filtering world we tend to work together to create collaborative technologies to block spam collectively. This a stable spammer is easy to detect.

A key principle to keep in mind is that spammers and phishers always want you to do something. They want you to "click here". The want you to reply to the email. If the spammer is going to get the victim's money or identity they have to be able to establish a connection with the victim and get the victim to either send them money or visit a fake web site where the victim give up their passwords to their accounts.

In order to phish the phisher has to accomplish a number of things. They have to create a platform for sending large quantities of spam. That is often a botnet. Then they have to get their message past spam filtering - people like me - in order to get their message in the victim's inbox. They then need to seduce the victim into acting. Often they pretend to be a bank and the message is "Your account has been suspended. You need to log in to your account to fix the problem." A link is provided which redirects the victim to the fake web site where the victim enters their login information and the phisher clean out their bank account.

This kind of spam is usually not hard to detect. And one can follow the link to the phisher's web sites and shut them down. These web sites are usually either part of the botnet or legitimate domains that have been exploited due to a security flaw. If the targer web server is shut down then all the phisher's emails are wasted. The victim clicks on the link and nothing happens.

Thus to extend the life of the fake servers phishers have resulted to using fast flux hostig. This allows the phisher to rapidly change name servers and to change the A record rapidly so that as the servers get shut down the phishers can redirect victims to new servers and continue to get their money.

In the case of fast flux the domain is under the control of the phisher. The phisher has to log in and make changes. This is probably done through automation. The phisher probably has a lot of domains and they have scripts that manage all of them. They need to be able to go in and make rapid changes to their setting and we have already identified that as a point we can control by rate limiting changes.

Let me however introduce some new ideas at this point. Registrars have customers and customers have domains. These are two different databases that the registrar controls. In order for a phisher to get a domain for fast flux they first need to be a customer. So if I'm a phisher I'm going to be a fake customer with a lot of domains or I might be a lot of customers with a one domain each. I suspect the most phishers are one customer with lots of domains.

One of our missions here is to make sure we don't burden legitimate people who are doing legitimate things. I've found that most every time I create some new restriction I run into an exception where someone legitimate runs into my restriction. So - I want to stop and make an important point here.


Instead of just actively detecting criminals, our solution should also actively detect non-criminals. We should treat old customers with old domains differently than new customers with new domains.

One of the ways I get my accuracy up in spam filtering is that I don't only look for spam. I actively try to detect non-spam and pass it through the system without restrictions. And non-spam is easier to detect because it comes from servers that are long term stable servers that send millions of good emails every day. For example, my bank Wells Fargo (wellsfargo.com) never sends any spam at all. All their outgoing servers come from hosts whose Forward Confirmed RDNS always resolves to *.wellsfargo.com. If I get an email from *.wellsfargo.com then I know it's good and I can skip all other testing and pass the message. This precludes the possibility that some other test might accidentally block it.

So if a registrar has an old customer with old stable domains then those customers and domains should be treated differently than a new customer with new domains. We can then look at behavior and determine if someone is fast fluxing and if someone is not.


Although the registrars can implement steps to detect fast fluxing they could also provide more public information through DNS calls to help other, like me in the spam filtering business, to detect faxt flux and generate blacklists of fast fluxing domains. Registrars could then download the URIBL lists and see what domains they control are on those lists as an indicator of where trouble might be. The registrar doesn't have to do all the work here - we in the spam filtering community can help because we might be in a better position to detect fast flux than registrars are.

For example - suppose I could find out the age of the domain (by it's current owner) and the number og NS changes made in the last 3 days. 99.99% of all these would be domains that are older than 90 days with less than 2 changes. Then there will be a group that is very new domains of new customers and there are say more than 3 changes. This domain would be highly suspect. If that information were combined with information in an email that I was processing where I determined a spoof had occurred then I could assert with a very high degree of accuracy that a fast flux domain had been detected.

I could then use some kind of automated reporting system to report back to registrars suspected trouble. And if other spam filtering companies also were sending reports on the same domain then the registrar could freeze NS changes or disable the domain.

So - my question to this group is - what additional information can registrars legally and practically provide about a domain? Right now registrars provide NS records telling the world what the name servers are. Can registrars tell us the age of the domain and the number of receint changes to the NS records?

Also - if registrars used capcha to discourage automated NS changes - at least for new customers our new domains, that would stop automated scripts from updating NS fast and kill a lot of fast flux.

Hope this email isn't too long. I hope these ideas are thought inspiring.

Marc Perkel
Fearless Leader
Junk Email Filter

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy