Re: 53/TCP port unresponsive
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 , 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/mail
RE: 53/TCP port unresponsive
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 different symptoms. This was 9.5.0-P1, BTW. Thanks, CJD Curt Deslatte curtis.desla...@acs-inc.com -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 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 , Chris Buxton writes: > 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@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > ___ > 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
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. Mark In message , Chris Buxton writes: > 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@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > ___ > 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
Re: 53/TCP port unresponsive
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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
53/TCP port unresponsive
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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
