Need help on RPZ sever, bit urgent

Discussion:

Need help on RPZ sever, bit urgent

Blason R

2018-08-09 13:29:16 UTC

Hi Bind-Users,

I would really appreciate if someone can help me understanding my issue
with BIND RPZ server?

I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.

Ideally since those end user has 192.168.1.42 DNS Server set and has
forwarder set to 192.168.1.179 should forward all queries to 1.179, right?

But certain domains from my response-policy are even though wall-gardened
those are being catered as NXdomain.

Anything I am missing pertaining to RPZ?

Or if I am querying all those domains directly to RPZ server then I am
getting proper answer. This issue is noticed when I have forwarder server
is between

options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no; # conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};

Blason R

2018-08-09 13:30:55 UTC

For example this one.

18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
0/1/0 (102)

Post by Blason R
Hi Bind-Users,
I would really appreciate if someone can help me understanding my issue
with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.
Ideally since those end user has 192.168.1.42 DNS Server set and has
forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
But certain domains from my response-policy are even though wall-gardened
those are being catered as NXdomain.
Anything I am missing pertaining to RPZ?
Or if I am querying all those domains directly to RPZ server then I am
getting proper answer. This issue is noticed when I have forwarder server
is between
options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no; # conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};

Bob Harold

2018-08-09 17:37:58 UTC

Post by Blason R
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
0/1/0 (102)

With RPZ, the name is looked up normally first, and only if there is an
answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that
and does not use RPZ.
If that is not what you want, then you probably want to set the option:
qname-wait-recurse no;
--
Bob Harold

Post by Blason R

Post by Blason R
Hi Bind-Users,
I would really appreciate if someone can help me understanding my issue
with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.
Ideally since those end user has 192.168.1.42 DNS Server set and has
forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
But certain domains from my response-policy are even though wall-gardened
those are being catered as NXdomain.
Anything I am missing pertaining to RPZ?
Or if I am querying all those domains directly to RPZ server then I am
getting proper answer. This issue is noticed when I have forwarder server
is between
options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no; # conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};

Blason R

2018-08-10 02:39:22 UTC

Well mine is bit different. I have RPZ and almost 400000+ RPZ entries wall
gardened. And in my scenario users are talking to windows based AD/DNS
server and then that server has forwarder set to RPZ.

1. First issue; I observed certain entries from BIND/RPZ zone are being
resolved by windows server directly to their original IPs and not the
wall-gardened IP. Where I believe once the forwarder is set all those
queries should have been routed to RPZ server? [If anyone here having
Windows DNS expertise, pls help]
2. And another, certain RPZ queries if queried through AD/DNS server are
not at all getting resolved. When I captured packets on BIND/RPZ server I
see that those domains are getting NXdomain by RPZ and not sure why.

Thanks and Regards,
Lionel F

Post by Bob Harold

Post by Blason R
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
0/1/0 (102)

With RPZ, the name is looked up normally first, and only if there is an
answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that
and does not use RPZ.
qname-wait-recurse no;
--
Bob Harold

Post by Blason R

Post by Blason R
Hi Bind-Users,
I would really appreciate if someone can help me understanding my issue
with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.
Ideally since those end user has 192.168.1.42 DNS Server set and has
forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
But certain domains from my response-policy are even though
wall-gardened those are being catered as NXdomain.
Anything I am missing pertaining to RPZ?
Or if I am querying all those domains directly to RPZ server then I am
getting proper answer. This issue is noticed when I have forwarder server
is between
options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no; # conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};

Blason R

2018-08-10 03:40:09 UTC

Hi there,

Where it should appear? ARM says it should appear inl Global-section of
response-policy which I tried but getting error.

response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
};
qname-wait-recurse no;
break-dnssec no;

Post by Blason R
Well mine is bit different. I have RPZ and almost 400000+ RPZ entries wall
gardened. And in my scenario users are talking to windows based AD/DNS
server and then that server has forwarder set to RPZ.
1. First issue; I observed certain entries from BIND/RPZ zone are
being resolved by windows server directly to their original IPs and not the
wall-gardened IP. Where I believe once the forwarder is set all those
queries should have been routed to RPZ server? [If anyone here having
Windows DNS expertise, pls help]
2. And another, certain RPZ queries if queried through AD/DNS server
are not at all getting resolved. When I captured packets on BIND/RPZ server
I see that those domains are getting NXdomain by RPZ and not sure why.
Thanks and Regards,
Lionel F

