Throughput drop using smaller zones

2013-02-27 Thread Stuart Browne
Hi,

I've been doing some throughput testing of BIND for both signed and non-signed 
zones of various sizes and have noticed some odd behaviour.

Using the 'dnsperf' tool to perform the testing, I see that smaller (signed) 
zones perform considerably worse than larger zones when queried with +DO.

I'm using 10 data points, but will only show 4 here as they indicate the 
extremes.  The number is of unsigned delegations before signing, with 0.05% DS 
records.  The zones were signed with NSEC3/OptOut, 10 iteration salt.

All tests were performed from the same number of client machines against the 
same name server using the same signed zones.

No. of RRs |   -DO  |   +DO 
 1,000 | 244,525 13.29% | 126,644 22.79%
 1,000,000 | 242,601 13.39% | 125,973 22.88%
 3,700,000 | 243,023 13.36% | 239,417 13.54%
20,000,000 | 240,740 13.48% | 238,346 13.60%

As can be seen, the -DO query rates are fairly stable across the different zone 
sizes (the %'s are failed queries, expected given the number of test clients).  
The +DO query rates however for the smaller zones is almost half the throughput 
of the larger zones.

This behaviour is the inverse of what I'd expect.  I was wondering if anybody 
knew of any known issue to this effect.

The following are my dnsperf command lines:
# dnsperf -f inet -s x.x.x.x -d .list -c 400 -l 60 -t 0.5 -q 500
# dnsperf -f inet -s x.x.x.x -d .list -c 400 -l 60 -t 0.5 -q 500 -D

With the thought that I was overloading the server, I tried less clients, less 
'-q', but the number stays fairly consistent around the 120K/s mark (even when 
the failures drop down to below 1%).

I'm currently using the RedHat maintained 9.8 series of BIND.  If there is no 
known issue, I'll have to come up with some other way for maintaining 
up-to-date builds on our systems.

Thanks for reading this far. ;)

Odds and Ends:
- Yes, tests were performed over a public network; repeated tests show this 
wasn't the cause
- Network was at least 1Gbit between test sites
- Configured as an auth-only server (recursion no).  The rest of configuration 
available on request.

Stuart J. Browne
Senior Unix Administrator, Network Administrator, Database Administrator
AusRegistry Pty Ltd
Level 8, 10 Queens Road
Melbourne. Victoria. Australia. 3004.
Ph:  +61 3 9866 3710
Fax: +61 3 9866 1970
Email: stuart.bro...@ausregistry.com.au
Web: www.ausregistry.com.au

The information contained in this communication is intended for the named 
recipients only. It is subject to copyright and may contain privileged and/or 
confidential information. If you are not an intended recipient you must not 
use, copy, distribute or take any action in reliance on it. If you have 
received this communication in error, please delete all copies from your system 
and notify us immediately.


___
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


How to flush MX records from the cache

2013-02-27 Thread Abdul Khader
Dear All,
Is there a way to flush MX records from the cache of a caching DNS server ?

Thanks
Abdul Khader
___
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: Problems with resolving a local tld

2013-02-27 Thread Robert Moskowitz


On 02/27/2013 08:34 PM, Mark Andrews wrote:

In message <512e31ca.5030...@htt-consult.com>, Robert Moskowitz writes:

For various testing reasons, I have been running a tld here of htt. It
has worked of old and continues to work on my new 9.8.2 Centos servers.
Problem came up from a namecaching server that 'forwards only' to my
internal server.  It cannot resolve any hosts in this tld and on the
server forwarded to I see:

Well one really shouldn't be creating one's own tlds.  That said
sign the zone and add a trust anchor (managed-keys/trusted-keys)
for it.  The validator won't ask the root zone for the DS records
from the zone once you do that.


So I get to dive into zone signing slightly before I wanted to. Well 
time to get my feet wet!



Anything from 9.3.0 onwards can sign modern ones.  If you want NSEC3
the 9.6.0 onwards.


The 9.6.2 server has a bunch of cruft on it that makes it hard to muck 
with.  It is scheduled for replacement as well, but it is last on the 
list.  Maybe just signing the tld will 'fix' this for now.





