Home / Blogs

Using Domain Filtering To Effect IP Address Filtering

In Taking Back The DNS I described new technology in ISC BIND as of Version 9.8.0 that allows a recursive server operator to import DNS filtering rules in what ISC hopes will become the standard interchange format for DNS policy information. Later I had to decry the possible use of this technology for mandated content blocking such as might soon be the law of the land in my country. I’m a guest at MAAWG this week in San Francisco and one of the most useful hallway discussions I’ve been in so far was about the Spamhaus DROP list.

The Spamhaus people do a lot of reputation research and some of us subscribe to their online services in a way that causes us to reject e-mail traffic from network neighborhoods of purportedly low reputation. This is a dangerous way to operate one’s network, since any mistake on Spamhaus’s part could cause us to reject nonmalicious traffic. As the creator of the first Realtime Blackhole List (RBL) back at MAPS in the mid 1990’s I am well acquainted with both the risks and benefits. For my home office those risks and benefits are well aligned. My long term use of the Spamhaus SBL has helped me reject a lot of e-mail spam that would otherwise have landed in my family’s inboxes, but as I add more communications tools (not just e-mail any more) I find myself wishing for a reputation tool that is not e-mail specific. The Spamhaus DROP list is such a tool, it’s a list of networks that Spamhaus recommends us Do Not Route or Peer (so, D-R-O-P.) However, wiring something like the DROP into my router or firewall is more work than I’m willing to do.

The Shoe Drops

Today I realized that the Response Policy Zone (RPZ) DNS filtering technology in BIND9 (9.8.0) could be used to represent the Spamhaus DROP list. The effect will simply be that various domain names return a fake NXDOMAIN result (this means, “there’s no such place”) if the address that DNS would otherwise return is listed on the Spamhaus DROP. That would prevent my family from accidentally visiting those locations with a web browser or other communications tool. Freakishly enough it will also prevent my e-mail server from accepting e-mail from those locations since my e-mail server will not accept an e-mail message if it cannot successfully look up all of the domain names in the envelope and header.

So I took a copy of the Spamhaus DROP list, wrote a short Perl script to translate it from “lasso” format into “RPZ” format, and looked for some test data. The ISC Passive DNS system gave me a long list of domain names whose address records fell inside one of the entries I saw in the middle of the Spamhaus DROP, so I looked up each one of these to find one that has not yet been killed by its registrar or abandoned by its registrant—in other words something still living that my RPZ could kill off. Testing… testing… it works! There’s no way to do forward or reverse DNS at my house any more for any address listed on the Spamhaus DROP.

Example Data

Since the Spamhaus DROP is publically and freely available, there’s no secrecy around the data I used. Still, it bothers me to name names (and to name addresses) since I have no personal knowledge of any misdeeds by the operator of the domain names or IP addresses involved. So, I’m going to anonymize here. The input data from the Spamhaus DROP file looks like this:

yyy.xxx.212.0/22 ; SBLzzzzz

The output data from my Perl script, in RPZ format now, looks like this:

$ORIGIN dns-policy.example.com.
22.0.212.xxx.yyy.rpz-ip CNAME .
*.212.xxx.yyy.in-addr.arpa CNAME .
*.213.xxx.yyy.in-addr.arpa CNAME .
*.214.xxx.yyy.in-addr.arpa CNAME .
*.215.xxx.yyy.in-addr.arpa CNAME .

I’ve sent the Perl script to Spamhaus in case they wish to publish it along with their DROP list.


Because of the ease with which criminals can “frequency hop” among many possible IP addresses, I’ve been rethinking my old position on IP source address based reputation systems. Criminals will always need identifiers for their traffic and content and there’s a vibrant market of providers who want to make those identifiers as cheap and plentiful as possible—but more and more I think domain identifiers are going to be where the reputation industry puts most of their research effort. Still, I find it heartening that all of my family’s communication tools rely on accurate DNS for every IP address they see—and so by using a domain-based filtering approach I can achieve an IP address based filtering result.

By Paul Vixie, VP and Distinguished Engineer, AWS Security