Post by Bob Harold

Post by Blason R
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
0/1/0 (102)

With RPZ, the name is looked up normally first, and only if there is an
answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that
and does not use RPZ.
qname-wait-recurse no;
--
Bob Harold

Post by Blason R

Post by Blason R
Hi Bind-Users,
I would really appreciate if someone can help me understanding my issue
with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.
Ideally since those end user has 192.168.1.42 DNS Server set and has
forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
But certain domains from my response-policy are even though
wall-gardened those are being catered as NXdomain.
Anything I am missing pertaining to RPZ?
Or if I am querying all those domains directly to RPZ server then I am
getting proper answer. This issue is noticed when I have forwarder server
is between
options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no; # conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};

Blason R

2018-08-10 03:50:24 UTC

This is the error I am getting

/etc/bind/named.conf.options:24: expected 'zone' near 'qname-wait-recurse'

Post by Blason R
Hi there,
Where it should appear? ARM says it should appear inl Global-section of
response-policy which I tried but getting error.
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
};
qname-wait-recurse no;
break-dnssec no;

Post by Blason R
Well mine is bit different. I have RPZ and almost 400000+ RPZ entries
wall gardened. And in my scenario users are talking to windows based AD/DNS
server and then that server has forwarder set to RPZ.
1. First issue; I observed certain entries from BIND/RPZ zone are
being resolved by windows server directly to their original IPs and not the
wall-gardened IP. Where I believe once the forwarder is set all those
queries should have been routed to RPZ server? [If anyone here having
Windows DNS expertise, pls help]
2. And another, certain RPZ queries if queried through AD/DNS server
are not at all getting resolved. When I captured packets on BIND/RPZ server
I see that those domains are getting NXdomain by RPZ and not sure why.
Thanks and Regards,
Lionel F

Post by Bob Harold

Post by Blason R
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074
NXDomain 0/1/0 (102)

With RPZ, the name is looked up normally first, and only if there is an
answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that
and does not use RPZ.
qname-wait-recurse no;
--
Bob Harold

Post by Blason R

Post by Blason R
Hi Bind-Users,
I would really appreciate if someone can help me understanding my
issue with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.
Ideally since those end user has 192.168.1.42 DNS Server set and has
forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
But certain domains from my response-policy are even though
wall-gardened those are being catered as NXdomain.
Anything I am missing pertaining to RPZ?
Or if I am querying all those domains directly to RPZ server then I am
getting proper answer. This issue is noticed when I have forwarder server
is between
options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no; # conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};

Vadim Pavlov via bind-users

2018-08-10 07:27:59 UTC

Should be:

response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;

Vadim

Post by Blason R
This is the error I am getting
/etc/bind/named.conf.options:24: expected 'zone' near 'qname-wait-recurse'
Hi there,
Where it should appear? ARM says it should appear inl Global-section of response-policy which I tried but getting error.
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
};
qname-wait-recurse no;
break-dnssec no;
Well mine is bit different. I have RPZ and almost 400000+ RPZ entries wall gardened. And in my scenario users are talking to windows based AD/DNS server and then that server has forwarder set to RPZ.
First issue; I observed certain entries from BIND/RPZ zone are being resolved by windows server directly to their original IPs and not the wall-gardened IP. Where I believe once the forwarder is set all those queries should have been routed to RPZ server? [If anyone here having Windows DNS expertise, pls help]
And another, certain RPZ queries if queried through AD/DNS server are not at all getting resolved. When I captured packets on BIND/RPZ server I see that those domains are getting NXdomain by RPZ and not sure why.
Thanks and Regards,
Lionel F
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A? 0351dag.com <http://0351dag.com/>. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain 0/1/0 (102)
With RPZ, the name is looked up normally first, and only if there is an answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that and does not use RPZ.
qname-wait-recurse no;
--
Bob Harold
Hi Bind-Users,
I would really appreciate if someone can help me understanding my issue with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with 192.168.1.179. I noticed that there are certain domains which are not getting resolved from end users.
Ideally since those end user has 192.168.1.42 DNS Server set and has forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
But certain domains from my response-policy are even though wall-gardened those are being catered as NXdomain.
Anything I am missing pertaining to RPZ?
Or if I am querying all those domains directly to RPZ server then I am getting proper answer. This issue is noticed when I have forwarder server is between
options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no; # conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Blason R

