53/TCP port unresponsive
Curtis.Deslatte at acs-inc.com
Wed Apr 8 09:17:24 UTC 2009
This problem is very very similar to the one I posted a couple of months
ago on the list.
Since then I have found that the couple of servers where this was
frequently occurring, were misconfigured.
(I admit it, NOT proudly though; I'm only "proud" anymore on Saturday
afternoons, once I've caught up on my sleep from the previous week, and
then just barely...)
The misconfiguration was related to the use of a second master that
another admin had removed and I had not caught the deferrals that were
piling up. I had thought that each zone was going to "choose" the first
master listed, in my case the local primary, the "failover" was listed
second. It would appear that is not always the case as the master which
had been removed was the second one listed in the "master ACL" that was
being referenced by many of the PTR zones being differed!
I had been troubleshooting another issue and noticed deferrals logging
fairly regularly. I started looking into the deferred zones (i.e.
allowed myself to be rabbit trailed) and found that the zones being
deferred, were being sought out at the second listed master, not the
first where I could actually pull any of the zones manually.
In any case, I edited the master ACL, removing the MIA server, and
zapped it. The deferrals stopped (naturally) as the remaining master,
the primary, was working correctly.
I haven't experienced a "TCP seizure" since....
I now think... The cyclic nature of the seizures was related to the
backing up of deferrals, perhaps a constrained resource under the hood
somewhere? I don't know that for a fact though.
A would assume it's going to be a different cycle based on the
differences between configurations (zones, or whatever) and servers
where the presumed resource is concerned. So manifestations would be
significantly different from victim to victim. If it's actually a
resource, application or server, it may actually manifest with totally
This was 9.5.0-P1, BTW.
Curtis.deslatte at acs-inc.com
From: bind-users-bounces at lists.isc.org
[mailto:bind-users-bounces at lists.isc.org] On Behalf Of Mark Andrews
Sent: Friday, April 03, 2009 1:08 PM
To: Chris Buxton
Cc: bind-users at lists.isc.org; bind-workers at lists.isc.org
Subject: Re: 53/TCP port unresponsive
There is no such version as BIND 9.5P1.
There are both BIND 9.5.0-P1 and BIND 9.5.1-P1.
If Mark is using BIND 9.5.0-P1 then I would recommend upgrading.
In message <FD6F686B-C502-4166-8A46-3D547C3EA18A at menandmice.com>, Chris
> We've seen this repeatedly with our customers, usually evidenced by
> slaves that stop refreshing and eventually expire the zone. It seems
> to happen most on Mac OS X and Solaris, and less often (or perhaps
> never) on Linux.
> named just stops listening on the TCP port. If you execute "lsof -i:
> 53", you'll see that it's still listening on 127.0.0.1:53/TCP, but not
> on some other interface. UDP seems to be unaffected by this.
> The only solution we've found is to stop and restart named.
> Chris Buxton
> Professional Services
> Men & Mice
> On Apr 2, 2009, at 5:26 PM, Mark Koehler wrote:
> > Greetings.
> > We have 4 masters (rsync'd together) and a pair of load balancers
> > each of which distributes queries to any of the 4. On the masters,
> > we run Solaris 10 with BIND 9.5P1. Recently, one of the 4 stopped
> > using TCP on port 53, but UDP traffic continued unaffected. What
> > would cause the TCP port to stop? The port was unresponsive from
> > the backside of the load balancers, and no DNS TCP packets came from
> > the server either. Is there anything in BIND which would detect and
> > block a potential DOS attack?
> > Thanx,
> > mrak
> > _______________________________________________
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> bind-users mailing list
> bind-users at lists.isc.org
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
bind-users mailing list
bind-users at lists.isc.org
More information about the bind-users