Re: High recursive client counts
In article , Jason Brandt wrote: > For now, I've disabled DNS inspection on our firewall, as it is an ancient > Cisco firewall services module, and that seems to have stabilized things, > but it's only been 30 minutes or so. Until I get a few days in, I'll keep > researching. We used to run DNS inspection on our FWSMs. We didn't notice any issues with DNS resolution per se, but we did find that turning it off dropped the FWSM CPU from ~70% to less than 30%. We're not aware of any issues that using DNS inspection might have caused. 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-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Dynamic update with bind
Dear All, Someone has resources, links or tutorial to understand and implement the dynamic update zone files with BIND Thank you! Ramanou ___ 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: Dynamic update with bind
Hi, Look at the Bind 9 ARM: https://kb.isc.org/article/AA-00845/0/BIND-9.9-Administrator-Reference-Manual-ARM.html and O’Reilly book DNS and BIND: http://shop.oreilly.com/product/9780596100575.do Best regards Banana On 26 Mar 2014, at 12:18, Ramanou Biaou wrote: > Dear All, > Someone has resources, links or tutorial to understand and implement the > dynamic update zone files with BIND > Thank you! > > Ramanou > ___ > 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 ___ 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: Dynamic update with bind
Ramanou Biaou wrote: > Someone has resources, links or tutorial to understand and implement the > dynamic update zone files with BIND If you search the web for [nsupdate howto] or [nsupdate tutorial] you should find some useful resources. If you are running BIND 9.7 or newer then it has a built-in setup for simple DNS UPDATE uses. Try adding the following line to your zone's configuration: update-policy local; Then on your master server you can run $ nsupdate -l The nsupdate man page explains the input format. For most purposes you only need to use "update add", "update delete", and "send", e.g. on my server I can type $ nsupdate -l > add example.dotat.at 3600 in a 192.0.2.4 > > ^D And my log says: 26-Mar-2014 11:44:00.603 update: info: client 127.0.0.1#43926/key local-ddns: view auth: updating zone 'dotat.at/IN': adding an RR at 'example.dotat.at' A 192.0.2.4 26-Mar-2014 11:44:00.607 notify: info: zone dotat.at/IN/auth: sending notifies (serial 2434) Tony. -- f.anthony.n.finchhttp://dotat.at/ Humber, Thames: North becoming cyclonic then east, 5 to 7, occasionally 4 later. Slight or moderate, becoming moderate or rough in Humber. Rain or showers. Good, occasionally poor. ___ 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: High recursive client counts
The code on our FWSMs isn't the latest release, so that could be part of the issue, but it's been about 16 hours now since I shut it off, and so far so good. I would say though with the other load on our firewalls, it's highly possible that they were being overloaded. Unfortunately our MRTG isn't setup to track firewall CPU, so I can't say for sure. Thanks, Jason On Wed, Mar 26, 2014 at 4:02 AM, Sam Wilson wrote: > In article , > Jason Brandt wrote: > > > For now, I've disabled DNS inspection on our firewall, as it is an > ancient > > Cisco firewall services module, and that seems to have stabilized things, > > but it's only been 30 minutes or so. Until I get a few days in, I'll > keep > > researching. > > We used to run DNS inspection on our FWSMs. We didn't notice any issues > with DNS resolution per se, but we did find that turning it off dropped > the FWSM CPU from ~70% to less than 30%. We're not aware of any issues > that using DNS inspection might have caused. > > 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-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Jason K. Brandt Systems Administrator ___ 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: Re: High recursive client counts
DNS inspection doesn't do anything useful; bind does enough validity checking. UDP inspection suffices to let return packets thru. Another thing to beware of is NAT - if you do static NAT translation for your nameservers, be sure to specify no-payload (e.g. ip nat inside source static tcp/udp 10.0.0.1 53 16.123.213.11 53 extendable no-payload ) Otherwise, the router will try to be 'helpful' by modifying the payload - which breaks quite a few things, and not necessarily in obvious ways. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. On 26-Mar-14 05:02, Sam Wilson wrote: In article , Jason Brandt wrote: For now, I've disabled DNS inspection on our firewall, as it is an ancient Cisco firewall services module, and that seems to have stabilized things, but it's only been 30 minutes or so. Until I get a few days in, I'll keep researching. We used to run DNS inspection on our FWSMs. We didn't notice any issues with DNS resolution per se, but we did find that turning it off dropped the FWSM CPU from ~70% to less than 30%. We're not aware of any issues that using DNS inspection might have caused. Sam smime.p7s Description: S/MIME Cryptographic Signature ___ 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: High recursive client counts
I had it set as: policy-map global_policy class inspection_default inspect dns maximum-length 4096 Which is what Cisco recommends. EDNS tests worked fine, but the BIND servers would still get backed up. On Wed, Mar 26, 2014 at 7:35 AM, Thom, Paul E wrote: > Do you have the FWSM DNS inspection configured to support EDNS. Not > sure if I have seen ASA / PIX code causing that problem when EDNS support > was not configured on the firewalls but it's something to look at. > > > > > > *From:* bind-users-bounces+paul.thom=dfo-mpo.gc...@lists.isc.org [mailto: > bind-users-bounces+paul.thom=dfo-mpo.gc...@lists.isc.org] *On Behalf Of *Jason > Brandt > *Sent:* March-26-14 9:09 AM > *To:* Sam Wilson > *Cc:* comp-protocols-dns-b...@isc.org > *Subject:* Re: High recursive client counts > > > > The code on our FWSMs isn't the latest release, so that could be part of > the issue, but it's been about 16 hours now since I shut it off, and so far > so good. I would say though with the other load on our firewalls, it's > highly possible that they were being overloaded. Unfortunately our MRTG > isn't setup to track firewall CPU, so I can't say for sure. > > > > Thanks, > > Jason > > -- > > Jason K. Brandt > > Systems Administrator > > > -- Jason K. Brandt Systems Administrator ___ 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: Re: High recursive client counts
We don't do any NAT at the firewall level, they're all public IPs. Thanks, Jason On Wed, Mar 26, 2014 at 7:51 AM, Timothe Litt wrote: > DNS inspection doesn't do anything useful; bind does enough validity > checking. UDP inspection suffices to let return packets thru. > > Another thing to beware of is NAT - if you do static NAT translation for > your nameservers, be sure to specify no-payload (e.g. > ip nat inside source static tcp/udp 10.0.0.1 53 16.123.213.11 53 > extendable no-payload ) > > Otherwise, the router will try to be 'helpful' by modifying the payload - > which breaks quite a few things, and not necessarily in obvious ways. > > Timothe Litt > ACM Distinguished Engineer > -- > This communication may not represent the ACM or my employer's views, > if any, on the matters discussed. > > > On 26-Mar-14 05:02, Sam Wilson wrote: > >> In article , >> Jason Brandt wrote: >> >> For now, I've disabled DNS inspection on our firewall, as it is an >>> ancient >>> Cisco firewall services module, and that seems to have stabilized things, >>> but it's only been 30 minutes or so. Until I get a few days in, I'll >>> keep >>> researching. >>> >> We used to run DNS inspection on our FWSMs. We didn't notice any issues >> with DNS resolution per se, but we did find that turning it off dropped >> the FWSM CPU from ~70% to less than 30%. We're not aware of any issues >> that using DNS inspection might have caused. >> >> Sam >> >> > > > ___ > 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 > -- Jason K. Brandt Systems Administrator ___ 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: High recursive client counts
In article , Jason Brandt wrote: > The code on our FWSMs isn't the latest release, so that could be part of > the issue, but it's been about 16 hours now since I shut it off, and so far > so good. I would say though with the other load on our firewalls, it's > highly possible that they were being overloaded. Unfortunately our MRTG > isn't setup to track firewall CPU, so I can't say for sure. Logging into your FWSM and doing 'show cpu usage' when things are going badly might be an option, but if you've got MRTG monitoring the 6500 that the FWSM is in you could also have a look at the traffic on the virtual ethernets that connect to the FWSM. Whilst they don't show up on 'show int' they and a 6 Gbps portchannel are visible to SNMP and in 'show firewall module X traffic' (or 'show firewall switch X module Y traffic' in a VSS setup).. 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-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: High recursive client counts
Here is a script I wrote to log and sent traps. I'm sure you'll have to make a
lot of changes but hopefully it can help you get started monitoring the FWSM.
You can use this as a template to expand upon.
#!/usr/bin/perl
use strict;
use Expect;
use Net::Telnet;
use Data::Dumper;
use POSIX qw(tzset);
use Data::Dumper;
use lib qw( /usr/local/rrdtool-1.2.13/lib/perl );
use RRDs;
use File::Copy;
use Net::SNMP qw(:asn1);
## quick fix for gathering codec data
## not very robust !!!
## author: Cory Cartwright corycartwri...@sbcglobal.net
##
## grab cisco FWSM cpu information for RRD graphing and SNMP trap generation
##
$ENV{TZ} = 'EDT';
POSIX::tzset();
my $createRRD = shift || 'false';
my $host = "MY6500|7600 host";
my $user = "router username";
my $pass = "router passwd";
my $fwUser = "FWSM username";
my $fwPasswd = "FWSM password";
my $comunity = "FWSM comunity string";
my $monitor = 'trap monitor IP'; # source that set and sent the trap
my @trapCatchers = qw(array of trap catchers);
my $filename = "/var/voip/fwsm_logger.txt"; #dump file
my $DBfile = '/var/voip/codecDump.csv';
my $trapThreshold = '60'; #'60'; #five sec thresh > send trap%
my $procThreshold = '30'; #'30' ; #threshhold before we capture sh proc
my %meas_hash = ( 'fiveSec' => 'fiveSec',
'oneMin' => 'oneMin',
'fiveMin' => 'fiveMin',
);
my $rrd = '/usr/voip/bin/fwcpuRRD.rrd';
if (! -e $rrd) { $createRRD = 'true'; }
my $hashRef = doExec();
if($hashRef->{'fiveSec'} >= $trapThreshold) {
#send trap
print "Sending trap\n";
sendTrap($hashRef->{'fiveSec'});
}
createRRD($rrd,\%meas_hash) if($createRRD eq 'true');
updateRRD($rrd,\%meas_hash,$hashRef);
print " struct\n" . Dumper(%meas_hash);
print " data\n" . Dumper($hashRef);
copy($rrd,"/var/www/voipdata/fwcpuRRD.rrd");
sub doExec {
my $exp = new Expect;
#$exp->log_stdout(1);
$exp->log_file("$filename");
my $command = "ssh -l $fwUser $host";
$exp->spawn($command) or die "Could not spawn $command $!";
my $string = qr/passwd/;
my $return = $exp->expect(3, "$string");
$exp->send("$pass\n");
$return = $exp->expect(3, '7604-nh1>');
$exp->send("session slot 3 pro 1\n");
$return = $exp->expect(3, /Password:/);
$exp->send("x1c2v3\n");
$return = $exp->expect(3, 'sipsfw>');
$exp->send("enable\n");
$return = $exp->expect(3, "$string");
$exp->send("$fwPasswd\n");
$return = $exp->expect(3, 'sipsfw#');
$exp->send("sh cpu\n");
$exp->expect(2);
my $cpu = $exp->before();
$cpu = $exp->before();
my %cpu = ();
if($cpu =~
/\d\sseconds\s=\s(\d+)\%\;\s\d\sminute\:\s(\d+)\%\;\s\d\sminutes\:\s(\d+)\%/g) {
$cpu{'fiveSec'} = $1;
$cpu{'oneMin'} = $2;
$cpu{'fiveMin'} = $3;
print Dumper(%cpu);
}
if($cpu{'fiveSec'} >= $procThreshold) {
my $timestamp = "\nBEGIN: TIME: " . time . " !! " . localtime(time) .
"\n### CPU 5 sec " . $cpu{'fiveSec'} . "\n";
$exp->print_log_file($timestamp);
$exp->send("no pager\n");
$exp->send("sh proc\n");
$exp->send("sh conn\n");
$exp->send("sh resource usage\n");
$exp->expect(3,'sipsfw#');
}
$exp->send("exit\n"); #exit enable
$exp->expect(1);
$exp->send("exit\n"); #exit fw
$exp->expect(1);
$exp->send("exit\n"); #exit switch
$exp->expect(1);
$exp->print_log_file("\nEND\n");
$exp->soft_close();
return(\%cpu);
} #end doExec
sub updateRRD {
my ($rrd,$meas_hashRef,$dataHashRef) = @_;
my $epoc = time;
my $data_string = '';
foreach my $cust (sort keys %$meas_hashRef) {
my $data = $$dataHashRef{$$meas_hashRef{$cust}} || 0;
print "Cust $cust: $data \n";
$data_string = $data_string . "$data:";
}
$data_string =~ s/:$//g;
print "rrdtool update $rrd $epoc:$data_string\n";
RRDs::updatev $rrd, $epoc .":" . $data_string;
if (my $ERROR = RRDs::error) {
warn "$0: unable to update $rrd : $ERROR";
}
} #end sub
sub createRRD {
my $starttime = time;
my $step = (5 * 60);
my ($rrd,$meas_hashRef) = @_;
print Dumper($meas_hashRef);
print "In createRRD: ($starttime,$rrd,$step,$meas_hashRef)\n";
my $DS_string = "$rrd --start $starttime --step $step ";
foreach(sort keys %{$meas_hashRef}) {
print "Key: $_\n";
$DS_string = $DS_string . "DS:$_:GAUGE:$step:U:U ";
}
$DS_string = $DS_string .
"RRA:AVERAGE:0.5:1:3000 " .
"RRA:MIN:0.5:1:3000 " .
"RRA:MAX:0.5:1:3000 " .
"RRA:LAST:0.5:1:3000 ";
print "$DS_string\n";
my $return = `/usr/voip/bin/rrdtool create $DS_string`;
print $return;
my $ERROR = RRDs::error;
die "$0: unable to create $rrd : $ERROR" if $ERROR;
}
sub sendTrap {
my $cpu = shift;
foreach my $host (@trapCatchers) {
my ($session, $error) = Net::SNMP->session(
Re: High recursive client counts
Thanks guys. I appreciate the input. I don't want to derail the list much
though, as this is supposed to be more BIND than Cisco :)
At this point my BIND installation seems to be stable, so we'll call it
case closed. We do plan on replacing our firewalls in the near future, so
hopefully we won't need to put much more effort into it. But again
appreciate all the help and suggestions, it definitely pushed me in the
right direction for finding the problem.
Jason
On Wed, Mar 26, 2014 at 12:56 PM, CARTWRIGHT, CORY C wrote:
> Here is a script I wrote to log and sent traps. I'm sure you'll have to
> make a lot of changes but hopefully it can help you get started monitoring
> the FWSM. You can use this as a template to expand upon.
>
> #!/usr/bin/perl
>
> use strict;
> use Expect;
> use Net::Telnet;
> use Data::Dumper;
> use POSIX qw(tzset);
> use Data::Dumper;
> use lib qw( /usr/local/rrdtool-1.2.13/lib/perl );
> use RRDs;
> use File::Copy;
> use Net::SNMP qw(:asn1);
>
> ## quick fix for gathering codec data
> ## not very robust !!!
> ## author: Cory Cartwright corycartwri...@sbcglobal.net
> ##
> ## grab cisco FWSM cpu information for RRD graphing and SNMP trap
> generation
> ##
>
> $ENV{TZ} = 'EDT';
> POSIX::tzset();
>
> my $createRRD = shift || 'false';
>
> my $host = "MY6500|7600 host";
> my $user = "router username";
> my $pass = "router passwd";
> my $fwUser = "FWSM username";
> my $fwPasswd = "FWSM password";
> my $comunity = "FWSM comunity string";
> my $monitor = 'trap monitor IP'; # source that set and sent the trap
> my @trapCatchers = qw(array of trap catchers);
>
> my $filename = "/var/voip/fwsm_logger.txt"; #dump file
> my $DBfile = '/var/voip/codecDump.csv';
>
> my $trapThreshold = '60'; #'60'; #five sec thresh > send trap%
> my $procThreshold = '30'; #'30' ; #threshhold before we capture sh proc
>
> my %meas_hash = ( 'fiveSec' => 'fiveSec',
> 'oneMin' => 'oneMin',
> 'fiveMin' => 'fiveMin',
> );
> my $rrd = '/usr/voip/bin/fwcpuRRD.rrd';
>
> if (! -e $rrd) { $createRRD = 'true'; }
>
> my $hashRef = doExec();
>
> if($hashRef->{'fiveSec'} >= $trapThreshold) {
> #send trap
> print "Sending trap\n";
> sendTrap($hashRef->{'fiveSec'});
> }
>
> createRRD($rrd,\%meas_hash) if($createRRD eq 'true');
> updateRRD($rrd,\%meas_hash,$hashRef);
> print " struct\n" . Dumper(%meas_hash);
> print " data\n" . Dumper($hashRef);
> copy($rrd,"/var/www/voipdata/fwcpuRRD.rrd");
>
> sub doExec {
>
>
> my $exp = new Expect;
> #$exp->log_stdout(1);
> $exp->log_file("$filename");
>
> my $command = "ssh -l $fwUser $host";
>
> $exp->spawn($command) or die "Could not spawn $command $!";
>
> my $string = qr/passwd/;
> my $return = $exp->expect(3, "$string");
>
> $exp->send("$pass\n");
>
> $return = $exp->expect(3, '7604-nh1>');
> $exp->send("session slot 3 pro 1\n");
>
> $return = $exp->expect(3, /Password:/);
> $exp->send("x1c2v3\n");
>
> $return = $exp->expect(3, 'sipsfw>');
> $exp->send("enable\n");
> $return = $exp->expect(3, "$string");
> $exp->send("$fwPasswd\n");
>
> $return = $exp->expect(3, 'sipsfw#');
> $exp->send("sh cpu\n");
> $exp->expect(2);
> my $cpu = $exp->before();
> $cpu = $exp->before();
> my %cpu = ();
> if($cpu =~
> /\d\sseconds\s=\s(\d+)\%\;\s\d\sminute\:\s(\d+)\%\;\s\d\sminutes\:\s(\d+)\%/g)
> {
> $cpu{'fiveSec'} = $1;
> $cpu{'oneMin'} = $2;
> $cpu{'fiveMin'} = $3;
> print Dumper(%cpu);
> }
> if($cpu{'fiveSec'} >= $procThreshold) {
> my $timestamp = "\nBEGIN: TIME: " . time . " !! " .
> localtime(time) . "\n### CPU 5 sec " . $cpu{'fiveSec'} . "\n";
> $exp->print_log_file($timestamp);
> $exp->send("no pager\n");
> $exp->send("sh proc\n");
> $exp->send("sh conn\n");
> $exp->send("sh resource usage\n");
> $exp->expect(3,'sipsfw#');
> }
> $exp->send("exit\n"); #exit enable
> $exp->expect(1);
> $exp->send("exit\n"); #exit fw
> $exp->expect(1);
> $exp->send("exit\n"); #exit switch
> $exp->expect(1);
> $exp->print_log_file("\nEND\n");
> $exp->soft_close();
>
> return(\%cpu);
> } #end doExec
>
>
> sub updateRRD {
> my ($rrd,$meas_hashRef,$dataHashRef) = @_;
> my $epoc = time;
> my $data_string = '';
> foreach my $cust (sort keys %$meas_hashRef) {
> my $data = $$dataHashRef{$$meas_hashRef{$cust}} || 0;
>print "Cust $cust: $data \n";
> $data_string = $data_string . "$data:";
> }
>
> $data_string =~ s/:$//g;
> print "rrdtool update $rrd $epoc:$data_string\n";
> RRDs::updatev $rrd, $epoc .":" . $data_string;
> if (my $ERROR = RRDs::error) {
> warn "$0: unable to update $rrd : $ERROR";
> }
> } #end sub
>
> sub createRRD {
> my $starttime = time;
> my $step = (5 * 60);
> my ($rrd,$meas_hashRef) = @_;
> print Dumper($meas_hashRef);
> print "In createRRD:
Re: High recursive client counts
This got me to take a look at "rndc recursing" on one of our servers.
It is disappointing that queries for the same FQDN/type/class from the same
client (different source port and query ID though) are handled individually
rather than being merged somehow. Is this because of the ID or the source
port, both, or something else?
On Wed, Mar 26, 2014 at 2:05 PM, Jason Brandt wrote:
> Thanks guys. I appreciate the input. I don't want to derail the list
> much though, as this is supposed to be more BIND than Cisco :)
>
> At this point my BIND installation seems to be stable, so we'll call it
> case closed. We do plan on replacing our firewalls in the near future, so
> hopefully we won't need to put much more effort into it. But again
> appreciate all the help and suggestions, it definitely pushed me in the
> right direction for finding the problem.
>
> Jason
>
>
> On Wed, Mar 26, 2014 at 12:56 PM, CARTWRIGHT, CORY C wrote:
>
>> Here is a script I wrote to log and sent traps. I'm sure you'll have to
>> make a lot of changes but hopefully it can help you get started monitoring
>> the FWSM. You can use this as a template to expand upon.
>>
>> #!/usr/bin/perl
>>
>> use strict;
>> use Expect;
>> use Net::Telnet;
>> use Data::Dumper;
>> use POSIX qw(tzset);
>> use Data::Dumper;
>> use lib qw( /usr/local/rrdtool-1.2.13/lib/perl );
>> use RRDs;
>> use File::Copy;
>> use Net::SNMP qw(:asn1);
>>
>> ## quick fix for gathering codec data
>> ## not very robust !!!
>> ## author: Cory Cartwright corycartwri...@sbcglobal.net
>> ##
>> ## grab cisco FWSM cpu information for RRD graphing and SNMP trap
>> generation
>> ##
>>
>> $ENV{TZ} = 'EDT';
>> POSIX::tzset();
>>
>> my $createRRD = shift || 'false';
>>
>> my $host = "MY6500|7600 host";
>> my $user = "router username";
>> my $pass = "router passwd";
>> my $fwUser = "FWSM username";
>> my $fwPasswd = "FWSM password";
>> my $comunity = "FWSM comunity string";
>> my $monitor = 'trap monitor IP'; # source that set and sent the trap
>> my @trapCatchers = qw(array of trap catchers);
>>
>> my $filename = "/var/voip/fwsm_logger.txt"; #dump file
>> my $DBfile = '/var/voip/codecDump.csv';
>>
>> my $trapThreshold = '60'; #'60'; #five sec thresh > send trap%
>> my $procThreshold = '30'; #'30' ; #threshhold before we capture sh proc
>>
>> my %meas_hash = ( 'fiveSec' => 'fiveSec',
>> 'oneMin' => 'oneMin',
>> 'fiveMin' => 'fiveMin',
>> );
>> my $rrd = '/usr/voip/bin/fwcpuRRD.rrd';
>>
>> if (! -e $rrd) { $createRRD = 'true'; }
>>
>> my $hashRef = doExec();
>>
>> if($hashRef->{'fiveSec'} >= $trapThreshold) {
>> #send trap
>> print "Sending trap\n";
>> sendTrap($hashRef->{'fiveSec'});
>> }
>>
>> createRRD($rrd,\%meas_hash) if($createRRD eq 'true');
>> updateRRD($rrd,\%meas_hash,$hashRef);
>> print " struct\n" . Dumper(%meas_hash);
>> print " data\n" . Dumper($hashRef);
>> copy($rrd,"/var/www/voipdata/fwcpuRRD.rrd");
>>
>> sub doExec {
>>
>>
>> my $exp = new Expect;
>> #$exp->log_stdout(1);
>> $exp->log_file("$filename");
>>
>> my $command = "ssh -l $fwUser $host";
>>
>> $exp->spawn($command) or die "Could not spawn $command $!";
>>
>> my $string = qr/passwd/;
>> my $return = $exp->expect(3, "$string");
>>
>> $exp->send("$pass\n");
>>
>> $return = $exp->expect(3, '7604-nh1>');
>> $exp->send("session slot 3 pro 1\n");
>>
>> $return = $exp->expect(3, /Password:/);
>> $exp->send("x1c2v3\n");
>>
>> $return = $exp->expect(3, 'sipsfw>');
>> $exp->send("enable\n");
>> $return = $exp->expect(3, "$string");
>> $exp->send("$fwPasswd\n");
>>
>> $return = $exp->expect(3, 'sipsfw#');
>> $exp->send("sh cpu\n");
>> $exp->expect(2);
>> my $cpu = $exp->before();
>> $cpu = $exp->before();
>> my %cpu = ();
>> if($cpu =~
>> /\d\sseconds\s=\s(\d+)\%\;\s\d\sminute\:\s(\d+)\%\;\s\d\sminutes\:\s(\d+)\%/g)
>> {
>> $cpu{'fiveSec'} = $1;
>> $cpu{'oneMin'} = $2;
>> $cpu{'fiveMin'} = $3;
>> print Dumper(%cpu);
>> }
>> if($cpu{'fiveSec'} >= $procThreshold) {
>> my $timestamp = "\nBEGIN: TIME: " . time . " !! " .
>> localtime(time) . "\n### CPU 5 sec " . $cpu{'fiveSec'} . "\n";
>> $exp->print_log_file($timestamp);
>> $exp->send("no pager\n");
>> $exp->send("sh proc\n");
>> $exp->send("sh conn\n");
>> $exp->send("sh resource usage\n");
>> $exp->expect(3,'sipsfw#');
>> }
>> $exp->send("exit\n"); #exit enable
>> $exp->expect(1);
>> $exp->send("exit\n"); #exit fw
>> $exp->expect(1);
>> $exp->send("exit\n"); #exit switch
>> $exp->expect(1);
>> $exp->print_log_file("\nEND\n");
>> $exp->soft_close();
>>
>> return(\%cpu);
>> } #end doExec
>>
>>
>> sub updateRRD {
>> my ($rrd,$meas_hashRef,$dataHashRef) = @_;
>> my $epoc = time;
>> my $data_string = '';
>> foreach my $cust (sort keys %$meas_hashRef) {
>> my $data = $$dataHashRef{$$meas_hashRef{$cust}} || 0;
>>print "Cust $cust: $data \n";
>> $dat
Re: High recursive client counts
In message , Scott Bertilson writes: > > This got me to take a look at "rndc recursing" on one of our servers. > > It is disappointing that queries for the same FQDN/type/class from the same > client (different source port and query ID though) are handled individually > rather than being merged somehow. Is this because of the ID or the source > port, both, or something else? What makes you think they are not merged? Named detects duplicates. It has self tuning limits on the number of simultaneous clients for the FQDN/type/class tuple dropping clients if there are too many. It also drops duplicates where the source port and address are duplicated. Named still has to reply to all the clients which is why they are on the recursing list. Mark -- 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
DNS64 and DNSSEC - AD bit not set (RFC 6147)
Hi list, Just wanted to check my understanding of BIND9's implementation of DNS64 against RFC 6147. Currently BIND9's "break-dnssec" defaults to "no" - in this configuration, a security-aware & validating recursive resolver with will never synthesise a record via DNS64 when queried with DO=1 irregardless of the CD bit. When changing "break-dnssec" to "yes", querying with DO=1 will always trigger synthesis of a DNS64 record, irregardless of the CD bit. Both of these configurations seem to conflict with the DNS64 RFC 6147, which specifies that (so long as the upstream negative and positive A responses validate) the recursive resolver can still synthesise the DNS64 when queried with DO=1 and CD=0 but must return the answer with the AD bit set. Only when queried with both DO=1 and CD=1 must it not synthesise the DNS64 . Is there any way to configure BIND9 to comply with this RFC 6147 behaviour? We're on 9.8.2, but I couldn't find anything related in the CHANGES for either 9.8 or 9.9. Thanks, Tom ___ 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: DNS64 and DNSSEC - AD bit not set (RFC 6147)
In message , Tom Lanyon wri tes: > Hi list, > > Just wanted to check my understanding of BIND9's implementation of DNS64 agai > nst RFC 6147. > > Currently BIND9's "break-dnssec" defaults to "no" - in this configuration, a > security-aware & validating recursive resolver with will never synthesise a A > AAA record via DNS64 when queried with DO=1 irregardless of the CD bit. No. If the answer is secure and DO=1 then it won't synthesis. RFC 6147 just gets DO and CD semantics completely wrong. The WG wanted there to be signaling that the client was going to validate and DNSSEC does not have such signaling. The best DNSSEC can do is DO=1 indicates that the client might validate. This is independent of CD. A validating stub resolver should send it queries with CD=0 so that the recursive server can filter out bad responses from upstream. Only if it gets SERVFAIL should it attempt the query with CD=1 in case the resolver has bad time or bad trust anchors. Named doesn't lie when DO=1 *and* it is possible to detect the lie. "break-dnssec yes;" tells named to lie even when it is possible to detect the lie. Stub resolvers don't currently set DO=1 so DNS64 synthesis happens for them. > When changing "break-dnssec" to "yes", querying with DO=1 will always trigger > synthesis of a DNS64 record, irregardless of the CD bit. > > Both of these configurations seem to conflict with the DNS64 RFC 6147, which > specifies that (so long as the upstream negative and positive A response > s validate) the recursive resolver can still synthesise the DNS64 when q > ueried with DO=1 and CD=0 but must return the answer with the AD bit set. On > ly when queried with both DO=1 and CD=1 must it not synthesise the DNS64 > . > > Is there any way to configure BIND9 to comply with this RFC 6147 behaviour? > We're on 9.8.2, but I couldn't find anything related in the CHANGES for eithe > r 9.8 or 9.9. > > Thanks, > Tom > > ___ > 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: DNS64 and DNSSEC - AD bit not set (RFC 6147)
On 27 Mar 2014, at 14:48, Mark Andrews wrote: > No. If the answer is secure and DO=1 then it won't synthesis. > > RFC 6147 just gets DO and CD semantics completely wrong. The WG > wanted there to be signaling that the client was going to validate > and DNSSEC does not have such signaling. The best DNSSEC can do > is DO=1 indicates that the client might validate. This is independent > of CD. Isn't this signalling defined as the purpose of the CD bit in RFC 4035? My naive understanding is something like: DS=1 CD=0 "I am not going to validate this, I want you to check it" DS=1 CD=1 "I am going to validate this, so I don't care if you check it" > A validating stub resolver should send it queries with CD=0 so that > the recursive server can filter out bad responses from upstream. > Only if it gets SERVFAIL should it attempt the query with CD=1 in > case the resolver has bad time or bad trust anchors. Right, this is what our current stub resolvers are doing (well, I'm not sure about the retry with CD=1 on SERVFAIL, but they're sending DS=1 CD=0 queries to our recursive resolvers). > Named doesn't lie when DO=1 *and* it is possible to detect the lie. > "break-dnssec yes;" tells named to lie even when it is possible to > detect the lie. So, what is a "lie" here? Assuming that the response received upstream (i.e. a negative and positive A response) has been validated, is inserting a synthesised for DNS64 "lying"? > Stub resolvers don't currently set DO=1 so DNS64 synthesis happens > for them. Our real-world case, and why I'm looking into this, is that our BIND 9.8.2 validating recursive resolvers are *not* returning synthesised DNS64 responses for DNSSEC signed zones because the downstream stub resolvers query with DS=1 and CD=0. This breaks connectivity from our IPv6-only clients for DNSSEC signed zones. As far as I can see, my two options are to enable break-dnssec in BIND, or disable DNSSEC validation in the stub resolvers. Are there any other options, and if not, are either of these two more preferred than the other? Tom ___ 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: DNS64 and DNSSEC - AD bit not set (RFC 6147)
In message , Tom Lanyon wri tes: > On 27 Mar 2014, at 14:48, Mark Andrews wrote: > > No. If the answer is secure and DO=1 then it won't synthesis. > > > > RFC 6147 just gets DO and CD semantics completely wrong. The WG > > wanted there to be signaling that the client was going to validate > > and DNSSEC does not have such signaling. The best DNSSEC can do > > is DO=1 indicates that the client might validate. This is independent > > of CD. > > Isn't this signalling defined as the purpose of the CD bit in RFC 4035? > > My naive understanding is something like: > > DS=1 CD=0 "I am not going to validate this, I want you to check it" > DS=1 CD=1 "I am going to validate this, so I don't care if you check it" Which is incorrect. I presume you mean DO not DS. DO=1 says "I understand DNSSEC records, send them to me if you have them" it also says "set AD as appropriate" (AD=1 can also be used to request setting AD as appropriate in the response). CD=1 says "Do not validate records from upstream if you have to make upstream queries, pass them through to me without checking" it also stop validation checks being made on other lookups needed to complete the lookup being made. Think of CD=1 as "Give me the answer even if the lookup would normally fail due to DNSSEC validation failures". There is no "I will be validating responses" on either of these. DNSSEC does not have a way to signal "I will be validating responses". The authors of RFC 6147 really wanted there to be such a signal and tried to twist the DNSSEC signaling bits into signaling this. This is like defining pi to be 3. It does not work. > > A validating stub resolver should send it queries with CD=0 so that > > the recursive server can filter out bad responses from upstream. > > Only if it gets SERVFAIL should it attempt the query with CD=1 in > > case the resolver has bad time or bad trust anchors. > > Right, this is what our current stub resolvers are doing (well, I'm not > sure about the retry with CD=1 on SERVFAIL, but they're sending DS=1 CD=0 > queries to our recursive resolvers). > > > > Named doesn't lie when DO=1 *and* it is possible to detect the lie. > > "break-dnssec yes;" tells named to lie even when it is possible to > > detect the lie. > > So, what is a "lie" here? Assuming that the response received upstream > (i.e. a negative and positive A response) has been validated, is > inserting a synthesised for DNS64 "lying"? Yes, it is lying. It's deliberate lying but it is lying. The same policy applies to othe places where named can be configured to lie. > > Stub resolvers don't currently set DO=1 so DNS64 synthesis happens > > for them. > > Our real-world case, and why I'm looking into this, is that our BIND > 9.8.2 validating recursive resolvers are *not* returning synthesised > DNS64 responses for DNSSEC signed zones because the downstream stub > resolvers query with DS=1 and CD=0. This breaks connectivity from our > IPv6-only clients for DNSSEC signed zones. > > As far as I can see, my two options are to enable break-dnssec in BIND, > or disable DNSSEC validation in the stub resolvers. Are there any other > options, and if not, are either of these two more preferred than the > other? Or teach the stub resolvers how to discover the DNS64 parameters. The sane way to do that would have been a EDNS option but the working group decided heuristics are good enough. > Tom > -- 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
