RE: [gnso-ff-pdp-may08] Information based solutions instead of policy based solutions

["Greg Aaron" <gaaron@xxxxxxxxxxxx>]

Dear Marc:

In answer to your questions:
"Is it within the scope of what ICANN can do to ask/require registries to
make available more information about a domain?" Specifically:

1) "The domain's registrar": ICANN-regulated TLDs (and their registrars) are
already required to publish that information via WHOIS.  ICANN has no say
over the WHOIS practices of ccTLDs, and ccTLD practices in this particular
area vary.

2) "The number of days old based on the current domain owner":
ICANN-regulated TLDs (and their registrars) publish current registrant
contact info via WHOIS.  ICANN has no say over the WHOIS practices of
ccTLDs, and ccTLD practices in this particular area vary.  
        There's a more fundamental issue, I believe: fast-fluxing domain
names are not usually old domains that have changed hands.  In my
experience, fast-fluxing names are of more recent vintage, and were
purchased by the entities that are hosting them on fast-flux setups.  
        Also, cyber-criminals tend to either a) use fake contact data, or b)
use proxy contact services.  Either way, their registrant data is often
unreliable or is obscured.
        Also, you are asking a question about changes to the registrant
information.  Note that a change to registrant information is not always a
change in real ownership.  (For example, a company can change its name.  And
many entities put a person's name in the Registrant Name field, and those
names change as people come and go at the organization.)  

3) "The number of name server changes made in the last 3 days?"  I suppose
ICANN could require such from the ICANN-regulated TLDs via a consensus
policy or contract changes, but this is unlikely.  There is no way for ICANN
to require it from ccTLDs.  
        There's a technical issue with this solution: most flux is not
accomplished by changing the nameservers associated with a domain name.
It's accomplished at a level below the registry, and the real issue is the A
records.  So those changes may not be reflected in registry records at all,
and having a registry report in the manner you suggest would be of limited
use.

So, I do not think that the solutions #2 and #3 above address the means by
which fast-flux is executed.

All best,
--Greg


-----Original Message-----
From: owner-gnso-ff-pdp-may08@xxxxxxxxx
[mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Marc Perkel
Sent: Friday, July 11, 2008 1:47 PM
To: gnso-ff-pdp-may08@xxxxxxxxx
Subject: [gnso-ff-pdp-may08] Information based solutions instead of policy
based solutions


First of all the conference call was great and helped clarify a lot of 
things for me. This is all very new to me as this is the first group of 
this nature I've been involved in. Sometimes I'm better at relating to 
machines than people and need to grasp the process more. I'm more of an 
engineer and more focused on solutions. So defining the problem helps do 
that.

I want to throw out some raw ideas just to get some feedback as to the 
scope of solutions available. I am someone who favors informational 
and/or best practices based solutions as opposed to restriction based 
solutions.

Let me see if I can explain what I'm talking about. Rather than 
registrars putting limits on what can be changed or how fast nameservers 
can be changed, maybe the solution is to publish these change rates and 
other non-private information abut domain names through DNS queries so 
that spam filtering companies, like mine, can use this information to 
help detect fraud through fast fluxing.

Wendy brought up a point that and oppressed political group might use 
fast flux to get information out about evil deeds within that country. 
That needs to be distinguished from a criminal organization who is 
impersonating a bank in order to steal your money.

Thus if there are legitimate uses for fast flux if we use policy to 
prohibit it then we might block an important free speech that needs to 
get out.

However - if as a spam filtering company I could detect that a domain 
was fast fluxing then I could combine that information with other 
information in the content of the email that I am assessing to determine 
if the message should be passed or blocked. If, for example, the message 
contains a link to a fast flux domain AND it also appears to be bank 
fraud then I can not only block it but submit the information to 
automated URI based block lists to allow other spam filtering worldwide 
to block, and perhaps forward the fraud email to someplace to report fraud.

However, if the message appears to be fast fluxing and is free speech 
exposing oppression then I might consider it a white rule to enhance 
delivery.

What I'm talking about is to create policy that makes public information 
about domains that is not private and would help people like me 
determine if something unusual was happening with a domain. If I could 
read the age of the domain and I could know if a high number of changes 
has been made recently then that might be useful in distinguishing free 
speech from fraud.

The advantage of an information based solution is that spam filtering 
companies can adapt to changes in criminal behavior faster that ICANN 
policy can.

I have found that it is far easier to determine spam and fraud by the 
behavior of the spammer than they content of the message. The more 
information I have the more accurate my filters will be.

So - my question. Is this possible? Is it within the scope of what ICANN 
can do to ask/require registries to make available more information 
about a domain? Specifically:

1) The domain's registrar.
2) The number of days old based on the current domain owner?
3) The number of name server changes made in the last 3 days?

Marc Perkel
http://www.junkemailfilter.com