Re: [gnso-ff-pdp-may08] Proposed solutions - DNS Information Solution

[Marc Perkel <marc@xxxxxxxxxx>]

Thanks for opening up the solution part of the discussion. I had just 
sent a version of this email below to Joe St Sauver this morning but 
perhaps others can jump in.
Let me say this this is a rough idea in development and if there's any 
problem or objections to it I'd like to hear about it. I'm more than 
happy to abandoned this idea if it's a bad idea.
I've become aware of some of the controversies around whois, and want to 
avoid getting in the middle of that. So I'm not going to refer to it as 
publishing whois through DNS. But for those of you who will say, "this 
information is already available through whois" - it's not really 
because the people who would use this need that data in a different form 
that is compatible with real time queries and the whois protocol just 
isn't fast enough.
As to concerns about new technology and new standards - what I'm 
proposing here uses existing technology and existing standards. This is 
I believe simple stuff that could be implemented in an afternoon. At 
least it's my goal to keep it that way.
And - the exact implementation - if people like the idea - is up for 
discussion. There are people in the group who can do a better job on the 
details than I can. Especially the registrars. Much of this affects the 
registrars directly so I would particularly want to hear from them. My 
goal here is to make life easier for everyone except for criminals.
The concept is based around making public information available at high 
speed so that we on the edges can use it to make real time decisions so 
as to stop spam carrying links to fast flux domains that are being used 
improperly. We would be in a position to respond faster to threats, 
abuses, and changes in tactics than anyone else.
As to privacy, if anything here is a threat to privacy, freedoms, or 
civil liberties I want to know about that. The preservation of Internet 
freedom is extremely important and must be preserved.
This information is not only for detecting fast flux, but also what is 
not fast flux. The idea is not only to catch the bad guys, but to avoid 
false positives. Thus if a domain is fluxing, but it's an old stable 
domain and it's paid up 5 years in advance then that information might 
protect that domain from accidentally being misclassified.
Here's what I'm thinking.

1) Figure out what data would be useful for fighting spam/fast 
flux/fraud that is easily available.
2) Figure out what is the best way to structure the information (spec 
out a solution)
3) Avoid whois privacy concerns issue.

Let's say that example.com is listed with tucows.com. Let's say that 
icann.info will become an information domain. It will be the domain for 
all centralized data. But - and here's a question I have - some data 
might be best provided by the registrars. In other words tucows or 
godaddy might have some of the data. So I'll assume that there will be 
perhaps a godaddy.info and tucows.info to provide information on the 
domains they control.
And - I'm just throwing out these as raw ideas. If you have better ideas 
that would be great.
I'm also thinking that we'll use rbldnsd to distribute the information. 
The software rbldnsd is a standard open source program that is used in 
the spam filtering community for blacklist and whitelist information. 
It's solid - it's fast - and just a few servers would be required to 
provide information to the whole planet.
So - what information do we need and how do we provide it. First - I 
think we need to be able to look up the registrar of the domain.
dig example.com.registrar.icann.info txt

This would return "tucows.com". Or - there might be a separate lookup 
for information servers as follows:
dig example.com.info-server.icann.info txt

Would return tucows.info

With registrar information if there is a problem domain then we can 
alert the registrar of the problem for automated reporting. So we would 
assume that "abuse@xxxxxxxxxx" would be the abuse address - or - we can 
look up the abuse address as follows.
dig example.com.abuse-email.tucows.info txt    or
dig example.com.abuse-email.icann.info txtr - if it is centralized.

I have some ideas on keeping the spammers out of the automated reporting 
system. But I'm going to save that for later.
In this discussion I'm going to assume that tucows is the source of the 
data. If this can be centralized that would be great. So - the next 
issue is what data do we need to fight FF. As to the Whois controversies 
- we really don't need the owner information because in the case of FF 
it would all be bogus. But here's what I'd like to know.
Age of the domain - maybe a start date - maybe start date by current owner.

Expiration date - domains that are paid in advance several years are 
less likely FF domains.
Tech Email - the email address to contact the tech person for the domain 
- person to contact to alert to problems.
Nameserver Changes - some kind of information indicating the rate that 
name servers have been changed. (maybe 127.0.0.x codes) indicating some 
formula of evaluating change rates.
Examples:

dig example.com.domain-age.tucows.info txt
dig example.com.domain-expire.tucows.info txt
dig example.com.abuse-email.tucows.info txt

These might return date or might return a number which represents the 
ages and expiration in days from the current date.
As a spam filtering company, and this applies to similar operations as 
well as those doing spam filtering, this information would be helpful, 
when combined with other information, to determine if email is to be 
passed or blocked. Most scams have an email/spam component. Scam require 
that every step in the process work. So if the scam can be stopped or 
reduced at the spam level then the scam is disrupted and the cost to 
society is decreased.
Additionally, I am not suggesting this as the only solution but as one 
of many things we can propose. So this is not instead of everything else.
This proposal also has the quality of being a non-restriction based 
solution. It doesn't take away anything from rights or liberties nor 
does it stop existing or future useful technologies. And I believe that 
the information provided isn't going to do any harm, which is important.
In Conclusion:

What I'm looking for in response is the following.

1) Concerns - tell me why this isn't a good idea.
2) Improvements - tell me how to make the idea better.
3) Unintended consequences - If this is harmful to anyone we are going 
to want to know it.
4) Burden - if this is going to cause a burden on anyone we need to know it.

And - I'm new to this process. I'm used to jumping in with ideas. 
Sometimes I come across as pushy or impatient and I'm not always best at 
explaining the details. So asking in advance that you understand that 
policy is new to me. I'm a tech geek and I relate to computer better 
than people sometimes.
Thoughts?