Feb 27 11:16:14 rigel named[9294]: error (chase DS servers) resolving
'htt-consult.com/DS/IN': 208.83.67.188#53

Something not fully dnssec aware in the resolution path?


Probably.  NetSol is my registry...

Time to unlock it and move 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


Re: Problems with resolving a local tld

2013-02-27 Thread Mark Andrews

In message <512e31ca.5030...@htt-consult.com>, Robert Moskowitz writes:
> For various testing reasons, I have been running a tld here of htt. It 
> has worked of old and continues to work on my new 9.8.2 Centos servers.  
> Problem came up from a namecaching server that 'forwards only' to my 
> internal server.  It cannot resolve any hosts in this tld and on the 
> server forwarded to I see:

Well one really shouldn't be creating one's own tlds.  That said
sign the zone and add a trust anchor (managed-keys/trusted-keys)
for it.  The validator won't ask the root zone for the DS records
from the zone once you do that.

Anything from 9.3.0 onwards can sign modern ones.  If you want NSEC3
the 9.6.0 onwards.

> Feb 27 11:16:14 rigel named[9294]: error (chase DS servers) resolving 
> 'htt-consult.com/DS/IN': 208.83.67.188#53

Something not fully dnssec aware in the resolution path?

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


Re: allow-recursion slowing server to crawl

2013-02-27 Thread Mark Andrews

In message <512e97aa.2020...@argontech.net>, "Marco C. Coelho" writes:
> Just so the list has the same answer,
> 
> Mark Andrews was right.
> This server was being hammered so hard that logging the rejects was 
> killing the performance.
> adding:
> logging {
>category default { null; };
>//category lame-servers { null; };
> };
> 
> to named.conf fixed the performance issues.

That was a bit of over kill.  I said kill the security category not every
category.   When you do that you are driving blind.

category security { null; };
 
> mc
> 
> On 2/27/2013 5:18 PM, Mark Andrews wrote:
> > I suspect this is just logging. send the security channel to null;
> > for a while.  Once your server gets off the I'm a recursive reflector
> > lists you can turn it on again.
> >
> > In message <512e7940.7060...@argontech.net>, "Marco C. Coelho" writes:
> >> I discovered my bind 9 server was being used in a DDOS attack so I
> >> decided (late) to block outside networks from making recursive
> >> requests.  The problem is every time I enable this, the time for DNS
> >> queries goes from 0-1ms to 2000-6000ms or just times out completely.
> >> The options section is below. I've commented it out so as to enable my
> >> network to run.
> >>
> >> There are thousands of my clients that need recursion from this server.
> >> It is also authoritative for many domains.
> >>
> >> There is a semi busy mail server on this same box that uses DNS as well.
> >>
> >> I googled this to death with no real suggestions.  I've tried it with
> >> ACL and without.
> >>
> >> Any suggestions would be appreciated.
> >>
> >> Marco
> >>
> >> acl "internal" {
> >> 24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8; "localnets"; "localhost";
> >> };
> >>
> >> options {
> >> directory "/var/named";
> >> /*
> >>  * If there is a firewall between you and nameservers you want
> >>  * to talk to, you might need to uncomment the query-source
> >>  * directive below.  Previous versions of BIND always asked
> >>  * questions using port 53, but BIND 8.1 uses an unprivileged
> >>  * port by default.
> >>  */
> >> // query-source address * port 53;
> >> recursive-clients 1000;
> >> recursion yes;
> >> //allow-query { any; };
> >> //allow-recursion { 24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8;
> >> "localnets"; "localhost"; };
> >> //allow-recursion { "internal"; };
> >> //allow-query-cache { 24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8;
> >> "localnets"; "localhost"; };
> >> listen-on-v6 { none; };
> >> listen-on { 24.202.224.2; };
> >> version "8.2.3-REL";
> >> };
> >>
> >> -- 
> >> Argon Technologies Inc.
> >> Marco Coelho, President, CEO
> >> POB 875
> >> 4612 Wesley St.
> >> Greenville, TX 75402
> >> 903-455-5036
> >> 903-455-2115 Fax
> >>
> >> ___
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr
> ibe
> >>   from this list
> >>
> >> bind-users mailing list
> >> bind-users@lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/bind-users
> 
> -- 
> Argon Technologies Inc.
> Marco Coelho, President, CEO
> POB 875
> 4612 Wesley St.
> Greenville, TX 75402
> 903-455-5036
> 903-455-2115 Fax
> 
> ___
> 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: allow-recursion slowing server to crawl

