Upon updating a very long established net-dns/bind, a restart of named caused a very surprising gulp of nearly 8GBytes of virtual RAM! After a few bits of debug and puzzlement and suspicion that the new “pie” use flag might be at play, a ‘quick fix’ to try was to reinstall bind… Whereupon the following was executed as root (adjust the version number accordingly):
emerge -vDNu net-dns/bind emerge --config '=net-dns/bind-9.15.2'
… And the named DNS service then failed to start with the slightly cryptic message in the syslog (/var/log/messages) of:
named[3181]: openssl_link.c:164: fatal error: named[3181]: OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ) named[3181]: exiting (due to fatal error in library) /etc/init.d/named[3179]: start-stop-daemon: failed to start `/usr/sbin/named'
Briefly, the problem is that named cannot access “/dev/urandom” for its cryptography bits… This is a change in that older versions of named happily used the (blocking, slower) “/dev/random”. Additionally, Gentoo runs named in a chroot and the new requirement of including “/dev/urandom” in the chroot hasn’t been implemented…
The ‘quick fix’ is to simply add the urandom device file into the respective chroot thus (as root):
cd /chroot/dns/dev mknod urandom c 1 9
“named” can then be started as normal.
Confusingly, the new named appears to ignore the Gentoo use flags and requires “/dev/urandom” regardless…
Further detail can be found in two Gentoo bug reports and a forum posting:
- Bug 673746 – net-dns/bind-9.12.2_p2-r1 – named: OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not seeded’ message in the OpenSSL FAQ)
- Bug 693402 – net-dns/bind-9.15.2 – named: OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not seeded’ message in the OpenSSL FAQ)
- OpenSSL pseudorandom number generator issue w/bind [SOLVED]
Hopefully, all will soon be officially fixed in the repositories.
Leave a Reply
You must be logged in to post a comment.