Have you looked at DSC?
http://dns.measurement-factory.com/tools/dsc/
It doesn't parse logs, but reads actual packet traces, and it reports
many good statistics, with nice colored graphs.
cv
On Sat, Dec 29, 2012 at 11:56 AM, Gaurav Kansal wrote:
> Dear Team,
>
>
>
> I want to collect some stat
Hi Jim,
We are seeing the same thing. The problem is an incorrectly signed
zone (missing RRSIG records) at ed.gov. See:
http://dnssec-debugger.verisignlabs.com/www.ed.gov
http://dnsviz.net/d/www.ed.gov/dnssec/
cv
On Fri, May 27, 2011 at 12:09 PM, Jim Glassford wrote:
> Hi,
>
> Running BIND 9.7
> If, for some reason, you can't wait for your TTLs to expire, then forwarding
> the relevant zones to your authoritative servers is a better solution than
> slaving the zones.
>
But the server that is forwarding to the authoritative also caches the
response, so that won't help. I'm looking for
So, if I understand you correctly, if I were to sign my authoritative
zone and my caching nameserver, which is "bogus" for this zone, is
dnssec enabled, and also validating, and no other validating
nameserver is querying this bogus nameserver, then it's OK?
cv
On Thu, May 19, 2011 at 11:16 PM, Ma
Hi all,
> If you're saying that you shouldn't *offer* recursive and authoritative
> services on the same box, then I generally agree. If you're saying that you
> shouldn't ever prime your cache with a zone, or have a recursive server be a
> slave to anything, then I'd say it gets kind of hairy t
Hi all,
> If you're saying that you shouldn't *offer* recursive and authoritative
> services on the same box, then I generally agree. If you're saying that you
> shouldn't ever prime your cache with a zone, or have a recursive server be a
> slave to anything, then I'd say it gets kind of hairy t
-Original Message-
> From: dns-operations-boun...@lists.dns-oarc.net
> [mailto:dns-operations-boun...@lists.dns-oarc.net] On Behalf Of Carlos Vicente
> Sent: Thursday, May 19, 2011 1:58 PM
> To: bind-users@lists.isc.org; dns-operati...@lists.dns-oarc.net
> Subject: [dns-oper
Dear lists [apologies if you receive two copies of this message],
I am in the process of implementing anycast recursive DNS service for
our campus using a combination of servers running Bind 9.8.0 and Cisco's
IP SLA feature. There are three identical Redhat servers connected to
three different rou
Just had one of our authoritative servers crash with a similar error:
17-Feb-2011 10:28:18.814 general: critical: rbtdb.c:1566:
INSIST(((unsigned int)((&(node)->references)->refs)) == 0 && node->data
== ((void *)0)) failed
17-Feb-2011 10:28:18.838 general: critical: exiting (due to assertion
failu
It is possible. I found that named wasn't logging to the configured
/var/log/named because logrotate failed to reload named after creating
the new file. If rndc stop was timing out because the daemon was trying
to write to the log file, then it could have been a catch 22 situation.
I have since re
Has anybody had this problem?
# /etc/init.d/named restart
Stopping named: . [FAILED]
Starting named: named: already running [ OK ]
I notice it happens after the daemon has been running for a while. If I
kill it and start it again, the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My understanding is that you don't need this unless you're planning on
using hardware security modules. You can still generate and manage keys
without pkcs11.
See:
http://www.isc.org/software/bind/new-features/9.7
cv
Timothy Holtzen wrote:
> Has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
One of our recursive resolvers, running 9.7.0-P2, failed last Sunday
with the following:
Aug 8 04:02:39 server named[23628]: mem.c:1093:
INSIST(ctx->stats[i].gets == 0U) failed
Aug 8 04:02:39 server named[23628]: exiting (due to assertion failu
13 matches
Mail list logo
