ISC announces a new way of delivering domain reputation data

Written by Rod Rasmussen Thursday, 12 August 2010 09:49

Internet Systems Consortium (ISC) has announced that it would get involved in the growing market for DNS reputation data by creating standard mechanisms for reputation providers to send data to people who run recursive nameservers.  The standard is called DNS Response Policy Zones (RPZ) and will be implemented as extensions to BIND, the most popular DNS server software in use today. (ISC publishes and maintains the BIND codebase.)  These RPZ’s, says ISC’s Paul Vixie, would allow “cooperating good guys to provide and consume reputation information about domain names.”  Note that ISC has also definitively announced it is only providing a standard and will not, at any time, be distributing any reputation data itself.  Since the announcement however, there has been a lot of passion from people debating the desirability of the mere "existence" of a mechanism like the RPZ’s on multiple blogs that cover this sort of thing (here and here, for example).

 

What those impassioned netizens have missed though is that RPZ's of some form have been with us for years and that debate is long over.  SURBL, Spamhaus, OpenDNS, IID, and many, many others have been providing domain reputation services that can be used at the DNS resolver level (if desired) for years now.  A large number of enterprises (and even ISP's) create their own custom block lists of domain names, and implement them either in DNS and/or at the firewall to protect their networks.  Sometimes that even extends to the TLD level—for instance, a lot of enterprises block all of a TLD like .RU or .CN as a matter of policy.  Some governments routinely block or reroute domains to "protect" their citizens.

What ISC has done is create a standard way for people running resolvers to incorporate data from sources of their choosing, making it possible for anyone using BIND to easily choose a list(s) they like and use it to protect the users of their resolvers.  Those could be many, and vary depending upon the nature of the networks and users that use those resolvers.  For example, for a highly sensitive critical infrastructure environment, a network security officer may want to implement a policy that blocks entire TLDs, any domain reported as being malicious or compromised, and domains on hosts they've tracked trying to penetrate their networks from being resolved by machines on that network.  That same officer may choose a wide-open resolver for the public access network they run, and a "malware domain blocked" resolver for their employee network.  That's just standard risk-assessment and implementation of security policies.

And yes, this kind of activity happens today!  Lots of folks out there are using DNS level blocking in proprietary resolver solutions to stop malware communications, prevent employees from visiting phishing sites, and implement other aspects of their security policies.  Interestingly, the debates that Paul’s announcement spurred have largely concentrated on port 80 resolution for the most part (web).  The beauty of using the DNS as a filtering tool is that malware and other undesirable activities happen over almost any port, so you can address all attacks at this level—of course, if appropriate.  That way your employees’ machines can't leak data to a keylogger C&C, be part of the Conficker network, or anything else that can be quantified and blocked out via the DNS.  Of course, if you want to just block port 80 traffic, products/services like WebSense, NetNanny and others routinely block large swaths of domains based on their content type (yep, just like the anti-spam vendors blocking port 25 traffic) so there's yet another example of why the "existence of domain reputation lists" issue is moot.

So given the existence of these kinds of lists as a fact, the thing that's really at issue here is whether ISC's solution is a good one, both technically and as a way to create a better, more open marketplace for reputation services.  The current solution set of proprietary ratings, kludged extensions, custom resolvers, and non-standard reporting by vendors, internal sensors, and data sharing partners makes it difficult for people running resolvers to evaluate reputation data quality and efficacy for their own purposes.  I applaud ISC for attempting to create a standard we can all look at and evaluate for whether or not it works, and potentially brings order to a rather chaotic marketplace.  In fact, I'd venture to say that by creating such a standard, you're much more likely to see better accountability out of folks supplying such data.  Whenever you can compare things side-by-side, you get a better understanding of who's doing a better job.  That can also lead to far better transparency by the way, for those worried about mysterious players working in the shadows to “control the Internet.”

I do have some concerns/questions about the scalability of the ISC approach and would like to see some standardizations of how reputation is actually reported.  I think that's a far more fruitful topic for debate rather than should such lists exist at all.  That ship has sailed.  Deciding what this marketplace should look like, standards employed, implementation issues, and how it operates are of great interest to me.  I think talks about standards, best practices, feedback, and "governance" would be beneficial at this point in time.