In message <7caf9cc3b3625c46adb0a816877f5916f89...@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.desla...@acs-inc.com > > =20 > > > -----Original Message----- > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark Andrews > Sent: Friday, April 03, 2009 1:08 PM > To: Chris Buxton > Cc: bind-users@lists.isc.org; bind-work...@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-3d547c3ea...@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@lists.isc.org > > > https://lists.isc.org/mailman/listinfo/bind-users > >=20 > > _______________________________________________ > > 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: mark_andr...@isc.org > _______________________________________________ > 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: mark_andr...@isc.org _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users