Need help on RPZ sever, bit urgent

[Bob Harold]

On Thu, Aug 9, 2018 at 9:31 AM Blason R <blason16 at gmail.com> wrote:

> For example this one.
>
> 18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
> 0351dag.com. (29)
> 18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
> 0/1/0 (102)
>

With RPZ, the name is looked up normally first, and only if there is an
answer, is RPZ invoked.  If it gets NXDOMAIN or some error, it returns that
and does not use RPZ.
If that is not what you want, then you probably want to set the option:
    qname-wait-recurse no;

-- 
Bob Harold




>
> On Thu, Aug 9, 2018 at 6:59 PM Blason R <blason16 at gmail.com> wrote:
>
>> Hi Bind-Users,
>>
>> I would really appreciate if someone can help me understanding my issue
>> with BIND RPZ server?
>>
>> I have one windows server say 192.168.1.42 and then RPZ server with
>> 192.168.1.179. I noticed that there are certain domains which are not
>> getting resolved from end users.
>>
>> Ideally since those end user has 192.168.1.42 DNS Server set and has
>> forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
>>
>> But certain domains from my response-policy are even though wall-gardened
>> those are being catered as NXdomain.
>>
>> Anything I am missing pertaining to RPZ?
>>
>> Or if I am querying all those domains directly to RPZ server then I am
>> getting proper answer. This issue is noticed when I have forwarder server
>> is between
>>
>> options {
>>         version "test";
>>         allow-query     { localhost;subnets; };
>>         directory "/var/cache/bind";
>>         recursion yes;
>>         querylog yes;
>>         forwarders {
>>                 1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
>>          };
>> //      dnssec-validation auto;
>>         request-ixfr yes;
>>         auth-nxdomain no;    # conform to RFC1035
>> //      listen-on-v6 { any; };
>>         listen-on port 53 { any; };
>>         listen-on port 15455 {any;};
>>         response-policy { zone "whitelist.allow" policy passthru;
>>                         zone "wg.block";
>>                         zone "bad.trap";
>>                         zone "block.tld";
>>                         zone "ransomwareips.block";  };
>> };
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180809/e5d2cce6/attachment.html>