Need help on RPZ sever, bit urgent

[Bob Harold]

-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharolde at umich.edu
734-647-6524 desk


On Sun, Aug 12, 2018 at 2:38 AM Blason R <blason16 at gmail.com> wrote:

> Hi Bob,
>
> I guess my scenario is not exactly understood I believe. Before that if I
> have set forwarder in Global option then ideally BIND should forward all
> queries to the forwarder, right?
>
> Lets say 192.168.3.15 is client
> 192.168.3.42 is BIND Server
> 192.168.3.78 is RPZ server
>
> I have one zone on 192.168.3.42 by name test.com and have all the entries
> on 192.168.3.42, so on users desktop 192.168.3.15 I have DNS configured as
> 192.168.3.42.
>

Make sure 3.42 has in the global options:
forward only;
forwarders { 192.168.3.78; };

If you are missing the "forward only;" then bind will try to forward, but
if it does not get a quick answer it will try to resolve itself.

-- 
Bob Harold


> So,
>
> When query goes for ftp.test.com it will be resolved by 192.168.3.42
> When query goes for bad.malware.com. it will be forwarded 192.168.3.78
> where it will be wall-gardened.
>
> Now what I noticed is certain RPZ entries on 3.78 are not getting resolved
> from 192.168.3.15. And then I observed that certain .com entries 3.42 is
> trying resolve on his own even though he is not authoritative server and
> supposedly those ALL queries should have been forwarded to 192.168.3.78.
>
> PS:  I guess there are certain folks are on list from commercial RPZ
> services, are they facing same issue?
>
> On Sun, Aug 12, 2018 at 10:12 AM Bob Harold <rharolde at umich.edu> wrote:
>
>>
>> On Fri, Aug 10, 2018 at 10:53 PM Blason R <blason16 at gmail.com> wrote:
>>
>>> Infact what I observed that the intermediate DNS servers are not
>>> forwarding he queries for .com and .net servers to my RPZ servers and it
>>> tries resolves directly on his own from TLD servers
>>>
>>
>> You need to work on the intermediate server to get it to forward.  If it
>> is running  Microsoft DNS, then I don't know enough to help you with that.
>>
>> I would suggest that  you have the RPZ server be a 'slave' for the '
>> test.com' zone (and all the zones that the AUTH server has).  Then point
>> users directly at the RPZ server.
>>
>> --
>> Bob Harold
>>
>>
>>
>>> 192.168.3.72 End User
>>> 192.168.3.15 [AUTH Server for test.com] and has forwarder to
>>> 192.168.3.44 [RPZ]
>>>
>>> So, 3.15 should only resolve for test.com else all queries should be
>>> forwarded to 192.168.3.44
>>>
>>> *Which is not happening.*
>>>
>>> dig 003bbhq9.com
>>>
>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> 003bbhq9.com
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;003bbhq9.com.                  IN      A
>>>
>>> *;; AUTHORITY SECTION:*
>>> *com.                    530     IN      SOA     a.gtld-servers.net
>>> <http://a.gtld-servers.net>. nstld.verisign-grs.com
>>> <http://nstld.verisign-grs.com>. 1533954938 1800 900 604800 86400*
>>>
>>> ;; Query time: 0 msec
>>> ;; SERVER: 192.168.3.15#53(192.168.3.15)
>>> ;; WHEN: Sat Aug 11 08:12:17 IST 2018
>>> ;; MSG SIZE  rcvd: 114
>>>
>>>
>>> On Sat, Aug 11, 2018 at 7:57 AM Blason R <blason16 at gmail.com> wrote:
>>>
>>>> Ok - Now I added like this and it disappeared.
>>>>
>>>>         response-policy { zone "whitelist.allow" policy passthru;
>>>>                         zone "malware.trap";
>>>>                         zone "ransomwareips.block"; }
>>>> qname-wait-recurse no break-dnssec no;
>>>>
>>>>
>>>> On Sat, Aug 11, 2018 at 7:51 AM Blason R <blason16 at gmail.com> wrote:
>>>>
>>>>> This is not accepting and giving my syntax error.
>>>>>
>>>>> named-checkconf /etc/bind/named.conf
>>>>> /etc/bind/named.conf.options:29: syntax error near '}'
>>>>>
>>>>>
>>>>> And here is I added
>>>>>
>>>>>         response-policy { zone "whitelist.allow" policy passthru;
>>>>>                         zone "malware.trap";
>>>>>                         zone "ransomwareips.block"; }
>>>>> qname-wait-recurse no break-dnssec no; };
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 11, 2018 at 1:17 AM Carl Byington <carl at byington.org>
>>>>> wrote:
>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA512
>>>>>>
>>>>>> On Fri, 2018-08-10 at 13:17 +0530, Blason R wrote:
>>>>>> > Nah I dont think that is the answer since you need a termination
>>>>>> after
>>>>>> > clause.
>>>>>>
>>>>>> Did you actually try the answer below?
>>>>>>
>>>>>>
>>>>>> > 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;
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180813/f314188f/attachment.html>