I use RPZ to blacklist some domains and my configuration looks like:

*.com A
mydomain.net A

if i query a whatever domain .com it works correctly giving me

let's dig fun.com @localhost, my reply will be:

fun.com.     5       IN      A

now let's edit the previous config and make my zone now look like:

*.com A
mydomain.net A

It's unnecessary because the master *.com should cover all the cases however I have my domains loaded by multiple sources so the list is compiled automatically and things like this can happen.

While this seems to be an harmless change and if I do dig this.fun.com @localhost it will reply again stuff like:

this.fun.com.     5       IN      A

If I now query the root domain dig fun.com @localhost I will get:

fun.com.                86400   IN      A

Like.. WHAAT? What happened here? adding this.fun.com masked out fun.com main domain from the upper omni-inclusive *.com?

Is this a wanted behaviour of bind? Did I found some kind of weird bug?

How can avoid this? Should I write a script that recurse all the domains removing the ones contained into the bigger ones? (annoying but doable - in search of better alternatives)

TL;DR: Add of a 3rd level domain in bind rpz in order to BLACKLIST IT make the 2nd level domain not follow the main FILTER resulting WHITELISTED.

  • @RuiFRibeiro this question is for you :D Apr 5, 2016 at 1:24
  • I do not understand as tagging works, as I have not received a message. Apr 5, 2016 at 3:01
  • @RuiFRibeiro probably works only if you actively replied at least once to the question, if I tag you from a brand new question the message will not be delivered. Apr 5, 2016 at 9:52

1 Answer 1


As for BIND RPZ behaviour and regexps: *.com blacklists all the DNS subdomains bellow com, however if you intend to blacklist the com root domain itself you need to add to the rpz file:


So if you do not introduce com to the rpz list, it will be resolved. What you describe is normal behaviour.

As for a RPZ blacklist parser, I recommend writing one, at least to save resources. The impact while running should be minimal, as BIND is using hashing tables, however the delay reading the RPZ table when restarting BIND is noticeable (e.g. when BIND is reading and parsing the RPZ table), and it uses slightly more memory. I have not written such a parser for now.

  • No I didn't want to blacklist com itself, it wasn't my purpouse. I blacklisted all the .com domains resolving right? Then I have another entry added automatically that claims this.fun.com to resolve and this is ok. But all of sudden the main domain fun.com or www.fun.com and everything.fun.com start to resolve right instead of continue working properly as before giving tl;dr: the addon of this.fun.com break everything, all the root of .fun.com 3d level domains and 2nd level fun.com itself appears like WHITELISTED, and this is a really UNWANTED behaviour Apr 5, 2016 at 9:45
  • Also edited the question for better clarification. Apr 5, 2016 at 9:51
  • I will try to understand it better later on. I am both attending a conference in the next few days, and providing training in a FreeRadius workshop, so it might take a while to come test this and come back to you. I recommend increasing the BIND log level and running it as non-daemon/debug mode to trace this. It might have something to do with their hash list creation. Order in the rpz file might make a difference. Apr 5, 2016 at 10:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .