DNS block lists & why you NEED to use them!

We all know about IPBL’s or “IP Block Lists” (a.k.a IP Blackhole Lists).  They’re great right?  What about applying the same logic to DNS?

DNS works like this:

On your computing device you browse to yahoo.com and your computing device says…hey, I don’t happen to know what yahoo.com is…hey DNS server…what IP address is yahoo.com?  If your immediate DNS server knows it says, yahoo.com is and your computing devices shows the website with the corresponding content.  If it doesn’t know, it should pass the request up the chain to the forwarding DNS server like your ISP or even further up the chain to what’s called “root name servers” asking each server the question…what IP address is yahoo.com – for the answer…what IP address maps to yahoo.com.  That’s what DNS does…converts easily remembered names like yahoo.com into their corresponding IP address so your computing device can present you the page and it does it in seconds.

It’s kind of like how operators worked wayyyy…wayyyy back in the day…operator, I’d like the number for ATT Customer service, “One moment pahlease”…and they’d connect you…eventually.  It then moved to 411 (do you remember 411?).  411 began in 1930, they had these cool switchboards an operator would physically switch your call to and from (more here) and is where we get the shorthand I grew up with when you need more information.  You ask someone for the 411 on something.  In our current contemporary age, we now search online for everything using search engines, digital personal assistants from big brother like Google, Apple, Amazon and Micro$oft but even they still have an operator / 411 type of service behind the scenes called DNS which is what we have today.  DNS is not going anywhere soon.

So this is where a DNSBL comes in handy in the security stack.  I went into my file archive and pulled out an old virus that is kicked off on your Windows PC with a javascript file (.js).  There are LOTS of ways you can get a virus but this one came in as a “.zip” attachment via email, some fake invoice or something similar and it attempts to get the end user (you) to open and execute it.  This is somewhat hard to do because it’s a two step process, you have to unzip the file then click on this javascript file that looks goofy to most users.  This particular version that I have a sample of wasn’t a widely successful virus but is still useful.

* Note:  If you’re not blocking the “.zip” attachment on your mail server you’re in for some pain – block it today!

Here are contents of the file that are interesting to what we’re doing with DNSBL’s:

var xLr4 = “http://”;
var xPSn0 = new Array();
xPSn0.push(xLr4 + “smgonline[.]ca/0bfcm13c”);
xPSn0.push(xLr4 + “sitivisibili[.]it/3keepsdhpw”);
xPSn0.push(xLr4 + “whitecard[.]jp/hdtkpfyan”);
xPSn0.push(xLr4 + “wuxfit[.]de/hq1on”);
xPSn0.push(xLr4 + “shingo[.]ca/4bl3yqszl”);

Notice the “var” – “http://“.  The following lines are ALL varying types of URL’s so if you put the “var” and the “push” together you’d get a result like:  http://smgonline[.]ca with a subfolder containing a package (file, more scripts, downloaded exe, whatever the attacker might want you to download or see, etc).

Notice all the URL’s though:

smgonline[.]ca <– Canadian

…you have Italy, Japan, Germany also.

This particular file has these characteristics if run (reference):










Notice what it does:  It “Performs some HTTP requests”, we noted that above to the various domain names that must be resolved via DNS queries…what domain is smgonline[.]ca…oh, here’s the IP address unsuspecting computer users…about to be hacked end users.  The IP address is  It then delays the time in which it does this, it tries to modify Windows functions, it tries to steal private information from your Internet browser and then installs in your Windows startup so it can come back to life after a reboot.

Lets assume for a moment that your Anti-Virus didn’t know about this malicious file yet or the way it behaves (which does happen).  If you did a few more things on the edge of your network like we do at the firewall with both IP and DNS blocking you’d have saved this person from having their information stolen.  If you’re a business…your information is everything, privacy is key and the protection of your network is paramount!

At the time I wrote this each domain resolved to these addresses:

smgonline[.]ca ->

sitivisibili[.]it ->

whitecard[.]jp -> doesn’t resolve to an IP

wuxfit[.]de ->

shingo[.]ca ->

Now; if you do DNSBL (or Geo IP block listing [aka country blocking] or IP blocking), or  you block the specific domains so smgonline[.]ca resolves to  nothing meaningful (, or some blocked interface on your firewall), or you block the “TLD“, aka “Top Level Domain” (.ca, .it, .de, .jp, etc)…the above requests will be rejected / blocked / denied and will not affect the end user.  It won’t affect them even if they inadvertently execute that java script file because the resources it attempts to get online won’t go anywhere!

The more effective low maintenance option is to block the TLD’s as noted but you can also block the actual domain names as also mentioned.  There are many lists which block those domains or you can make and maintain your own like we do.  We prefer blocking TLD’s that aren’t meaningful to our clients.

If you don’t block the TLD or the domain name you’ll actually be able to see and retrieve the resources at smgonline[.]ca and pull down or push up anything they want you to.  You’ll be hacked, you may or may not know it if this happens and your Anti-Virus suite may or may not know about it.

