dnssec-keygen
reads from /dev/random
by default. If the entropy on your system is low, you won't get enough random data to generate the keys in a timely manner. strace will probably show lots of stuff like:
select(4, [3], [], NULL, NULL) = 1 (in [3])
read(3, "5%\5\32\316\337\241\323", 46) = 8
read(3, 0x7fff5b6c3df0, 38) = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], NULL, NULL) = 1 (in [3])
read(3, "\305\35\201c\31\343\251\21", 38) = 8
read(3, 0x7fff5b6c3df0, 30) = -1 EAGAIN (Resource temporarily unavailable)
/dev/random
blocks if there isn't enough entropy, so it could take a while.
You have a few options to make this go much faster. The easiest is to use change -r /dev/random
to -r /dev/urandom
to use the non-blocking (but not as secure) random number generator. This may not be considered secure for something like a GPG or SSH key which you'd expect to use for several years, but it's probably safe for something you'll be changing every 30 days.
Another option is to use something like EGD or haveged as a replacement for /dev/random
.
If you want a much more secure RNG, you're better off with a dedicated hardware RNG. These are probably overkill for DNSSEC unless you're managing TLDs or bank domains.
You may want to stick to /dev/random for the KSK, but /dev/urandom should be good for the ZSKs.
I found an answer. Following line in /etc/bind/named.conf.options
fixes it:
---> dnssec-must-be-secure mydomain.local no; <---
So, full text of /etc/bind/named.conf.options
will be (skipping comments):
options {
directory "/var/cache/bind";
forwarders {
192.168.1.1;
};
dnssec-enable yes;
dnssec-validation yes;
dnssec-must-be-secure mydomain.local no;
auth-nxdomain no;
listen-on-v6 { any; };
};
UPDATE: Actually, at this point I cannot tell if I indeed fixed bind with that line or didn't. Somehow all queries succeed now, with or without this line. If an expert is present here, please chip in
Best Answer
The reason why there is no separate documentation for reverse zones is that reverse zones are just a subset of zones which there is plenty of documentation for. The thing that sets a reverse zone apart from other zones is how it is (typically) used, not how it actually operates.
Ie, the only thing that is actually different is that your typical lookup of a name inside a reverse zone is for type
PTR
and for a name which is the result of having mapped an IP address into a name based on the standardized convention of reversing the IP address and appending.in-addr.arpa
or.ip6.arpa
for IPv4 and IPv6 respectively. The reverse zone itself operates just the same as any other zone and neither the authoritative nameserver or the resolver server needs any special handling for this at all.