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:
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
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.