2013-02-27 Thread Vernon Schryver
> From: "Marco C. Coelho"

> Mark Andrews was right.
> This server was being hammered so hard that logging the rejects was 
> killing the performance.
> adding:
> logging {
>category default { null; };
>//category lame-servers { null; };
> };


> On 2/27/2013 5:18 PM, Mark Andrews wrote:
> > I suspect this is just logging. send the security channel to null;
> > for a while.  Once your server gets off the I'm a recursive reflector
> > lists you can turn it on again.

> >> I discovered my bind 9 server was being used in a DDOS attack so I
> >> decided (late) to block outside networks from making recursive
> >> requests.  The problem is every time I enable this, the time for DNS
> >> queries goes from 0-1ms to 2000-6000ms or just times out completely.

> >> There are thousands of my clients that need recursion from this server.
> >> It is also authoritative for many domains.
> >>
> >> There is a semi busy mail server on this same box that uses DNS as well.

Turning off recursion for outsiders while allowing them authoritative
responses might not entirely stop the use of a DNS server reflection
attacks.  If the server is one of the ones I suspect, then even with
recursion for outsiders turned off, it is remains useful for about 6X
amplification in a reflection attack.  That's enough lower than the
10X or even 50X available from some others that the bad guys might
demote it.  However, many of those have been fixed or are being fixed.

To really stop reflection DoS problem, I would install a current version
of BIND and then the RRL patch with RRL enabled for external DNS clients
and disabled for internal clients.  See http://www.redbarn.org/dns/ratelimits

If RRL is too radical or can't be installed immediately, I'd still
get away from BIND8.  See https://www.isc.org/software/bind/security
and https://www.isc.org/software/bind8/security/matrix


Vernon Schryverv...@rhyolite.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: BIND roadmap

2013-02-27 Thread Mark Andrews

In message ,
 wbr...@e1b.org writes:
> Congrats to ISC and everyone that has worked on BIND 10!
> 
> I am building new name servers and redesigning our infrastructure with an 
> eye towards streamlining, improving security and implementing DNSSEC.  I 
> had been testing a few things with BIND 9.9.x.  Now that BIND 10 is 
> released, I am wondering which way to go.  Will ISC continue to develop 
> the BIND 9 code stream?  I saw a mention of RRL being added to 9.10, but 
> how long will development continue before hitting ESV?

BIND 10 is still a way off being a replacement for BIND 9.  Development
for both is still proceeding in parallel.  BIND 9 is still the
server to install for production.  BIND 10 is more for test
environments at this stage though we would like people to play with
it give feedback (good or bad).  As of BIND 9.9.3, BIND 9.9 will be
a extended support version.  BIND 9.9.0 was released March 2012
so it will be supported until March 2016 and perhaps further as per
the software support policy.

https://www.isc.org/wordpress/software/software-support-policy/

> William Brown
> Core Hosted Application Technical Team and Messaging Team
> Technology Services, WNYRIC, Erie 1 BOCES
> (716) 821-7285
-- 
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: allow-recursion slowing server to crawl

2013-02-27 Thread Marco C. Coelho

Just so the list has the same answer,

Mark Andrews was right.
This server was being hammered so hard that logging the rejects was 
killing the performance.

adding:
logging {
  category default { null; };
  //category lame-servers { null; };
};

to named.conf fixed the performance issues.

mc

On 2/27/2013 5:18 PM, Mark Andrews wrote:

I suspect this is just logging. send the security channel to null;
for a while.  Once your server gets off the I'm a recursive reflector
lists you can turn it on again.

