RE: [gnso-ff-pdp-may08] Information based solutions instead of policy based solutions
- To: "'Marc Perkel'" <marc@xxxxxxxxxx>, <gnso-ff-pdp-may08@xxxxxxxxx>
- Subject: RE: [gnso-ff-pdp-may08] Information based solutions instead of policy based solutions
- From: "Greg Aaron" <gaaron@xxxxxxxxxxxx>
- Date: Fri, 11 Jul 2008 14:31:14 -0400
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
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
So, I do not think that the solutions #2 and #3 above address the means by
which fast-flux is executed.
[mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Marc Perkel
Sent: Friday, July 11, 2008 1:47 PM
Subject: [gnso-ff-pdp-may08] Information based solutions instead of policy
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
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
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
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
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
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?