[DNSfirewalls] rpz firewall + whitelisting

[m3047]

Lee,

For better or worse, response policy zones are DNS /zones/. This has use 
cases outside of blocking something. For one thing the domains in an RPZ 
can be managed like the contents of a zone; you're seeing this as a 
negative at the moment. The RPZ can be queried directly (DNS is an awesome 
key/value store in the right environment); RPZs can be managed within the 
DNS ecosystem like other zones.

I don't know that I've ever seen a formal and unambiguous definition of a 
"(BIND) Zone File". I know I informally tried to get some of Mockapetris' 
language in the RFC edited in the BIND ARM without success. But mostly it 
seems to work for people.

The format reflects architectural bias from current and envisioned 
implementations of the time. DNS is a distributed tree thingy, with no 
single entity having actual control over everything but with delegated 
authority.

Axiomatically there is only one correct representation of the zone 
functionally speaking.

There have been a number of zone file maintaining projects / products over 
the years. But it might be better to dispense with the notion of 
maintaining the zone /file/ and just focus on the /zone/ (dynamic updates, 
or a database backend; what Vixie said, I personally use a Perl script to 
do dynamic updates). I don't have any recommendations. But I'd invite you 
to find one that does what you want, or that you can fork or send a pull 
request for, and come back here and ask for feedback / assistance: I'd 
love to hear about what you find! Personally I'd prefer Python or Go, I 
used to do a lot of Perl, and I'd find C or Rust to be odd choices; but 
really anything but Java. :-p

It's a conceptual impedance mismatch: the hardware programming manual may 
say you can get some result by writing to a register or address, but any 
way you accomplish it in C is going to be a kludge (notwithstanding 
there's a lot of it going around).

On Wed, 28 Aug 2019, Lee wrote:

> [...]
> For the record, my guesses about how rpz works continues at 100% wrong:
> [...]
>  response-policy { zone "rpz.white"; zone "rpz.black" log yes; }
> [...]
> bcbsks.com.102.112.2o7.net CNAME .
> ; bcbsks.com.102.112.2o7.net CNAME rpz-passthru.
> ; === end ===
>
> and the only difference in the results is that
> bcbsks.com.102.112.2o7.net is also blocked

1) You've got two RPZs, in order of precedence rpz.white and rpz.black [1]

2) "CNAME ." is the idiom which returns NXDOMAIN; "rpz-passthru" is the
    idiom which leaves a query unmolested.

3) In the rpz.black you're declaring *.2o7.net as NXDOMAIN; nothing below
    that is touched (no empty nonterminals). In rpz.white you're declaring
    bcbsks.com.102.112.2o7.net passthru.

*) com.102.112.207.net comes back as NXDOMAIN

*) bcbsks.com.102.112.2o7.net resolves

4) You change the rule in rpz.white for bcbsks.com.102.112.2o7.net to
    NXDOMAIN.

*) bcbsks.com.102.112.2o7.net comes back as NXDOMAIN

You shouldn't do #4. ;-) Questions:

Why is bcbsks.com.102.112.2o7.net blocked? Because you blocked it. Even if 
you just commented out the rule in rpz.white, the wildcard in rpz.black 
would still catch it.

Why is com.102.112.2o7.net (still) blocked? Because you blocked it.

But doesn't declaring bcbsks.com.102.112.2o7.net create empty 
nonterminals, regardless of what the policy attached to it is? Yes it 
does. I'm not testing with an exact replica of your zones, but I'll wager 
that net.rpz.black is an empty nonterminal.

Why does the impact of empty nonterminals differ depending on which zone I 
declare the domain in? In rpz.black you have an active (wildcard) context.

Best regards...

--

Fred Morris

--

[1] You've declared two TLDs, .black and .white. Some of us stubbornly use 
personal network TLDs and build our network defenses accordingly; sane and 
pragmatic people tend to want to declare under namespace they control.