Re: Bind 8

• Previous message: Gleb Smirnoff: "Re: em(4) patch for test"
• In reply to: Anton Bester: "Bind 8"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Tue, 25 Oct 2005 02:28:33 -0500 (CDT)
To: Anton Bester <extech@dod.co.za>

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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

• Previous message: Gleb Smirnoff: "Re: em(4) patch for test"
• In reply to: Anton Bester: "Bind 8"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]