Re: named assertion failure

2015-01-07 Thread Cathy Almond 
On 06/01/2015 04:11, James Brown wrote:
> Running BIND 9.10.1-P1  on Mac OS X 10.10.1. It’s been running fine - no
> problems until this morning, when I got:
> 
> 
> 06-Jan-2015 01:33:33.356 transfer of 'rpz.spamhaus.org/IN/external'
>  from 199.168.90.51#53: Transfer
> completed: 1 messages, 486 records, 11827 bytes, 0.292 secs (40503
> bytes/sec)
> 06-Jan-2015 01:33:33.463 rpz.c:463: REQUIRE(*cnt > 0) failed, back trace
> 06-Jan-2015 01:33:33.482 #0 0x10f97917d in isc_thread_yield()+0xf6ad05d
> 06-Jan-2015 01:33:33.495 #1 0x10fbf54aa in isc_thread_yield()+0xf92938a
> 06-Jan-2015 01:33:33.495 #2 0x10fab7eac in isc_thread_yield()+0xf7ebd8c
> 06-Jan-2015 01:33:33.495 #3 0x10fab678b in isc_thread_yield()+0xf7ea66b
> 06-Jan-2015 01:33:33.495 #4 0x10fa34c94 in isc_thread_yield()+0xf768b74
> 06-Jan-2015 01:33:33.496 #5 0x10fa3447c in isc_thread_yield()+0xf76835c
> 06-Jan-2015 01:33:33.496 #6 0x10fa34a67 in isc_thread_yield()+0xf768947
> 06-Jan-2015 01:33:33.496 #7 0x10fc1749e in isc_thread_yield()+0xf94b37e
> 06-Jan-2015 01:33:33.496 #8 0x7fff906792fc in
> isc_thread_yield()+0x7ffe903ad1dc
> 06-Jan-2015 01:33:33.496 #9 0x7fff90679279 in
> isc_thread_yield()+0x7ffe903ad159
> 06-Jan-2015 01:33:33.496 #10 0x7fff906774b1 in
> isc_thread_yield()+0x7ffe903ab391
> 06-Jan-2015 01:33:33.496 exiting (due to assertion failure)
> 
> Any suggestions or ideas what caused it and how to prevent in the future?
> 
> Let me know any more info that is required.
> 
> Thanks,
> 
> James.

Normally we'd request that instead of posting a crash here, that you
report it directly at https://www.isc.org/community/report-bug/

To diagnose a named crash problem, we'd be looking for you have saved a
core file from the aborting named process and to be able to submit it
along with the binary that produced the core, the libs on the system
that named was using, and other data:

https://kb.isc.org/article/AA-00340

If you have gdb, then we usually first (before asking you to submit the
files) ask that you load up the core and binary locally (preferably on
the system that produced the crash - then we both know that all the libs
are present and correct versions):

$ /gdb /named /

And then once loaded, issue:

> thread apply all bt full

(Sometimes this doesn't work or terminates prematurely - in which case,
retry without the 'full')

Then we'd want to see the output, from the start of launching gdb (as
the dump loading can also sometimes be useful).

---

