Home / server / Questions / 129897
In Process
syn-
Asked: 2010-04-07 12:36:15 +0800 CST

Providing DNS redirection to honeypot server for known bad domains

  • 772

Currently running BIND on RHEL 5.4 and am looking for a more efficient manner of providing DNS redirection to a honeypot server for a large (30,000+) list of forbidden domains.

Our current solution for this requirement is to include a file containing a zone master declaration for each blocked domain in named.conf. Subsequently, each of these zone declarations point to the same zone file, which resolves all hosts in that domain to our honeypot servers. ...basically this allows us to capture any "phone home" attempts by malware that may infiltrate the internal systems.

The problem with this configuration is the large amount of time taken to load all 30,000+ domains as well as management of the domain list configuration file itself... if any errors creep into this file, the BIND server will fail to start, thereby making automation of the process a little frightening. So I'm looking for something more efficient and potentially less error prone.

named.conf entry:

include "blackholes.conf";

blackholes.conf entry example:

zone "bad-domain.com" IN { type master; file "/var/named/blackhole.zone"; allow-query { any; }; notify no; };

blackhole.zone entries:

$INCLUDE std.soa

@ NS ns1.ourdomain.com.
@ NS ns2.ourdomain.com.
@ NS ns3.ourdomain.com.

                       IN            A                192.168.0.99
*                      IN            A                192.168.0.99

domain-name-system blackhole honeypot redirection

4 Answers

  1. Haven't found a good way to eliminate having to load each domain in its own zone, but using the following rndc command eliminates the concern of causing the server to fail in the event of a malformed entry. 

    rndc reconfig

    A full on server restart/reload will still result in a failure to start.

    • 1

  2. Edit : Sorry I don't read well your question. I propose the same things as you. Maybe You can include a file generated from a database ?

    I have a dropDomain file with :

    $TTL 3600       ; 1 hour
@               IN SOA  xxxxxxxx.fr. dnsmaster.xxxxxxxx.fr. (
                2009112001 ; serial 20yymmdd+nn
                                900        ; refresh (15 minutes)
                                600        ; retry (10 minutes)
                                86400      ; expire (1 day)
                                3600       ; minimum (1 hour)
                                )
                        NS      dns1.xxxxxxxx.fr.
                        NS      dns2.xxxxxxxx.fr.
                        MX      0       smtp.xxxxxxx.fr.

*                       A       127.0.0.1

; vim:filetype=bindzone

    Then I just add the domains in my list in named.conf.local :

    # Master pour les zones que l'on ne veut plus resoudre (pirates, virus, prise en main a distance...)
zone "zzzzzzz.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };
zone "yyyyyyy.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };
zone "ttttttt.com" { type master; file "/etc/bind/dropDomain.tld"; allow-query { any; }; };

    I don't need to define it in the zone file, it is generic.

    • 0

  3. In theory you can avoid the slow load time by making your blackhole list part of your root hints file (e.g. via $INCLUDE) and then changing that file from being a hint to a master. That last bit is necessary to prevent your server from download the real root hints from the internet.

    e.g. in named.ca:

    a.root-servers.net.  IN A ....
m.root-servers.net.  IN A ....
$INCLUDE blackhole.zone

    and then in blackhole.zone:

    $ORIGIN example.com.
@ IN 192.168.0.99
* IN 192.168.0.99

$ORIGIN example.net.
@ IN 192.168.0.99
* IN 192.168.0.99

; ad-infinitum

    There's no real need for NS records or separate zone statements for each blackholed zone - you're effectively inserting fake authoritative data into your local copy of the root zone. Just make sure you download the real root zone occasionally!

    Then just go with @syn's suggestion of running named-checkzone before each reload and/or restart.

    NB: I haven't tested this.

    • 0

  4. Have you considered an alternative to BIND? I haven't used any yet, but there are MySQL driven alternatives with web frontends such as PowerDNS with Poweradmin. This might make updates less error prone and risky. PowerDNS even has a tool to convert a BIND zone file to SQL for migration.

    Also, can I ask if that list is publicly available? I'm very interested in this myself.

    • 0