bind 9.6.2 with threads hangs
Hi, We have several recursive cache bind servers and experiencing weird things when named is compiled with-threads: In 4 steps: 1) everything goes ok 2) for ~1h named began to answer slower (0,5ms to 100ms) and with symptoms: - load increase on the server (from 0,3 to 4) - number of recursive queries increase (+500%) - number of recursive slot increase (from 200 to 600) - cache hit decrease (from 9X% to - number of cache entries drops from 2M to 0 3) named answer no query - no recursive queries - 0 entry in cache - rndc stats/status works 4) We flush the named cache (rndc flush) and everything goes ok We do a rndc stats every minute to get some stats. Hardware: - intel or amd with a total of 4 or 8 cores - solaris 10 - bind 9.6.2 with threads (gcc) or bind 9.5.1-P3 with threads (SUNWspro) any clue ? some numbers from named.stats : ++ Name Server Statistics ++ 437118882 IPv4 requests received ++ Zone Maintenance Statistics ++ ++ Resolver Statistics ++ 120096973 IPv4 queries sent 29784114 queries with RTT 10ms 49289542 queries with RTT 10-100ms 33448291 queries with RTT 100-500ms 277957 queries with RTT 500-800ms 105059 queries with RTT 800-1600ms 31079 queries with RTT 1600ms [View: _bind] ++ Socket I/O Statistics ++ 120075062 UDP/IPv4 sockets opened 35059 TCP/IPv4 sockets opened 120074870 UDP/IPv4 sockets closed 42651 TCP/IPv4 sockets closed 13116 UDP/IPv4 socket bind failures 5513 TCP/IPv4 socket connect failures 120061921 UDP/IPv4 connections established 6901 TCP/IPv4 connections established 7599 TCP/IPv4 connections accepted 276089 UDP/IPv4 recv errors 315 TCP/IPv4 recv errors ++ Cache DB RRsets ++ [View: mire] [View: abonnes] 885677 A 751488 NS 171869 CNAME 144655 PTR 312051 MX 41667 RRSIG 38816 NSEC 130572 NXDOMAIN -- Fabien ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.6.2 with threads hangs
BIND has long had issues with threading since it started supporting threaded operation. I recommend you simply recompile without thread support. I retry compiling with thread support about twice a year and as of late last year, BIND still hung soon after restart with threading enabled. -david On 03/19/2010 09:09 AM, Fabien Seisen wrote: Hi, We have several recursive cache bind servers and experiencing weird things when named is compiled with-threads: [...] -- Linux: freedom to build is good Please top-post and trim when replying to my messages. I most often read mail on a small device. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
T_ANY
I posted this to the postfix users list:
One of my users had problems receiving from Yahoo a couple days ago. The sender
(in FLA) got this:
From: mailer-dae...@yahoo.com mailer-dae...@yahoo.com
To: xx...@yahoo.com
Sent: Sun, March 7, 2010 5:51:09 PM
Subject: failure notice
Hi. This is the qmail-send program at yahoo.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
xx...@slsware.com:
CNAME lookup failed temporarily. (#4.4.3)
I'm not going to try again; this message has been in the queue too long.
I got responses saying that the problem was that my DNS ignores
'dig @ns1.slsware.com -t any slsware.com' (or 'dig +trace -t any slsware.com')
and indeed it does, from outside. From inside it's fine, and '-t MX' works from
anywhere. Yahoo's MTA (qmail) does T_ANY lookups, so it thinks there's nobody
home at my nameserver. But I can't get anybody over on the postfix list to
suggest what might be wrong. I spent the morning with google, and couldn't find
anything that looked like it might be the answer.
The obvious answer is firewalling, but I don't think that's it. A query from
inside goes through the same PIX firewall as would a query from outside; the
pix is configured no fixup protocol dns; I don't think IOS in the router
knows anything about what type of DNS query is coming in; and the same query to
the other nameserver ('dig @ns1.richeyrentals.com -t any slsware.com') also
fails. That one's also behind a PIX, but has a non-IOS router.
Both servers are Debian lenny, 'named -v' says BIND 9.5.1-P3, and bind's config
check says it's OK. But it has nothing to do with any of that, I think, because
the query works from inside.
Any ideas?
--
Glenn English
g...@slsware.com
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: T_ANY
Maybe it's a difference between udp and tcp in your firewall?
For most queries udp 53 is used but for long packets it might switch to
tcp 53 - since you're doing an any you're going to get a lot more data.
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
Of Glenn English
Sent: Friday, March 19, 2010 4:13 PM
To: bind-users@lists.isc.org
Subject: T_ANY
I posted this to the postfix users list:
One of my users had problems receiving from Yahoo a couple days ago. The
sender (in FLA) got this:
From: mailer-dae...@yahoo.com mailer-dae...@yahoo.com
To: xx...@yahoo.com
Sent: Sun, March 7, 2010 5:51:09 PM
Subject: failure notice
Hi. This is the qmail-send program at yahoo.com.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
xx...@slsware.com:
CNAME lookup failed temporarily. (#4.4.3)
I'm not going to try again; this message has been in the queue too
long.
I got responses saying that the problem was that my DNS ignores
'dig @ns1.slsware.com -t any slsware.com' (or 'dig +trace -t any
slsware.com')
and indeed it does, from outside. From inside it's fine, and '-t MX'
works from anywhere. Yahoo's MTA (qmail) does T_ANY lookups, so it
thinks there's nobody home at my nameserver. But I can't get anybody
over on the postfix list to suggest what might be wrong. I spent the
morning with google, and couldn't find anything that looked like it
might be the answer.
The obvious answer is firewalling, but I don't think that's it. A query
from inside goes through the same PIX firewall as would a query from
outside; the pix is configured no fixup protocol dns; I don't think
IOS in the router knows anything about what type of DNS query is coming
in; and the same query to the other nameserver ('dig
@ns1.richeyrentals.com -t any slsware.com') also fails. That one's also
behind a PIX, but has a non-IOS router.
Both servers are Debian lenny, 'named -v' says BIND 9.5.1-P3, and bind's
config check says it's OK. But it has nothing to do with any of that, I
think, because the query works from inside.
Any ideas?
--
Glenn English
g...@slsware.com
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: T_ANY
From: Glenn English g...@slsware.com Date: Fri, 19 Mar 2010 15:15:38 -0600 Sender: bind-users-bounces+oberman=es@lists.isc.org On Mar 19, 2010, at 2:30 PM, Lightner, Jeff wrote: Maybe it's a difference between udp and tcp in your firewall? For most queries udp 53 is used but for long packets it might switch to tcp 53 - since you're doing an any you're going to get a lot more data. Don't think so. The router's border acl just blocks spoofers and noise, and... the router's to-inside acl: 120 permit tcp any gt 1023 host 209.97.231.218 eq domain (118155 matches) the pix' from-outside acl: 29 permit tcp any host 209.97.231.218 eq domain (hitcnt=118062) and the iptables filter on the host itself is turned off. And telnet to port 53 works -- to both nameservers, from inside or outside. ... I thought maybe the restriction to remote ports over 1023 might have been it, so I removed it. Nope. It seems to me that there are 3 questions: Can bind tell the difference between inside and outside queries for T_ANY? Can the PIX? Can IOS even tell if this is a T_ANY DNS query? And, of course, there's the question I haven't thought of whose answer will fix my problem... PIX, you say? They used to have a problem with DNS UDP packets over 512 bytes. (Well, it didn't have a problem, it just blocked them. I'm not sure what, if any code version fixes this. (I don't have any these days.) If this has not been fixed, that might explain it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: T_ANY
On Mar 19, 2010, at 3:35 PM, Kevin Oberman wrote: PIX, you say? They used to have a problem with DNS UDP packets over 512 bytes. (Well, it didn't have a problem, it just blocked them. I'm not sure what, if any code version fixes this. (I don't have any these days.) 6.3 fixed it. The command is fixup protocol dns min_length nnn. It was indeed the PIX, though ip audit signature 6053 disable allows T_ANY DNS queries. By default sig 6053 blocks T_ANY on the outside interface... Thank you all for your suggestions. -- Glenn English g...@slsware.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
how to ignore external queries?
Hello everyone, I'm currently using an ACL for allow-query statement, which I thought it's fine. Recently I did a spoofability test on: https://www.grc.com/dns/dns.htm and the results came up with a statement that External Queries are REJECTED and It would be better for it to ignore external queries. Question is... How can I IGNORE External Queries instead of Rejecting them? Thank you in advance for any idea, Julian ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
