Sam Trenholme's webpage
Support this website

MaraDNS 3.5.0035


December 28 2022

To end 2022, I have released MaraDNS 3.5.0035. This release adds support for large block lists which use little memory.

==Blocking hosts==

For a couple of years now, MaraDNS has had support for block lists. For example, let us suppose we want to block some domains. We have been able to do it like this:

ip4 = {}
ip4[""] = "X"
ip4[""] = "X"
ip4[""] = "X"

(As an aside, this will block both the IPv4 and IPv6 forms of these names)

Once this is set up, it will not be possible to resolve, say, using Deadwood.

This works, but there’s a problem: It uses too much memory per entry.

Over at there are a number of large block lists. One of which, the one for blocking pornographic content, has some 207,723 entries in it. Loading this in to Deadwood using the ip4 method uses some 237 megabytes or so of memory. In comparison, if we use a block hash (see below), the same list only takes up 9.5 megabytes of memory.

==Block Hash support==

In otder to be able to block a large number of hosts while using minimal memory, MaraDNS 3.5.0035 now has block hash support.

The process for adding a block hash to Deadwood is as follows:

  • We use a new program, blockHashMake, to create a “block hash file”:

$ cat | blockHashMake badHosts.bin

(^D means to hit Ctrl + D at the same time to finish the list; note that this is for *NIX systems and Windows users will probably be better off with the Windows version which includes a pre-built block hash file)

  • We place the block hash file in the Deadwood home directory (usually, /etc/deadwood).
  • We then tell Deadwood to read the block hash file. Put this in /etc/dwood3rc:

blocked_hosts_hash_file = "badHosts.bin"

Note that, for security reasons, every time a block hash file is made, a different file is generated. If, for some reason, it is desirable to have a block hash file be same for a given list of hosts every time, one can generate a block hash file as follows:

$ cat | blockHashMake badHosts.bin 0

And read it as follows:

blocked_hosts_hash_file = "badHosts.bin"
allow_block_hash_zero_key = 1

There is a security risk if we allow a blocked hosts file to have a 0 key: An attacker with access to a recursive instance of Deadwood could have Deadwood use more resources than necessary if they know the block hash file being used. Since the block hash file is read only, hash flooding attacks are not possible, but an attacker could form queries which use more resources to resolve as not being present in the block hash.

Deadwood should never be an open recursor and this attack is limited in scope. But be aware of the risks before setting this parameter to 1.

Comments for blog entries can be seen in the forum.