Items 0

DNS Domain Blacklisting and Sinkhole for Microsoft DNS & BIND

You can import a list of malicious or undesired domains that you need to Block, Redirect, Monitor, and/or Report with your current DNS Servers; whether your DNS Server is an Active-Directory Integrated DNS, Standalone Microsoft DNS Server, or Unix BIND Server.

You can as well create a custom response of the requested domains that you want to control access to; such that you can identify the devices that are trying to communicate with the domains and URLs you want to monitor or control access to. Besides, you can make a use of your current network security solutions such as IPS, IDS, Honeypot, Next Generation Firewall, SIEM, or simply just log it with syslog or packet capture tools.  

Briefly; when a computer requests a URL or access to one of these undesired domains by sending a DNS query request, which could be even triggered by a malware/spyware, a customized response is sent by your DNS Server, thus enforcing and controlling access to the listed domains. 

Introduction

One of the essential and critical techniques for mitigating, identifying, and preventing malwares/spywares among users is through the use of DNS, which can be configured with custom/synthesized responses such as redirection, blocking, and reporting.

Most commonly this will be achieve by importing the blacklisted or undesired domains into an Internal DNS Server. It can even be implemented on a DNS Caching Server, which will act as Authoritative DNS for only the undesired / blacklisted domains and Zones. Yet using a DNS Caching Server in this case will prevent you from identifying the source IP addresses and devices sending the DNS query requests. 

The DNS Server, which will be used, could also be configured as a “primary” or “master” resolver for domains associated with malicious malware, spyware, botnets, or any other domains that you need to control.

The DNS server will be “Authoritative” for these zones, which will answer the query instead of forwarding or recursion them with other DNS servers.


Once the domains that you need to control are added to your DNS Server, the requested clients will start receiving a custom response that you have specified.

These custom responses can be resolved to IP addresses that relates to one of the following:

1) A loopback address (127.0.0.1) or 0.0.0.0
2) An internal Web Portal or a Wall Garden configured to “redirect” all web requests to a warning web page.

3) An existing security device such as an IPS, IDS, Next-Generation Firewall, Honeypot….etc

4) A reporting solution such as a logging system, packet analyzer, SIEM, etc such that it will identify the device trying to access the listed domains.  

The last two options have the added advantage of logging the requesting device for inspection as well as enable an IPS, NG-FW, or IDS system to continue monitoring suspension traffic.

This is also commonly known as DNS RPZ (Response Policy Zone).

 

DNS RPZ Overview

 

DNS RPZ is a technology developed by ISC available since Bind version 9.8. Network administrators can use DNS RPZ to essentially stop malware-infected hosts from reaching their command and control (C&C) servers by blocking DNS resolution to known malicious hosts and sites. This effectively turns a recursive DNS server into a DNS firewall. In fact, many people refer to DNS RPZ as the “DNS Firewall.” Various ISPs are testing and implementing this to provide additional protection to their customers.

Note: DNS RPZ will block DNS resolution, machines connecting to the C&C via IP address will not be blocked.

The following figure provides an overview of how DNS RPZ works.

RPZ-overview1

In this figure, a client performs a few DNS queries. It first queries for a good domain (example.com) and the corporate server receives the normal DNS response from the upstream DNS server. This client also queries for a malicious domain (malicious-domain.com) and also for a domain called someotherwebsite.com. Enterprises can have their own (local) DNS RPZ to block any other domains/websites that are not allowed because of corporate policies. In this example the corporate DNS server has a local RPZ configured to block “someotherwebsite.com” and it also receives information about “malicious-domain.com” from the external DNS RPZ. There are organizations such as Spamhaus.org and SURBL that provide RPZ services that organizations can subscribe to.

Note: DNS zone transfers can be full transfers (AXFR) and incremental (IXFR). AXFR zone transfers are defined in RFC 5936 and IXFR is defined in RFC 1995.

The “reputation-based” zones, via RPZ responses, will send back either non existent domain (NXDOMAIN) or a pointer to a “walled-garden” where you can point the user to clean up their workstation or direct them through any other specific instructions.