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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

DNS is fast and low overhead b/c for the most part no one has tried to make it 
do more than it ought. In fact, I would argue that the DNS may be the least  
overloaded protocol above TCP (look at the competition- FTP, SNMP,  SMTP, HTTP, 
SIP - lols).

However, you are correct that name servers know a lot more about the state of 
the name service than the DNS protocol "reveals", so I agree that the DNS can 
return more information than it does.

ICANN isn't the body that decides what the DNS protocol does and does not do. 
ICANN does policy, not Internet architecture and protocol definition. If you 
want to enact the change you are suggesting, you have to go to the IETF. That 
body has to agree that what you suggest has merit and that the DNS is the 
appropriate protocol. Then someone (perhaps you) has to take the idea from 
"idea" to a standard (RFC) that describes how this feature is to be 
incorporated into the DNS protocol. Only then will you be able to get 
commercial vendors and open source developers to implement it in an 
interoperable way.

I was on the IESG a long while ago, but I roughly recall the process as 
involving at least these steps:


 1.  write up an proposal for an RFC
 2.  identify the data you want the DNS to maintain
 3.  identify the changes/extensions to the DNS query and response messages
 4.  submit it to the IESG/IETF and propose that an IETF WG study the proposal
 5.  push the proposal through standards track process, which involves review 
cycles, prototyping, interoperability testing, and demonstration of willingness 
to implement by the community (primarily vendors)

Once it's on the standards track, early adopters can experiment with it to see 
if it scales, what effect it may have on performance, etc.

Both the DNSSEC and IDN specifications were developed by the IETF. ICANN 
continues to develop policy for IDN, and recently we are seeing more policy 
"activity" for DNSSEC.

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



Dave Piscitello wrote:
Re: [gnso-ff-pdp-may08] Information based solutions instead of policy based 
solutions 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.