Need help on RPZ sever, bit urgent

[Bob Harold]

I don't know what else to check.  If possible, I would avoid forwarding by
putting both functions on the same server.  You could turn on BIND
debugging - Cricket's "DNS and BIND" book has a  chapter on debugging - but
that could be a lot of work.

-- 
Bob Harold

On Mon, Aug 13, 2018 at 10:58 AM Blason R <blason16 at gmail.com> wrote:

> 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/cdbbbc0b/attachment.html>