Need help on RPZ sever, bit urgent

Blason R blason16 at gmail.com
Fri Aug 10 08:36:34 UTC 2018


Hello All,

I have been debugging my issue from last 30+ hrs without luck and dang its
something related to forwarding. Again here is my quick scenario

I have Windows DNS Server 192.168.1.42 Has Forwarder set to 192.168.1.179
[BIND/RPZ]

Now certain domains when queried from end user e.g 192.168.1.100 has DNS
set to  192.168.1.42 does not get resolved at all. While I troubleshooting
I observed that may be 192.168.1.42 has got root zone "." and is trying to
resolve locally instead of forwarding. I noticed this issue is happening
randomly with any domains but mostly it observed for .com and .net domain
entries.

Again I tried replacing 192.168.1.42 with Linux BIND server and its same
behavior so I don't think its related with Windows.

I want all other queries should strictly forward to my RPZ forwarding
server. How do I do that can someone help me in troubleshooting? I can
provide the logs and config.

Or if someone has a similar setup can try simulating at their end and
confirm, plz?



On Fri, Aug 10, 2018 at 1:17 PM Blason R <blason16 at gmail.com> wrote:

> Nah I dont think that is the answer since you need a termination after
> clause.
>
>
> Thanks and Regards,
> Lionel F
>
> On Fri, Aug 10, 2018 at 12:58 PM Vadim Pavlov <pvm_job at mail.ru> wrote:
>
>> Should be:
>>
>> response-policy {zone "whitelist.allow" policy passthru;
>>                         zone "malware.trap";
>>                         zone "ransomwareips.block";
>> } qname-wait-recurse no break-dnssec no;
>>
>> Vadim
>>
>> On 09 Aug 2018, at 20:50, Blason R <blason16 at gmail.com> wrote:
>>
>> This is the error I am getting
>>
>> /etc/bind/named.conf.options:24: expected 'zone' near 'qname-wait-recurse'
>>
>> On Fri, Aug 10, 2018 at 9:10 AM Blason R <blason16 at gmail.com> wrote:
>>
>>> Hi there,
>>>
>>> Where it should appear? ARM says it should appear inl Global-section of
>>> response-policy which I tried but getting error.
>>>
>>>     response-policy {zone "whitelist.allow" policy passthru;
>>>                         zone "malware.trap";
>>>                         zone "ransomwareips.block";
>>>                                 };
>>> qname-wait-recurse no;
>>> break-dnssec no;
>>>
>>>
>>> On Fri, Aug 10, 2018 at 8:09 AM Blason R <blason16 at gmail.com> wrote:
>>>
>>>> Well mine is bit different. I have RPZ and almost 400000+ RPZ entries
>>>> wall gardened. And in my scenario users are talking to windows based AD/DNS
>>>> server and then that server has forwarder set to RPZ.
>>>>
>>>>
>>>>    1. First issue; I observed certain entries from BIND/RPZ zone are
>>>>    being resolved by windows server directly to their original IPs and not the
>>>>    wall-gardened IP. Where I believe once the forwarder is set all those
>>>>    queries should have been routed to RPZ server? [If anyone here having
>>>>    Windows DNS expertise, pls help]
>>>>    2. And another, certain RPZ queries if queried through AD/DNS
>>>>    server are not at all getting resolved. When I captured packets on BIND/RPZ
>>>>    server I see that those domains are getting NXdomain by RPZ and not sure
>>>>    why.
>>>>
>>>> Thanks and Regards,
>>>> Lionel F
>>>>
>>>> On Thu, Aug 9, 2018 at 11:08 PM Bob Harold <rharolde at umich.edu> wrote:
>>>>
>>>>>
>>>>> 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";  };
>>>>>>> };
>>>>>>>
>>>>>>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180810/819c0958/attachment.html>


More information about the bind-users mailing list