Facing weird issue with DNS-RPZ

[Bob Harold]

On Tue, Apr 24, 2018 at 8:33 AM, Blason R <blason16 at gmail.com> wrote:

> Resending  since it seems it has few malicious domains
> ---------- Forwarded message ----------
> From: Blason R <blason16 at gmail.com>
> Date: Tue, Apr 24, 2018 at 6:02 PM
> Subject: Facing weird issue with DNS-RPZ
> To: bind-users <bind-users at lists.isc.org>
>
>
> Hello All,
>
> I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2
> (Extended Support Version).
>
> When I am manually creating writing a policy it works fine for CNAME while
> I have around 10k domains which needs to be wall-gardened but somehow as
> soon as I write simple while loop and entered in a .db file it stops RPZ
> functionality infact stops wall gardening instead it shows the real time.
>
> here is my zone config
>
> ###############
>
>         recursion yes;
>         forwarders {1.1.1.1; 8.8.8.8; 9.9.9.9; };
>         querylog yes;
>         response-policy { zone "isnlab.in"; };
>         check-names master ignore;
>         check-names slave ignore;
>
> ###############
>
> zone "isnlab.in" IN {
>         type master;
>         file "/var/named/firewall.local.db";
>         };
>
>
> ******************
> $TTL 180
> @               IN      SOA     ns1.isnlab.in. ns1.isnlab.in.    (
>                         2006060301      ; Serial
>                         21600           ; Refresh
>                         3600            ; Retry
>                         604800          ; Expire
>                         3600 )          ; Minimum TTL
>
>             IN  NS    ns1.isnlab.in.
> ns1.isnlab.in.            IN  A     172.16.3.46
> wg.isnlab.in.        IN  A     172.16.3.46
> *.facebook.com  CNAME   wg.isnlab.in.
> facebook.com    CNAME   wg.isnlab.in.
> testing.com     CNAME   wg.isnlab.in.
> *.testing.com   CNAME   wg.isnlab.in.
> 000cas.info       CNAME           wg.isnlab.in.
> 000dfcc96tkpc.com         CNAME           wg.isnlab.in.
>
> As soon as I add up the zones using below funcitonality it stops
> wallgardening and starts giving me real IPs
>
> This is before
> *$ dig @172.16.3.46 <http://172.16.3.46> facebook.com
> <http://facebook.com>*
>
> ; <<>> DiG 9.11.0-P5 <<>> @172.16.3.46 facebook.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6228
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;facebook.com.                  IN      A
>
> *;; ANSWER SECTION:*
> *facebook.com <http://facebook.com>.           5       IN      CNAME
>  wg.isnlab.in <http://wg.isnlab.in>.*
> *wg.isnlab.in <http://wg.isnlab.in>.           180     IN      A
>  172.16.3.46*
>
> *;; AUTHORITY SECTION:*
> *isnlab.in <http://isnlab.in>.              180     IN      NS
> ns1.isnlab.in <http://ns1.isnlab.in>.*
>
>
> ****************
> cat /tmp/sinkhole.zones | awk '{print $2}' | sed -e 's/\"//g' | while read
> line;do echo -e $line' \t ' CNAME' \t ' wg.isnlab.in.;done >>
> /var/named/firewall.local.db
>
> After this
> *$ dig @172.16.3.46 <http://172.16.3.46> facebook.com
> <http://facebook.com>*
>
> ; <<>> DiG 9.11.0-P5 <<>> @172.16.3.46 facebook.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32058
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;facebook.com.                  IN      A
>
> ;; ANSWER SECTION:
> *facebook.com <http://facebook.com>.           225     IN      A
>  157.240.13.35*
>
> ;; AUTHORITY SECTION:
> .                       2972    IN      NS      m.root-servers.net.
> .                       2972    IN      NS      a.root-servers.net.
> .                       2972    IN      NS      h.root-servers.net.
> .                       2972    IN      NS      j.root-servers.net.
> .                       2972    IN      NS      c.root-servers.net.
> .                       2972    IN      NS      i.root-servers.net.
> .                       2972    IN      NS      b.root-servers.net.
> .                       2972    IN      NS      g.root-servers.net.
> .                       2972    IN      NS      e.root-servers.net.
> .                       2972    IN      NS      k.root-servers.net.
> .                       2972    IN      NS      f.root-servers.net.
> .                       2972    IN      NS      d.root-servers.net.
> .                       2972    IN      NS      l.root-servers.net.
>
> ;; Query time: 128 msec
>
>
> Any clue why this is happening?
>

Check the logs for an error message saying that the zone failed to load,
and which line # had the error.

Also try this:
cat /tmp/sinkhole.zones | awk '{print $2}' | sed -e 's/\"//g' | egrep -v
'^[-0-9a-zA-Z.]*$'

There might be names that don't fit that pattern that are still ok, but it
is a start.

If not, then edit the zone and delete the last half of the lines, reload,
if it fails delete half of the remaining names, etc, until you find it by
binary search.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180424/8ec44678/attachment-0001.html>