2018-08-10 07:47:26 UTC

Nah I dont think that is the answer since you need a termination after
clause.

Thanks and Regards,
Lionel F

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;
Vadim
This is the error I am getting
/etc/bind/named.conf.options:24: expected 'zone' near 'qname-wait-recurse'

Post by Blason R
Hi there,
Where it should appear? ARM says it should appear inl Global-section of
response-policy which I tried but getting error.
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
};
qname-wait-recurse no;
break-dnssec no;

Post by Blason R
Well mine is bit different. I have RPZ and almost 400000+ RPZ entries
wall gardened. And in my scenario users are talking to windows based AD/DNS
server and then that server has forwarder set to RPZ.
1. First issue; I observed certain entries from BIND/RPZ zone are
being resolved by windows server directly to their original IPs and not the
wall-gardened IP. Where I believe once the forwarder is set all those
queries should have been routed to RPZ server? [If anyone here having
Windows DNS expertise, pls help]
2. And another, certain RPZ queries if queried through AD/DNS server
are not at all getting resolved. When I captured packets on BIND/RPZ server
I see that those domains are getting NXdomain by RPZ and not sure why.
Thanks and Regards,
Lionel F

Post by Bob Harold

Post by Blason R
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074
NXDomain 0/1/0 (102)

With RPZ, the name is looked up normally first, and only if there is an
answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that
and does not use RPZ.
qname-wait-recurse no;
--
Bob Harold

Post by Blason R

Post by Blason R
Hi Bind-Users,
I would really appreciate if someone can help me understanding my
issue with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.
Ideally since those end user has 192.168.1.42 DNS Server set and has
forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
But certain domains from my response-policy are even though
wall-gardened those are being catered as NXdomain.
Anything I am missing pertaining to RPZ?
Or if I am querying all those domains directly to RPZ server then I
am getting proper answer. This issue is noticed when I have forwarder
server is between
options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no; # conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};
_______________________________________________

Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Blason R

2018-08-10 08:36:34 UTC

Hello All,

I have been debugging my issue from last 30+ hrs without luck and dang its
something related to forwarding. Again here is my quick scenario

I have Windows DNS Server 192.168.1.42 Has Forwarder set to 192.168.1.179
[BIND/RPZ]

Now certain domains when queried from end user e.g 192.168.1.100 has DNS
set to 192.168.1.42 does not get resolved at all. While I troubleshooting
I observed that may be 192.168.1.42 has got root zone "." and is trying to
resolve locally instead of forwarding. I noticed this issue is happening
randomly with any domains but mostly it observed for .com and .net domain
entries.

Again I tried replacing 192.168.1.42 with Linux BIND server and its same
behavior so I don't think its related with Windows.

I want all other queries should strictly forward to my RPZ forwarding
server. How do I do that can someone help me in troubleshooting? I can
provide the logs and config.

Or if someone has a similar setup can try simulating at their end and
confirm, plz?

Post by Blason R
Nah I dont think that is the answer since you need a termination after
clause.
Thanks and Regards,
Lionel F

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;
Vadim
This is the error I am getting
/etc/bind/named.conf.options:24: expected 'zone' near 'qname-wait-recurse'

Post by Blason R
Hi there,
Where it should appear? ARM says it should appear inl Global-section of
response-policy which I tried but getting error.
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
};
qname-wait-recurse no;
break-dnssec no;

Post by Blason R
Well mine is bit different. I have RPZ and almost 400000+ RPZ entries
wall gardened. And in my scenario users are talking to windows based AD/DNS
server and then that server has forwarder set to RPZ.
1. First issue; I observed certain entries from BIND/RPZ zone are
being resolved by windows server directly to their original IPs and not the
wall-gardened IP. Where I believe once the forwarder is set all those
queries should have been routed to RPZ server? [If anyone here having
Windows DNS expertise, pls help]
2. And another, certain RPZ queries if queried through AD/DNS
server are not at all getting resolved. When I captured packets on BIND/RPZ
server I see that those domains are getting NXdomain by RPZ and not sure
why.
Thanks and Regards,
Lionel F

Post by Bob Harold

Post by Blason R
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074
NXDomain 0/1/0 (102)

With RPZ, the name is looked up normally first, and only if there is
an answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns
that and does not use RPZ.
qname-wait-recurse no;
--
Bob Harold

Post by Blason R