However, in this instance, we already have one report of something that
looks very similar (bug reference RT #36888), so we'll contact you
directly off-list to verify.

Cathy
___
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

Re: How reliable is RPZ in production? I'm seeing flakiness in testing.

2015-01-07 Thread Phil Mayers 

On 06/01/15 22:52, Anne Bennett wrote:


I don't know what to make of this; it looks as though the
technology is several years old, and my experience with ISC
bind is usually excellent.  Has anyone else encountered this
type of flakiness?


No, but we're not using client-ip RPZ, just qname-based blacklists.

I've had a couple of occurrences of runaway CPU use triggered by a large 
RPZ AXFR, but no-one seems to believe me when I bring it up here, so 
I've stopped bothering :o/


But we certainly haven't see the kind of sporadic issue you describe. It 
might be that the client-ip stuff is newer?


Not sure how you'd debug it.
___
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

RPZ zone defined in a view

2015-01-07 Thread Tomas Hozza 
Hello.

The BIND ARM documentation in section 6.2.16.20 says that
"Response policy zones are named in the response-policy
option for the view or among the global options if there
is no response-policy option for the view."

However named with the following configuration fails to start:
--
options {
directory   "/var/named";
dump-file   "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any; };
recursion yes;

dnssec-enable no;
dnssec-validation no;
dnssec-lookaside auto;

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";

managed-keys-directory "/var/named/dynamic";

response-policy { zone "rpz"; };
};

logging {
channel default_debug {
file "data/named.run" versions 3 size 50M;
severity dynamic;
};
};

view "trusted" {

zone "." IN {
type hint;
file "named.ca";
};

zone "rpz" {
type master;
file "rpz.zone";
};
};

view "untrusted" {

match-clients { any; };

zone "." IN {
type hint;
file "named.ca";
};
};
--
It ends with:
...
07-Jan-2015 13:12:58.641 /etc/named.conf:18: 'rpz' is not a master or slave zone
07-Jan-2015 13:12:58.642 loading configuration: not found
07-Jan-2015 13:12:58.642 exiting (due to fatal error)

I think the problem is that if the response-policy statement
is used within the options statement, then named looks for
the zone only in the _default view. However if you use view
statements, then all zones have to be defined in some view,
thus making the RPZ zone "non-existing" for the global
response-policy statement.

If I move the response-policy statement to the "trusted" view
it starts to work.

However based on the documentation it should work also in the
first case.

Is the documentation wrong or is it a bug in the RPZ implementation?

Thanks!

Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.   http://cz.redhat.com
___
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

Re: RPZ zone defined in a view

2015-01-07 Thread Mark Andrews 

In message <54ad246d.7080...@redhat.com>, Tomas Hozza writes:
> Hello.
> 
> The BIND ARM documentation in section 6.2.16.20 says that
> "Response policy zones are named in the response-policy
> option for the view or among the global options if there
> is no response-policy option for the view."
> 
> However named with the following configuration fails to start:
> --
> options {
> directory   "/var/named";
> dump-file   "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query { any; };
> recursion yes;
> 
> dnssec-enable no;
> dnssec-validation no;
> dnssec-lookaside auto;
> 
> /* Path to ISC DLV key */
> bindkeys-file "/etc/named.iscdlv.key";
> 
> managed-keys-directory "/var/named/dynamic";
> 
> response-policy { zone "rpz"; };
> };
> 
> logging {
> channel default_debug {
> file "data/named.run" versions 3 size 50M;
> severity dynamic;
> };
> };
> 
> view "trusted" {
> 
> zone "." IN {
> type hint;
> file "named.ca";
> };
> 
> zone "rpz" {
> type master;
> file "rpz.zone";
> };
> };
> 
> view "untrusted" {
> 
> match-clients { any; };
> 
> zone "." IN {
> type hint;
> file "named.ca";
> };
> };
> --
> It ends with:
> ...
> 07-Jan-2015 13:12:58.641 /etc/named.conf:18: 'rpz' is not a master or slave z
> one
> 07-Jan-2015 13:12:58.642 loading configuration: not found
> 07-Jan-2015 13:12:58.642 exiting (due to fatal error)
> 
> I think the problem is that if the response-policy statement
> is used within the options statement, then named looks for
> the zone only in the _default view. However if you use view
> statements, then all zones have to be defined in some view,
> thus making the RPZ zone "non-existing" for the global
> response-policy statement.

By adding it to options you are saying that all views have a rpz zone
but that is not the case.  "untrusted" does not have a rpz zone.

> If I move the response-policy statement to the "trusted" view
> it starts to work.
> 
> However based on the documentation it should work also in the
> first case.
> 
> Is the documentation wrong or is it a bug in the RPZ implementation?
> 
> Thanks!
> 
> Regards,
> -- 
> Tomas Hozza
> Software Engineer - EMEA ENG Developer Experience
> 
> PGP: 1D9F3C2D
> Red Hat Inc.   http://cz.redhat.com
> ___
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

Re: RPZ zone defined in a view

2015-01-07 Thread Tomas Hozza 
On 01/07/2015 02:31 PM, Mark Andrews wrote:
> In message <54ad246d.7080...@redhat.com>, Tomas Hozza writes:
> > Hello.
> >
> > The BIND ARM documentation in section 6.2.16.20 says that
> > "Response policy zones are named in the response-policy
> > option for the view or among the global options if there
> > is no response-policy option for the view."
> >
> > However named with the following configuration fails to start:
> > --
> > options {
> > directory   "/var/named";
> > dump-file   "/var/named/data/cache_dump.db";
> > statistics-file "/var/named/data/named_stats.txt";
> > memstatistics-file "/var/named/data/named_mem_stats.txt";
> > allow-query { any; };
> > recursion yes;
> >
> > dnssec-enable no;
> > dnssec-validation no;
> > dnssec-lookaside auto;
> >
> > /* Path to ISC DLV key */
> > bindkeys-file "/etc/named.iscdlv.key";
> >
> > managed-keys-directory "/var/named/dynamic";
> >
> > response-policy { zone "rpz"; };
> > };
> >
> > logging {
> > channel default_debug {
> > file "data/named.run" versions 3 size 50M;
> > severity dynamic;
> > };
> > };
> >
> > view "trusted" {
> >
> > zone "." IN {
> > type hint;
> > file "named.ca";
> > };
> >
> > zone "rpz" {
> > type master;
> > file "rpz.zone";
> > };
> > };
> >
> > view "untrusted" {
> >
> > match-clients { any; };
> >
> > zone "." IN {
> > type hint;
> > file "named.ca";
> > };
> > };
> > --
> > It ends with:
> > ...
> > 07-Jan-2015 13:12:58.641 /etc/named.conf:18: 'rpz' is not a master or slave 
> > z
> > one
> > 07-Jan-2015 13:12:58.642 loading configuration: not found
> > 07-Jan-2015 13:12:58.642 exiting (due to fatal error)
> >
> > I think the problem is that if the response-policy statement
> > is used within the options statement, then named looks for
> > the zone only in the _default view. However if you use view
> > statements, then all zones have to be defined in some view,
> > thus making the RPZ zone "non-existing" for the global
> > response-policy statement.
>
> By adding it to options you are saying that all views have a rpz zone
> but that is not the case.  "untrusted" does not have a rpz zone.
Ahh, that is the case. It wasn't clear to me from the documentation. It works
with the rpz zone in both views.

Thank you for the answer.
>
> > If I move the response-policy statement to the "trusted" view
> > it starts to work.
> >
> > However based on the documentation it should work also in the
> > first case.
> >
> > Is the documentation wrong or is it a bug in the RPZ implementation?
> >
> > Thanks!
> >
> > Regards,
> > --
> > Tomas Hozza
> > Software Engineer - EMEA ENG Developer Experience
> >
> > PGP: 1D9F3C2D
> > Red Hat Inc.   http://cz.redhat.com
> > ___
> > 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


-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
___
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

Re: How reliable is RPZ in production? I'm seeing flakiness in testing.

2015-01-07 Thread Anne Bennett 

John, thanks for helping.

> You might start things out by giving us your bind version

9.10.1-P1

> and your response-policy {} config.

  response-policy {
zone "rpz-whitelist"   policy given;
zone "rpz-quarantine"  policy given;
zone "rpz-phish"   policy given;
zone "rpz-malware" policy given;
zone "rpz-isc-suspicious"  policy given;
zone "rpz-mwdoms-doms" policy given;
zone "rpz-mwdoms-hosts"policy given;
  };

At the moment, only the first four contain any records
aside from SOA and NS.

> Also print out the exact rules (one or two
> examples should suffice) you're using for client quarantining --
> that'll help narrow things down.

"rpz-whitelist" has QNAME/passthru entries for names in
my domain and for patch sites.  It also has rpz-ip/passthru
entries for IP addresses of the same.  To show a few examples,
first for our University's public network:

  concordia.caCNAME rpz-passthru.
  *.concordia.ca  CNAME rpz-passthru.

  205.132.in-addr.arpaCNAME rpz-passthru.
  *.205.132.in-addr.arpa  CNAME rpz-passthru.

  16.0.0.205.132.rpz-ip   CNAME rpz-passthru.

... and for a patch site:

  12.0.0.0.23.rpz-ip  CNAME rpz-passthru. ; Akamai

(Note that I added the in-addr.arpa lines just lately, and
haven't re-run the tests with those in place, but those weren't
the names I was testing for; I was testing with nslookup.)

"rpz-quarantine" had, when I was testing, my workstation's address:

  32.192.47.205.132.rpz-client-ip CNAME serv-quarantine.encs.concordia.ca.

"rpz-phish" and "rpz-malware" have a few test entries, for example:

  nonexistent.porcupine.caCNAME serv-fishnet.encs.concordia.ca.
  *.nonexistent.porcupine.ca  CNAME serv-fishnet.encs.concordia.ca.

  emaillimitedequota.yolasite.com CNAME serv-fishnet.encs.concordia.ca.
  *.emaillimitedequota.yolasite.com   CNAME serv-fishnet.encs.concordia.ca.



> Also, how are you publishing to your
> client quarantine zones?  Presumably you're using some sort of DDNS
> publishing that gets triggered when a client does something
> suspicious.

No, actually, so far it's all manual (edit the zone file and
issue a reload), and the first four will remain that way.
The last three will contain data we obtain automatically from
offsite, but my download-parse-update-reload script will do
essentially the same as my manual operation.  We don't use
DDNS at all.


I'm going to re-run my tests with a fresh mind (I last tested
before I took a vacation in December, and I needed that
vacation!), though I find it hard to see what I could possibly
have done wrong that would have the nameserver changing its
responses to me without the data having been touched.

I'll report back with my new test results.



Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
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