ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: "gnso-ff-pdp-may08@xxxxxxxxx" <gnso-ff-pdp-may08@xxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] Information based solutions instead of policy based solutions
  • From: Marc Perkel <marc@xxxxxxxxxx>
  • Date: Sat, 12 Jul 2008 10:26:25 -0700



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.




<<< Chronological Index >>>    <<< Thread Index >>>