In message <512e7940.7060...@argontech.net>, "Marco C. Coelho" writes:

I discovered my bind 9 server was being used in a DDOS attack so I
decided (late) to block outside networks from making recursive
requests.  The problem is every time I enable this, the time for DNS
queries goes from 0-1ms to 2000-6000ms or just times out completely.
The options section is below. I've commented it out so as to enable my
network to run.

There are thousands of my clients that need recursion from this server.
It is also authoritative for many domains.

There is a semi busy mail server on this same box that uses DNS as well.

I googled this to death with no real suggestions.  I've tried it with
ACL and without.

Any suggestions would be appreciated.

Marco

acl "internal" {
24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8; "localnets"; "localhost";
};

options {
directory "/var/named";
/*
 * If there is a firewall between you and nameservers you want
 * to talk to, you might need to uncomment the query-source
 * directive below.  Previous versions of BIND always asked
 * questions using port 53, but BIND 8.1 uses an unprivileged
 * port by default.
 */
// query-source address * port 53;
recursive-clients 1000;
recursion yes;
//allow-query { any; };
//allow-recursion { 24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8;
"localnets"; "localhost"; };
//allow-recursion { "internal"; };
//allow-query-cache { 24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8;
"localnets"; "localhost"; };
listen-on-v6 { none; };
listen-on { 24.202.224.2; };
version "8.2.3-REL";
};

--
Argon Technologies Inc.
Marco Coelho, President, CEO
POB 875
4612 Wesley St.
Greenville, TX 75402
903-455-5036
903-455-2115 Fax

___
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


--
Argon Technologies Inc.
Marco Coelho, President, CEO
POB 875
4612 Wesley St.
Greenville, TX 75402
903-455-5036
903-455-2115 Fax

___
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: allow-recursion slowing server to crawl

2013-02-27 Thread Mark Andrews

I suspect this is just logging. send the security channel to null;
for a while.  Once your server gets off the I'm a recursive reflector
lists you can turn it on again.

In message <512e7940.7060...@argontech.net>, "Marco C. Coelho" writes:
> 
> I discovered my bind 9 server was being used in a DDOS attack so I 
> decided (late) to block outside networks from making recursive 
> requests.  The problem is every time I enable this, the time for DNS 
> queries goes from 0-1ms to 2000-6000ms or just times out completely.  
> The options section is below. I've commented it out so as to enable my 
> network to run.
> 
> There are thousands of my clients that need recursion from this server.  
> It is also authoritative for many domains.
> 
> There is a semi busy mail server on this same box that uses DNS as well.
> 
> I googled this to death with no real suggestions.  I've tried it with 
> ACL and without.
> 
> Any suggestions would be appreciated.
> 
> Marco
> 
> acl "internal" {
>24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8; "localnets"; "localhost";
> };
> 
> options {
>directory "/var/named";
>/*
> * If there is a firewall between you and nameservers you want
> * to talk to, you might need to uncomment the query-source
> * directive below.  Previous versions of BIND always asked
> * questions using port 53, but BIND 8.1 uses an unprivileged
> * port by default.
> */
>// query-source address * port 53;
>recursive-clients 1000;
>recursion yes;
>//allow-query { any; };
>//allow-recursion { 24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8; 
> "localnets"; "localhost"; };
>//allow-recursion { "internal"; };
>//allow-query-cache { 24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8; 
> "localnets"; "localhost"; };
>listen-on-v6 { none; };
>listen-on { 24.202.224.2; };
>version "8.2.3-REL";
> };
> 
> -- 
> Argon Technologies Inc.
> Marco Coelho, President, CEO
> POB 875
> 4612 Wesley St.
> Greenville, TX 75402
> 903-455-5036
> 903-455-2115 Fax
> 
> ___
> 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


allow-recursion slowing server to crawl

2013-02-27 Thread Marco C. Coelho


I discovered my bind 9 server was being used in a DDOS attack so I 
decided (late) to block outside networks from making recursive 
requests.  The problem is every time I enable this, the time for DNS 
queries goes from 0-1ms to 2000-6000ms or just times out completely.  
The options section is below. I've commented it out so as to enable my 
network to run.


