53/TCP port unresponsive

[Mark Andrews]

In message <7CAF9CC3B3625C46ADB0A816877F5916F89082 at A1DAL1SWPES16MB.ams.acs-inc.net>, "Deslatte, Curtis" writes:
> 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.=20
> 
> 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.... =20
> 
> 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
> different symptoms.

	Setting	"try-tcp-refresh no;" would have most probably fixed
	it.

> This was 9.5.0-P1, BTW.
> =20
> =20
> Thanks,
> CJD
> =20
> 
> Curt Deslatte
> Curtis.deslatte at acs-inc.com
> 
> =20
> 
> 
> -----Original Message-----
> 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=20
> 
> 
> 	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.
> 
> 	Mark
> 
> In message <FD6F686B-C502-4166-8A46-3D547C3EA18A at menandmice.com>, Chris
> Buxton writes:
> > We've seen this repeatedly with our customers, usually evidenced by=20
> > slaves that stop refreshing and eventually expire the zone. It seems=20
> > to happen most on Mac OS X and Solaris, and less often (or perhaps
> > never) on Linux.
> >=20
> > named just stops listening on the TCP port. If you execute "lsof -i:=20
> > 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.
> >=20
> > The only solution we've found is to stop and restart named.
> >=20
> > Chris Buxton
> > Professional Services
> > Men & Mice
> >=20
> > On Apr 2, 2009, at 5:26 PM, Mark Koehler wrote:
> >=20
> > > Greetings.
> > >
> > > We have 4 masters (rsync'd together) and a pair of load balancers=20
> > > each of which distributes queries to any of the 4.  On the masters,=20
> > > we run Solaris 10 with BIND 9.5P1.  Recently, one of the 4 stopped=20
> > > using TCP on port 53, but UDP traffic continued unaffected.  What=20
> > > would cause the TCP port to stop?  The port was unresponsive from=20
> > > 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
> >=20
> > _______________________________________________
> > bind-users mailing list
> > bind-users at 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: Mark_Andrews at isc.org
> _______________________________________________
> bind-users mailing list
> bind-users at 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: Mark_Andrews at isc.org