Post by Blason R
Hi Bind-Users,
I would really appreciate if someone can help me understanding my
issue with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.
Ideally since those end user has 192.168.1.42 DNS Server set and has
forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
But certain domains from my response-policy are even though
wall-gardened those are being catered as NXdomain.
Anything I am missing pertaining to RPZ?
Or if I am querying all those domains directly to RPZ server then I
am getting proper answer. This issue is noticed when I have forwarder
server is between
options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no; # conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};
_______________________________________________

Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Carl Byington

2018-08-10 19:47:04 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Blason R
Nah I dont think that is the answer since you need a termination after
clause.

Did you actually try the answer below?

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAltt65oACgkQL6j7milTFsF1fgCfYX/B4MaSrPqmoskfYvFAUQVV
YfcAn2NO474pn6agGUmjjR49eq4+sw4Y
=VwoG
-----END PGP SIGNATURE-----

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Blason R

2018-08-11 02:21:25 UTC

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; };

Post by Carl Byington
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Blason R
Nah I dont think that is the answer since you need a termination after
clause.

Did you actually try the answer below?

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEAREKAAYFAltt65oACgkQL6j7milTFsF1fgCfYX/B4MaSrPqmoskfYvFAUQVV
YfcAn2NO474pn6agGUmjjR49eq4+sw4Y
=VwoG
-----END PGP SIGNATURE-----
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Blason R

2018-08-11 02:27:26 UTC

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;

Post by Blason R
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; };

Post by Carl Byington
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Blason R
Nah I dont think that is the answer since you need a termination after
clause.

Did you actually try the answer below?

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEAREKAAYFAltt65oACgkQL6j7milTFsF1fgCfYX/B4MaSrPqmoskfYvFAUQVV
YfcAn2NO474pn6agGUmjjR49eq4+sw4Y
=VwoG
-----END PGP SIGNATURE-----
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Blason R

2018-08-11 02:46:35 UTC

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

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

Post by Blason R
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;

Post by Blason R
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; };

Post by Carl Byington
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Blason R
Nah I dont think that is the answer since you need a termination after
clause.

Did you actually try the answer below?

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEAREKAAYFAltt65oACgkQL6j7milTFsF1fgCfYX/B4MaSrPqmoskfYvFAUQVV
YfcAn2NO474pn6agGUmjjR49eq4+sw4Y
=VwoG
-----END PGP SIGNATURE-----
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Bob Harold

2018-08-12 04:42:36 UTC

Post by Blason R
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

Post by Blason R
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
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
;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

Post by Blason R
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;

Post by Blason R
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; };

Post by Carl Byington
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Blason R
Nah I dont think that is the answer since you need a termination after
clause.

Did you actually try the answer below?

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;

Blason R

2018-08-12 06:38:34 UTC

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?

Post by Bob Harold

Post by Blason R
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

Post by Blason R
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
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
;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

Post by Blason R
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;

Post by Blason R
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; };

Post by Carl Byington
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Blason R
Nah I dont think that is the answer since you need a termination

after

Post by Blason R
clause.

Did you actually try the answer below?

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;

Bob Harold

2018-08-13 13:28:36 UTC

--
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
***@umich.edu
734-647-6524 desk

Post by Blason R
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

Post by Blason R
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?

Post by Bob Harold

Post by Blason R
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

Post by Blason R
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
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
;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

Post by Blason R
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;

Post by Blason R
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; };

Post by Carl Byington
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Blason R
Nah I dont think that is the answer since you need a termination

after

Post by Blason R
clause.

Did you actually try the answer below?

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;

Blason R

2018-08-13 14:58:31 UTC

Its there!!!

Post by Bob Harold
--
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
734-647-6524 desk

Post by Blason R
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.

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

Post by Blason R
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?

Post by Bob Harold

Post by Blason R
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

Post by Blason R
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
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
;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

Post by Blason R
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;

Post by Blason R
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; };

Post by Carl Byington
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Blason R
Nah I dont think that is the answer since you need a termination

after

Post by Blason R
clause.

Did you actually try the answer below?

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;

Bob Harold

2018-08-13 16:45:57 UTC

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

Post by Blason R
Its there!!!

Post by Bob Harold
--
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
734-647-6524 desk

Post by Blason R
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.

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

Post by Blason R
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?

Post by Bob Harold

Post by Blason R
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

Post by Blason R
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
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
;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

Post by Blason R
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;

Post by Blason R
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; };

Post by Carl Byington
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Blason R
Nah I dont think that is the answer since you need a termination