If you block the TLD as you should, the program won’t be able to resolve ANY “*.ca” domain name.  Furthermore, if you block the actual domain via DNS “smgonline[.]ca” will resolve to a meaningless address essentially blocking the activity of the malicious file attempting to go grab more malicious files.  Instead of resolving it to you’ll be “redirected” to your local machine of or a null IP address like or perhaps a blocked interface on a firewall like we do of:  We maintain a blocked interface on our firewalls so we can see the blocked traffic and track what’s blocked.  That traffic is also logged.

As a side, all those IP addresses “live” in these countries (Reference): 26496 US AS-26496-GO-DADDY-COM-LLC – GoDaddy.com, LLC, US 52030 IT SERVERPLAN-AS, IT 6724 DE STRATO STRATO AG, DE 53831 US SQUARESPACE – Squarespace, Inc., US


Hey looky there we have our ole’ friend Ho-Daddy hacker hosting extraordinaire!  That’s both a surprise and not a surprise!

One final note!  In our stack we typically do this:

  1. Country blocking (all non-US IP addresses – Geo IP blocking)
  2. DNS blocking (a number of DNSBL’s we subscribe to and custom DNSBL’s)
  3. IP blocking (over 250 aggregated IPBL’s we subscribe to then parse and custom BL’s we maintain and aggregate)

If you only had Country and IP blocking it’s possible the wouldn’t be blocked because it resolves to the US!  So does the  That’s why you need to have the DNSBL in your stack.  You want to further mitigate the attacks by malicious actors who want to steal your data!  The .de domain resolves to a US IP address as does the .ca address, 50% of the requested URL’s from this attacker would have gotten past your stack if you only implemented 2 of the 3 blocking options.  Assuming that blocking the world and only allowing your own home country (the US) could be a big mistake.  The US happens to be one of the biggest offenders in the world.  There are more hacked servers in the US than anywhere, the US is frequently a top spammer.  We’re # 1…we’re #…we’re #1…USA-USA-USA!  LULZ.

** Super special note:  To the Enterprise and “business class” people who might say…well, PFSense isn’t Enterprise or “Business Class”.  Check yourself before you wreck yourself.  Most “Enterprise” class routers don’t do DNSBL which actually makes those routers less functional, less feature rich and quite frankly…weaker.  Furthermore, you have to beg and plead with the scripting Gods (that’s me or one of my colleagues) to write the scripts to even attempt this on an “enterprise class” router like a Cisco router.  Moreover that’s the IPBL part…the “enterprise routers” don’t do DNSBL and you have to get your actual DNS server to add that functionality or use a service like OpenDNS or Comodo Secure DNS (also both good services).  Of course, we can forgive those thinned out enterprise class systems because the vendors don’t build them with beefy enough resources to push this type of work load onto them.  You know…the workload is called “security”. They wouldn’t want to over task their measly 800 Mhz processors (LULZ).  Cisco actually knows how important it is for the edge to take the brunt of an attack they just haven’t built it into their legacy non-Meraki product lines.  Their newer product Meraki line in particular is known for bogging down throughput when you turn the “security services” features on (IDS, SNORT, etc).  I love beating up Cisco because they’re actually one of the worst.  Great marketing department, poor systems.  Here’s my point…the Meraki “sizing guide” I was perusing has a “conclusion” at the end of the guide that essentially says…if you have 500 users, you better get the router that does 1000 users.  This is a flagrant misrepresentation of sizing!  They should make the 1000 user router a 500 user router and quit playing hard to get.  They know when you turn the security features on the product will need MORE resources than it has and perform poorly.  That’s when they do the ole’ bait and switch.  You’ll call them and they’ll explain the model you have doesn’t have enough horsepower to push your traffic then explain that you need to buy a different model (they all do this – Watchguard, Sonicwall, etc).  PFSense does everything a Meraki can do, faster, better, cheaper and without the licensing restraints which is a truly Enterprise Class router.  Want i7 Intel power with 32 GB or RAM?  You can!  But not with Meraki, Watchguard, Sonicwall!  Flexibility, root access, options…now that’s “Enterprise Class” and that’s PFSense!

Cisco Meraki’s sizing guides “Conclusion”:

While every network will have a unique traffic pattern, this guide highlights a few common scenarios to help you choose the right Cisco Meraki MX product for your environment. Consider planning for future growth by allocating buffer room in your firewall selection (e.g., if you currently have 550 users, choose an MX that supports 1000 users). This will ensure that you can continue enabling additional security and network features as they become available. Also considering ISP speeds are increasing 29% year over year, it is important to choose a firewall that will serve you well over many years.”

^ So the 550 user shop should buy the 1000 user MX model…how about just making the 1000 user model a 500 user model and be honest about the horsepower (or lack thereof)?  You can NOT use the MX 550 model IF you turn on security features because it will be a dirty dawg…you need to buy the 1000 user model.  Marketing experts…what can you do (?)…hope someone reads the entire document!

If you’re having security problems we can help!  Need IT engineering?  We’re available.  Supercharge your security with DNSBL’s!  No bait and switch.  We are completely open and honest here and we won’t be undersized.


Comments or questions are welcome.

* indicates required field

Leave a Reply

Your email address will not be published. Required fields are marked *