Date: Tue, 25 Oct 2005 02:28:33 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Anton Bester <extech@dod.co.za> Cc: freebsd-net@freebsd.org Subject: Re: Bind 8 Message-ID: <20051025022412.X911@odysseus.silby.com> In-Reply-To: <200510181954020250.00A66152@196.25.53.68> References: <200510181954020250.00A66152@196.25.53.68>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Oct 2005, Anton Bester wrote: > Hi All, > > I do not know if this is the correct forum for this questions, if not please point me in the right direction. > > My secondary DNS server all of a sudden started to chop up about 100% of > my server's cpu, I'm running a FreeBSD 5.1-RELEASE server with Bind 8. > It was doning fine until I noticed that the sever's cpu running near > 100%, it turned out to be bind. > > When I restart bind it takes a couple of minutes but then it is back at > 70% - 100% with a lot of traffic being send to my primary DNS server, I > have noticed the following error in the Primary DNS log file: > > Oct 18 12:24:01 ns /kernel: Limiting icmp unreach response from 315 to 200 packets per second > Oct 18 12:24:02 ns /kernel: Limiting icmp unreach response from 259 to 200 packets per second > Oct 18 12:24:03 ns /kernel: Limiting icmp unreach response from 223 to 200 packets per second The problems may or may not be related, a good tcpdump will be required to figure it out. Those messages appear when incoming UDP packets are destined to a port that isn't listening for responses. DNS can cause that in two ways that I can think of off the top of my head: 1. A client program makes a DNS request to DNS server. The DNS server takes a long time responding, and in the meantime the client gives up and stops listening for a response. The DNS server finally returns a response, but since the client is no longer listening, the kernel has to return an icmp unreach response. 2. Similar case - you restart DNS server A, which had a bunch of queries in to DNS server B. DNS server A is restarted, and listens for query responses on a different port than it did before. DNS B responds with all the delayed DNS responses, and the kernel has to bounce all 315 per second of them. So, BIND is the real problem here, those messages are just telling you that the kernel is limiting the number of "icmp unreach" messages to packets who have no real destination anymore. This is mostly to save bandwidth during DoS attacks. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051025022412.X911>