There are thousands of my clients that need recursion from this server.  
It is also authoritative for many domains.


There is a semi busy mail server on this same box that uses DNS as well.

I googled this to death with no real suggestions.  I've tried it with 
ACL and without.


Any suggestions would be appreciated.

Marco

acl "internal" {
  24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8; "localnets"; "localhost";
};

options {
  directory "/var/named";
  /*
   * If there is a firewall between you and nameservers you want
   * to talk to, you might need to uncomment the query-source
   * directive below.  Previous versions of BIND always asked
   * questions using port 53, but BIND 8.1 uses an unprivileged
   * port by default.
   */
  // query-source address * port 53;
  recursive-clients 1000;
  recursion yes;
  //allow-query { any; };
  //allow-recursion { 24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8; 
"localnets"; "localhost"; };

  //allow-recursion { "internal"; };
  //allow-query-cache { 24.202.224.0/20; 127.0.0.0/8; 10.0.0.0/8; 
"localnets"; "localhost"; };

  listen-on-v6 { none; };
  listen-on { 24.202.224.2; };
  version "8.2.3-REL";
};

--
Argon Technologies Inc.
Marco Coelho, President, CEO
POB 875
4612 Wesley St.
Greenville, TX 75402
903-455-5036
903-455-2115 Fax

___
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: disabling lame server logging

2013-02-27 Thread Manson, John
Syslog-ng
Use the named default logging.

John Manson
CAO/HIR/NAF Data-Communications | U.S. House of Representatives | Washington, 
DC 20515
Desk: 202-226-4244 | TCC: 202-226-6430 | 
john.man...@mail.house.gov

___
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

Problems with resolving a local tld

2013-02-27 Thread Robert Moskowitz
For various testing reasons, I have been running a tld here of htt. It 
has worked of old and continues to work on my new 9.8.2 Centos servers.  
Problem came up from a namecaching server that 'forwards only' to my 
internal server.  It cannot resolve any hosts in this tld and on the 
server forwarded to I see:


htt. is mastered on my servers and home.htt is slaved off of old server 
(that will get upgraded later).  The host I want to access is 
repo.home.htt.  From my 'regular' DNS servers this works well, but from 
the namecaching server that 'forwards only' to this server I get on the 
caching server:


Feb 27 09:52:48 klovia named[1703]: error (insecurity proof failed) 
resolving 'repo.home.htt//IN': 208.83.67.188#53
Feb 27 09:52:48 klovia named[1703]: error (insecurity proof failed) 
resolving 'repo.home.htt/A/IN': 208.83.67.188#53


and on the main server (at 208.83.67.188) I see:

Feb 27 09:52:47 rigel named[9294]: error (chase DS servers) resolving 
'htt/DS/IN': 208.83.67.188#53


what little research I have done directs me to htt is not signed? Of 
course home.htt is not either as that server is rather old (bind 9.6.2)


Interestingly when 208.83.67.188 does a lookup in my regular domain I see:

Feb 27 11:16:14 rigel named[9294]: error (chase DS servers) resolving 
'htt-consult.com/DS/IN': 208.83.67.188#53


So what am I missing here?


___
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


High IOWAIT when running multiple rndc addzone / delzone causing dropped queries

2013-02-27 Thread Another Email
Hello,

I was wondering if someone on this list can assist me in figuring this out.  I 
am trying to run the rndc addzone / delzone for many domains at once on a set 
of name servers.  When this is done the the load on the box goes very high, and 
the process just slows right down to a halt (dropping queries).

I am basically wondering if there are certain settings that I can change in 
order to run BIND more efficiently.


Linux kernel: 3.1.10  x86_64 Intel(R) Xeon(R) CPU E3110 @ 3.00GHz GenuineIntel 
GNU/Linux


At the time when I run the rndc addzone / delzone commands I will see this:
Cpu(s):  0.3%us,  1.8%sy,  0.0%ni,  9.7%id, 88.2%wa,  0.0%hi,  0.0%si,  0.0%st



