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