[dns-operations] A DNS and network security forced marriage

Joe St Sauver joe at oregon.uoregon.edu
Fri Mar 12 18:16:30 UTC 2010

Andrew commented:

#First, it seems to me that your real problem is that you have a lot of
#botnet difficulty.  That seems to be something that would be better
#tackled head on.  But I realise it's hard to do, and with limited
#staff nearly impossible.

The problems associated with mitigating bot'd hosts are indeed complex,
particularly since end users really have no single central resource to
turn to for help. That's why I delivered the talk, "We Need a Cyber CDC
or Cyber World Health Organization" at the 2007 APWG E-Crime Summit, see
http://www.uoregon.edu/~joe/ecrime-summit/ecrime-summit.pdf (or .ppt)

One aspect of that complexity is that much of the spam we see in the United 
States doesn't come from within the United States, so we not only need
a way to help local users avoid getting 0wn3d (or to recover from
infestation if they do get hit), but we also need a way to help users 
in Poland and Vietnam and Brazil and Mexico and Ghana and every other 
connected point on the globe... we need global leadership to tackle the
problem of botted hosts, and global leadership is doubly difficult when
the economy is still struggling.

#Fourth, it's by no means impossible for the botnet infections to adapt
#by delivering resolution some other way.  The next step will be to
#block port 53 and force everything to use your nameserver, and soon
#responsible use of the network by advanced users will be nearly

Attempting to control botnets by controlling botnet C&C DNS resolution
is really a "control the source" strategy, and it can potentially work.
As an alternative approach, however, consider a "control the destination" 

Note that most botnets are used to spam, and the vast majority of spam 
relies on driving users to spamvertised web sites to purchase products 
or services.

The ubiquity of that mechanism is reflected in the emergence of URI 
and/or domain name oriented anti-spam block lists such as SURBL, URIBL, 
and now Spamhaus's new DBL.

URI and/or domain name oriented anti-spam lists use block listings to 
negatively score spamvertised messages, resulting in those messages
being blocked, spam foldered, or negatively tagged. 

However, you can use DNS to attack spamvertised domains in an 
alternative way. 

Specifically, by targeting resolution of the *spamvertised website*
domains, or, better yet, the relatively limited number of authoritative 
name servers that support those spamvertised domains, ISPs have the 
potential to directly impact the spammer's bottom line by interdicting 
customer visits to the spamvertised web sites. Spam may still get
delivered, but users can't successfully click through to the 
spamvertised web sites. If users can't click through to the 
spamvertised web sites, spammers don't make money.

Is this the FUSSP? No, nothing is. But it does have the potential to 
dramatically reduce the attractiveness of spamming a particular ISP, 
and that may be enough to make the spammer target some other ISP for 
their next spam run. ("I don't need to outrun the bear, I just need
to outrun at least some of the other campers")

I should also mention that that there are already a number of ISPs 
that have implemented this strategy, this is not something novel that
I've just personally come up with -- ISPs do it because it works,
is cheap to implement, and can easily accomodate users who want to 
opt out. 

That is, if an ISP's users *are* hell-bent on accessing a particular 
spamvertsed web site (for whatever reason -- maybe they want to buy
spamvertised pillz, maybe they want to do research on spamvertised
domains, whatever), ISPs can allow users the option of using an 
alternative open recursive resolver, such as Google's public resolver
at, instead of using the ISP's default spam-filtered resolvers 
(but we know that the vast majority of users won't bother to change 
the name servers they've been given).



Joe St Sauver (joe at oregon.uoregon.edu)
Disclaimer: all opinions strictly my own

More information about the dns-operations mailing list