BIND 9.2.2 recursive queries lag badly, Bind8 does not
bind...@vsfx.com
I tried searching for this in the archives and didn't see anything
conclusive.
We are an ISP with caching resolvers running BIND9.2.2 on Solaris 8 that
are not behind firewalls. Upon running scripts to test unrelated issues,
I noticed that any time I queried any of my resolvers for domains that
have not been cached, the recursive query response times are horrible --
consistently over 4 seconds. If I clear the cache and run a script that
digs over 100 random domains, all of them come back > 4 seconds. Nothing
has changed on our resolvers' config in months. Root hint file is up to
date. Dig +trace or debug isn't showing anything. Tcpdump/snoop shows
nothing, other than an empty hole when the machine is waiting for a
response back from any root server. Queries against the boxes locally vs.
queries from another machine make no difference. We have tried boxes that
have not been patched in months as well as up-to date machines. All the
same.
Here's the options we have:
options {
directory "/var/named";
/*
*
*/
max-ncache-ttl 10800;
transfers-in 25;
notify no;
allow-query { CSR; DEV; localhost; };
recursion yes;
recursive-clients 100000;
allow-transfer { none; };
interface-interval 0;
cleaning-interval 30;
blackhole { 10.0.0.0/8; 192.168.0.0/16; };
pid-file "named.pid";
};
Although I would be happy to post more info for your review, my questions
are these: Has anyone else noticed this lag in recursion recently? Can
anyone on this list try clearing their cache and then running queries for
random domains and noting the response time?
Curiously, an old BIND8 box we have does NOT experience this lag, no
matter what.
Any insight you may have is appreciated.
Thanks
-Erik J
p...@icke-reklam.ipsec.nu
> Hello List --
> I tried searching for this in the archives and didn't see anything
> conclusive.
> We are an ISP with caching resolvers running BIND9.2.2 on Solaris 8 tha=
t
> are not behind firewalls. Upon running scripts to test unrelated issue=
s,
> I noticed that any time I queried any of my resolvers for domains that
> have not been cached, the recursive query response times are horrible -=
-
> consistently over 4 seconds. If I clear the cache and run a script tha=
t
> digs over 100 random domains, all of them come back > 4 seconds. Nothi=
ng
> has changed on our resolvers' config in months. Root hint file is up t=
o
> date. Dig +trace or debug isn't showing anything. Tcpdump/snoop shows
> nothing, other than an empty hole when the machine is waiting for a
> response back from any root server. Queries against the boxes locally =
vs.
> queries from another machine make no difference. We have tried boxes t=
hat
> have not been patched in months as well as up-to date machines. All th=
e
> same.
> Here's the options we have:
> options {
> directory "/var/named";
> /*
> *
> */
> max-ncache-ttl 10800;
> transfers-in 25;
> notify no;
> allow-query { CSR; DEV; localhost; };
> recursion yes;
> recursive-clients 100000;
> allow-transfer { none; };
> interface-interval 0;
> cleaning-interval 30;
> blackhole { 10.0.0.0/8; 192.168.0.0/16; };
> pid-file "named.pid";
> };
> Although I would be happy to post more info for your review, my questio=
ns
> are these: Has anyone else noticed this lag in recursion recently? Ca=
n
> anyone on this list try clearing their cache and then running queries f=
or
> random domains and noting the response time?
> Curiously, an old BIND8 box we have does NOT experience this lag, no
> matter what.
> Any insight you may have is appreciated.
> Thanks
> -Erik J
bind-9 starts with end0 queries, if they are not answered a retry=20
without edns is attempted. This is what i understood.
--=20
Peter H=E5kanson =20
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out=
,
remove "icke-reklam" if you feel for mailing me. Thanx.
Mark Andrews
> Hello List --
>
> I tried searching for this in the archives and didn't see anything
> conclusive.
>
> are not behind firewalls. Upon running scripts to test unrelated issues,
> I noticed that any time I queried any of my resolvers for domains that
> consistently over 4 seconds. If I clear the cache and run a script that
> digs over 100 random domains, all of them come back > 4 seconds. Nothing
> has changed on our resolvers' config in months. Root hint file is up to
> date. Dig +trace or debug isn't showing anything. Tcpdump/snoop shows
> nothing, other than an empty hole when the machine is waiting for a
> queries from another machine make no difference. We have tried boxes that
> have not been patched in months as well as up-to date machines. All the
> same.
>
> Here's the options we have:
>
>
> options {
>
> directory "/var/named";
> /*
> *
> */
> max-ncache-ttl 10800;
> transfers-in 25;
> notify no;
> allow-query { CSR; DEV; localhost; };
> recursion yes;
> recursive-clients 100000;
> allow-transfer { none; };
> interface-interval 0;
> cleaning-interval 30;
> blackhole { 10.0.0.0/8; 192.168.0.0/16; };
> pid-file "named.pid";
>
> };
>
>
> are these: Has anyone else noticed this lag in recursion recently? Can
> anyone on this list try clearing their cache and then running queries for
> random domains and noting the response time?
>
> Curiously, an old BIND8 box we have does NOT experience this lag, no
> matter what.
>
> Any insight you may have is appreciated.
>
> Thanks
>
> -Erik J
Know issue which will be fixed in BIND 9.2.5/9.3.1.
Workarounds:
* upgrade to 9.3.0 and run "named -4".
* configure --disable-ipv6.
* get yourself IPv6 connectivity.
A.GTLD-SERVERS.NET and B.GTLD-SERVERS.NET now have AAAA address
and the RTT estimates are not being penalised because you don't
have IPv6 connectivity.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org