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 <blaso...@gmail.com> wrote: > Its there!!! > > On Mon, Aug 13, 2018 at 6:58 PM Bob Harold <rharo...@umich.edu> wrote: > >> >> >> -- >> Bob Harold >> hostmaster, UMnet, ITcom >> Information and Technology Services (ITS) >> rharo...@umich.edu >> 734-647-6524 desk >> >> >> On Sun, Aug 12, 2018 at 2:38 AM Blason R <blaso...@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 <rharo...@umich.edu> wrote: >>> >>>> >>>> On Fri, Aug 10, 2018 at 10:53 PM Blason R <blaso...@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 <blaso...@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 <blaso...@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 <c...@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_...@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; >>>>>>>> >>>>>>>>
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users