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

[Marc Perkel <marc@xxxxxxxxxx>]

Dave Piscitello wrote:
> 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.
DNS is very fast and very low overhead. In the spam filtering world 
there are a variety of DNS based "black list" of IP addresses of known 
spam bots. I personally control the worlds largest DNS white list of 
servers that never send spam. But DNS can return much more that just IP 
addresses. They can return short text strings using the TXT records. 
Here's how this would work technically. Let's say we start with the 
domain icann.info as the information domain. And we have a policy that 
each registrar maintain a compatible DNS database of their own to allow 
anyone to query non-private information about the domain.
The first step is to query the domain icann.info to determine the 
registry. I will use the domain example.com as what I want to look up.
dig example.com.registrar.icann.info TXT

This might return "networksolutions.net"

I then query networksolutions.net

dig example.com.age.networksolutions.net TXT

Which might return "768" indicating the age in days of the domain. I 
migh then query for changes:
dig example.com.ns-changes.networksolutions.net TXT

That might return maybe 3 numbers. The first being number of NS changes 
in the last 6 hours - then the last day - then the last 4 days. So lets 
say it returned the string "16,64,256". That would indicate the domain 
is fluxing every 15 minutes and perhaps something funny is going on 
there. Most domains would return "0,0,0" or maybe "0,1,1".
This is an important point to keep in mind. This is just information 
made available to help make decisions with, or who to contact if a 
problem is suspected. This information would not likely be used to block 
or pass email by itself, but rather to help paint a bigger picture. It 
would allow the rest of us who can respond faster than policy changes to 
stop fraud in real time.