Need help on RPZ sever, bit urgent

Blason R blason16 at gmail.com
Sun Aug 12 06:38:34 UTC 2018


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.

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/20180812/ae02fe34/attachment-0001.html>


More information about the bind-users mailing list