Need help on RPZ sever, bit urgent

[Blason R]

Its there!!!

On Mon, Aug 13, 2018 at 6:58 PM Bob Harold <rharolde at umich.edu> wrote:

>
>
> --
> 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/90ae8dc9/attachment-0001.html>