0

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

*.com A 127.0.0.1
mydomain.net A 127.0.0.1

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

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

;; ANSWER SECTION:
fun.com.     5       IN      A       127.0.0.1

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

*.com A 127.0.0.1
mydomain.net A 127.0.0.1
this.fun.com 127.0.0.1

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:

;; ANSWER SECTION:
this.fun.com.     5       IN      A       127.0.0.1

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

;; ANSWER SECTION:
fun.com.                86400   IN      A       209.61.131.188

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.

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
user3450548
  • 2,868

1 Answers1

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:

com

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.

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
  • No I didn't want to blacklist com itself, it wasn't my purpouse. I blacklisted all the .com domains resolving 127.0.0.1 right? Then I have another entry added automatically that claims this.fun.com to resolve 127.0.0.1 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 127.0.0.1. 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 – user3450548 Apr 05 '16 at 09:45
  • Also edited the question for better clarification. – user3450548 Apr 05 '16 at 09: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. – Rui F Ribeiro Apr 05 '16 at 10:19