DNSSec on FreeBSD 9.0-RELEASE causes CPU 100%

gkontos

gkontos

Greetings everyone,

I was testing DNSSec resolution on BIND 9.8.1-P1 by adding the following options:

Code: 
options {
...
dnssec-enable yes;
dnssec-validation auto;
...
};

Unfortunately immediately after named is restarted one CPU reaches 100% utilization.

Code: 
CPU: 30.1% user,  0.0% nice, 23.6% system,  0.0% interrupt, 46.3% idle
Mem: 111M Active, 14M Inact, 255M Wired, 852K Cache, 3558M Free
Swap: 2048M Total, 2048M Free

 PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
 2178 bind          5  20    0 51364K 13828K kqread  0   0:17 84.18% named

The system is running GENERIC kernel, and it not an authoritative DNS. Mainly used for testing purposes. My logs don't show anything strange:

Code: 
Jan  5 02:03:50 hp named[1175]: stopping command channel on ::1#953
Jan  5 02:03:50 hp named[1175]: exiting
Jan  5 02:03:55 hp named[2178]: starting BIND 9.8.1-P1 -t /var/named -u bind
Jan  5 02:03:55 hp named[2178]: built with '--prefix=/usr' '--infodir=/usr/share/info' '
--mandir=/usr/share/man' '--enable-threads' '--enable-getifaddrs' '
--disable-linux-caps' '--with-openssl=/usr' '--with-randomdev=/dev/random' '--without-idn' '--withoutlibxml2'
Jan  5 02:03:55 hp named[2178]: using built-in root key for view _default
Jan  5 02:03:55 hp named[2178]: command channel listening on 127.0.0.1#953
Jan  5 02:03:55 hp named[2178]: command channel listening on ::1#953
Jan  5 02:03:55 hp named[2178]: running

I have posted this on the freebsd-stable list but I would like to know if anybody here has come across a similar behavior.

George
 
fnucc said:
Maybe these two links can help: bug and debugging
Click to expand...

Hm, the first one is related to a previous bind version but I can see the similarities. The second one I don't really understand the solution. Anyway, I will make another installation on a different server once 9.0-RELEASE is available for downlod and try to reproduce the problem.
 
It appears to be an issue with my test server since I can not repeat the behavior in a different installation.
 
Code: 
$ mkdir /etc/namedb/managed
$ chown bind /etc/named/managed
Edit /etc/namedb/named.conf, add to the options { ... } block:
Code: 
  managed-keys-directory "/etc/namedb/managed";
# rndc reload

And the CPU burn stops.
 
An explanation would be in order :)

I've stumbled upon the same issue today, enabling dnssec validation auto on a test server.

Turns out, the high CPU usage is triggered by an error trying to write a file to the working directory. And, unless you specify a working directory for the keys, such as @emukulic recommends, named will try to write to the base directory specified in the directory clause, which is both a base path for other files and directories specified in named.conf, and the default working directory.

There are plenty of old installations that use directory just as a base path for files, pointing to a directory owned by root, creating special directories writable for bind (for example, for slave transfer zones). In such a case, enabling dnssec-validation auto will trigger the bug.

In the latest FreeBSD versions a new directory has been created (/etc/namedb/working), owned by the BIND user, and relative pathnames have been removed from named.conf-dist.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top