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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

Marc,

I can see the value in having such information published.

I don't understand why you would want to overload the DNS protocol in this 
manner.  How would you propose to encode this (what section of what kind of 
record)? Would you expect ICANN to ask the IAB/IETF to develop an RFC for this 
extension?

I'm also curious where you would use this query/response. In each client? At 
antispam gateways?  How would you assure that the feedback loop you create 
would have a low incidence of false positives, i.e., could you deploy this with 
confidence that attackers would not attack the system and cause legitimate 
sites to be block-listed?

It's tempting to look at a protocol that's already deployed and think about 
extending its utility to satisfy other needs. It might also be useful to think 
about a more out of band solution that complements what antispam software 
currently does with existing block list types of databases.

On 7/11/08 1:47 PM, "Marc Perkel" <marc@xxxxxxxxxx> wrote:



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