Dr. Paul Vixie is the CEO of Farsight Security. He previously served as President, Chairman and Founder of Internet Systems Consortium (ISC), as President of MAPS, PAIX and MIBH, as CTO of Abovenet/MFN, and on the board of several for-profit and non-profit companies. He served on the ARIN Board of Trustees from 2005 to 2013, and as Chairman in 2008 and 2009. Vixie is a founding member of ICANN Root Server System Advisory Committee (RSSAC) and ICANN Security and Stability Advisory Committee (SSAC).

Visit Page

Filed Under


Implications in an IPv6 world? Richard Donaldson  –  Jun 9, 2011 4:19 PM

Paul - how is your view further substantiated (or not) in an IPv6 world where IPs are nearly limitless?  What changes do you foresee with respect to spam filtering in this world?

Re: Implications in an IPv6 world? Paul Vixie  –  Jun 9, 2011 10:13 PM

Paul - how is your view further substantiated (or not) in an IPv6 world where IPs are nearly limitless?  What changes do you foresee with respect to spam filtering in this world?

I can share three perspectives on this.

First, in an IPv6 world we’ll see even more frequency hopping by criminals.  The bottom 64 bits of an Ethernet connected IPv6 host are generally computed using EUI64 and tend to look a lot like MAC addresses, but they can be anything, and we will indeed see everything—malware will rewrite these bits to evade detection and/or filtering.  That means effective filtering will be done at the /64 level—whole Ethernet segments will be added to the “rejection list” even if it’s a shared Ethernet having a mix of infected and non-injected hosts (or malicious and non-malicious users).  I’m not advocating this, just observing the ways in which victims will protect themselves.  IPv6 is coming to the fore just as the Internet population is increasingly willing to inflict and absorb collateral losses in order to prevent even more targetted and damaging attacks.  (For a non-Internet example, see the PATRIOT act in my country.)

Second, criminals need domain names, both to anchor their content and to connect their traffic to their content.  The use of raw IP addresses in places where domain names would usually be seen (like in URL’s, for example, make both content and traffic look “spammy” and criminals want to avoid looking spammy.  Of course there’s a market both broad and deep for providing domain names so cheap that they can be thrown away after a single hour of use, so criminals who need domain names can get all they need.  That’s why I developed the Response Policy Zone technology that will let information security providers kill these cheap domains as fast as the criminals can create them.  If a criminal is using DNS then we should be able to shut them down or at least keep them contained even when they migrate to IPv6 which as you point out has a vastly larger pool of addresses than IPv4.

Third, I think there’s an opportunity to uplevel our e-mail reputation game during the transition from IPv4 to IPv6.  In IPv4 the e-mail reputation industry has mostly been using the “realtime blackhole list” (RBL) technology that we developed at MAPS back in the mid 1990’s but it’s clear that spammers know how to get around this kind of blocking.  To the extent that it remains effective or useful to reject incoming traffic based on IP source address, your point about IPv6 is very well taken, we will need something better than dynamic lists of bad-reputation networks and hosts.  I wrote down some thoughts the other day about using Two Stage Filtering for IPv6 Electronic Mail and it’s possible that this same approach could be adapted for other types of traffic not just e-mail.

Thanks for this interesting question.

by popular demand, here's the perl script i mentioned Paul Vixie  –  Jun 9, 2011 10:54 PM

To convert from Spamhaus DROP “lasso” format into RPZ format you will need a conversion utility similar to this.

Team Cymru "fullbogons" list Paul Vixie  –  Jun 11, 2011 12:29 AM

Update: I added the Team Cymru fullbogons list to my personal RPZ using the same Perl conversion script that worked for the Spamhaus DROP and it works fine.  I spoke to Rob Thomas of Team Cymru who thought it a fine idea.  He agrees with me that spammers are unlikely to use this address space to source spam, yet it provides another layer of protection against such shenanigans.  As with any living list, we both strongly recommend you automate the updates to avoid blocking legitimate traffic.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byDNIB.com


Sponsored byVerisign

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global