Bind max socket/query per IP

Mukund Sivaraman muks at mukund.org
Thu May 23 02:33:01 UTC 2019


On Wed, May 22, 2019 at 11:39:04PM +0200, Ict Security wrote:
> Dear Klaus,
> 
> >>btw - how high is the "extremely load"?
> Without old DLZ module, Bind 9.12 scales to thousands and thousands of queries.
> If i include old DLZ module, with postgres, over about 1000 Qps Bind
> start to slow down visibly,
> 
> Do you think the old DLZ-Postgreqsl module might the bottleneck?
> Any possible replacement, continuing using Postgresql (i made an
> implementation to activate some custom filtering with a database).

It might be.

The dns_db API (which DLZ is an implementation of) is a synchronous
API. When a named thread asks dns_db to find an answer for it, it will
block until the dns_db API returns. This has almost no effect when using
the in-memory zones/cache which is typical, but when you start using a
database backend within dns_db which can block waiting for an answer,
this can tie up all the worker threads, depending on the rate of
response from the database. This would also cause queries to queue up on
the listening socket.

Use pstack <pid-of-the-named-process> when it appears to be stuck to see
if the threads are stuck within the DLZ implementation. If that is the
case, perhaps you can try increasing the number of worker threads
greatly (named -n ###) to see if that helps mitigating the issue.

In answer to your other question about why a query to another alias
interface appears to work, it is a different queue that by your
description has nothing waiting in it.

		Mukund


More information about the bind-users mailing list