after

Post by Blason R
clause.

Did you actually try the answer below?

Post by Blason R
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
} qname-wait-recurse no break-dnssec no;

Sam Wilson

2018-08-09 15:27:06 UTC

Post by Blason R
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074
NXDomain 0/1/0 (102)

$ dig 0351dag.com

; <<>> DiG 9.8.3-P1 <<>> 0351dag.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44466
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;0351dag.com. IN A

;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com.
1533828275 1800 900 604800 86400

Sam
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Blason R

2018-08-09 17:25:21 UTC

Is it a big?? I mean certain domains from my rpz feeds are properly getting
resolved while few are giving nxdomain though they appear in zone.

Post by Sam Wilson

Post by Blason R
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074
NXDomain 0/1/0 (102)

$ dig 0351dag.com
; <<>> DiG 9.8.3-P1 <<>> 0351dag.com
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44466
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;0351dag.com. IN A
com. 900 IN SOA a.gtld-servers.net.
nstld.verisign-grs.com.
1533828275 1800 900 604800 86400
Sam
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

WILSON Sam

2018-08-10 09:31:40 UTC

I'm sorry, I don't understand the question. Your message shows a query and an NXDOMAIN response. That seems to be correct. I don't know whether your RPZ configuration is supposed to change that.

Sam

Is it a big?? I mean certain domains from my rpz feeds are properly getting resolved while few are giving nxdomain though they appear in zone.

Post by Blason R
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074
NXDomain 0/1/0 (102)

$ dig 0351dag.com
; <<>> DiG 9.8.3-P1 <<>> 0351dag.com
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44466
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;0351dag.com. IN A
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com.
1533828275 1800 900 604800 86400
Sam
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

--
Sam Wilson
Communications Infrastructure Section, IT Infrastructure
Information Services, The University of Edinburgh
Edinburgh, Scotland, UK

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Blason R

2018-08-10 18:38:30 UTC

Hello,

Well even though the entry is there in RPZ zone it is still being returned
as nxdomain.

Post by WILSON Sam
I'm sorry, I don't understand the question. Your message shows a query
and an NXDOMAIN response. That seems to be correct. I don't know whether
your RPZ configuration is supposed to change that.
Sam

Post by Blason R
Is it a big?? I mean certain domains from my rpz feeds are properly

getting resolved while few are giving nxdomain though they appear in zone.

Post by Blason R

Post by Blason R
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074
NXDomain 0/1/0 (102)

$ dig 0351dag.com
; <<>> DiG 9.8.3-P1 <<>> 0351dag.com
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44466
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;0351dag.com. IN A
com. 900 IN SOA a.gtld-servers.net.

nstld.verisign-grs.com.

Post by Blason R
1533828275 1800 900 604800 86400
Sam
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to

unsubscribe from this list

Post by Blason R
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

--
Sam Wilson
Communications Infrastructure Section, IT Infrastructure
Information Services, The University of Edinburgh
Edinburgh, Scotland, UK
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

21 Replies
1 View
Permalink to this page
Disable enhanced parsing

Thread Navigation

Blason R 2018-08-09 13:29:16 UTC

Blason R 2018-08-09 13:30:55 UTC

Bob Harold 2018-08-09 17:37:58 UTC

Blason R 2018-08-10 02:39:22 UTC

Blason R 2018-08-10 03:40:09 UTC

Blason R 2018-08-10 03:50:24 UTC

Vadim Pavlov via bind-users 2018-08-10 07:27:59 UTC

Blason R 2018-08-10 07:47:26 UTC

Blason R 2018-08-10 08:36:34 UTC

Carl Byington 2018-08-10 19:47:04 UTC

Blason R 2018-08-11 02:21:25 UTC

Blason R 2018-08-11 02:27:26 UTC

Blason R 2018-08-11 02:46:35 UTC

Bob Harold 2018-08-12 04:42:36 UTC

Blason R 2018-08-12 06:38:34 UTC

Bob Harold 2018-08-13 13:28:36 UTC

Blason R 2018-08-13 14:58:31 UTC

Bob Harold 2018-08-13 16:45:57 UTC

Sam Wilson 2018-08-09 15:27:06 UTC

Blason R 2018-08-09 17:25:21 UTC

WILSON Sam 2018-08-10 09:31:40 UTC

Blason R 2018-08-10 18:38:30 UTC

about - legalese

Loading...