Bind 8

[Mike Silbersack]

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