I believe I have given named enough possible file handlers.
# lsof -n | grep named | wc -l
1232
# su - named
named@b1123 / $ ulimit -Hn
65536
named@b1123 / $ ulimit -Sn
65536


When I strace the different threads I notice that one thread is constantly 
redoing the 3bf305731dd26307.nzf and reading the JNL files.  Another thread is 
just spewing out as fast as possible the following:
futex(0x7ff72930e07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
677931537, {1361978981, 779057000}, ) = -1 ETIMEDOUT (Connection
timed out)
futex(0x7ff72930e028, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7ff72930e07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
677931539, {1361978981, 89129}, ) = -1 ETIMEDOUT (Connection
timed out)
futex(0x7ff72930e028, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7ff72930e07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
677931541, {1361978982, 44187000}, ) = -1 ETIMEDOUT (Connection
timed out)
futex(0x7ff72930e028, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7ff72930e07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
677931543, {1361978982, 100744000}, ) = -1 ETIMEDOUT (Connection
timed out)
futex(0x7ff72930e028, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7ff72930e07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
677931545, {1361978982, 266914000}, ) = 0
futex(0x7ff72930e028, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x7ff72930e028, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7ff72930e07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
677931547, {1361978982, 186681000}, ) = -1 ETIMEDOUT (Connection
timed out)
futex(0x7ff72930e028, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7ff72930e07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
677931549, {1361978982, 206752000}, ) = -1 ETIMEDOUT (Connection
timed out)
futex(0x7ff72930e028, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7ff72930e07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
677931551, {1361978982, 226846000}, ) = -1 ETIMEDOUT (Connection
timed out)
futex(0x7ff72930e028, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7ff72930e07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
677931553, {1361978982, 24694}, ) = -1 ETIMEDOUT (Connection
timed out)
futex(0x7ff72930e028, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7ff72930e07c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
677931555, {1361978982, 266914000}, ) = -1 ETIMEDOUT (Connection
timed out) 


Please let me know what you may think I need to do. 
Thank you!
-Ted
___
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


BIND roadmap

2013-02-27 Thread WBrown
Congrats to ISC and everyone that has worked on BIND 10!

I am building new name servers and redesigning our infrastructure with an 
eye towards streamlining, improving security and implementing DNSSEC.  I 
had been testing a few things with BIND 9.9.x.  Now that BIND 10 is 
released, I am wondering which way to go.  Will ISC continue to develop 
the BIND 9 code stream?  I saw a mention of RRL being added to 9.10, but 
how long will development continue before hitting ESV?


-- 

William Brown
Core Hosted Application Technical Team and Messaging Team
Technology Services, WNYRIC, Erie 1 BOCES
(716) 821-7285




Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.
___
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: disabling lame server logging

2013-02-27 Thread Cathy Almond
On 26/02/13 21:34, Bryan Harris wrote:
> Hi Robert,
> 
> On Feb 26, 2013, at 2:23 PM, Robert Moskowitz  wrote:
> 
>>
>> On 02/26/2013 01:57 PM, Doug Barton wrote:
>>> On 02/26/2013 10:38 AM, Robert Moskowitz wrote:
 I would like a scalpel for lame logging, but probably would not discover
 any actionable data.
>>>
>>> There is a logging category for lame-servers. It's in the ARM.
>>
>> So far 2 reads and I am not getting out of it what to do for selective 
>> logging based on return codes.  I am going to let it stay for now as I move 
>> on to other parts of this project.
> 
> Perhaps you want something outside of bind; e.g. The rsyslog software can 
> exclude/filter based on regex. Just a thought. 
> 
> Bryan

It may not do quite what you want - but have a look at the query-errors
logging category.

To use it, you need run named with a debug level of 1 or higher, so
you'll need to look at configuring more granular logging overall so that
you don't get that level of logging from other categories too (unless
you'd like to collect that anyway) and you might prefer to log this
category to a separate file.

Anyway - all documented in the ARM which you can find in your
distribution source code tarball, or for the most recent ARMs - here:
https://kb.isc.org/category/116/0/10/Software-Products/BIND9/Documentation/

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