Log Message:
On rebooting a Xen VPS, dnscache said it started, but failed to
respond to queries and wrote nothing to the logs. This would have
been more fun to debug if my production system hadn't been relying
on it for name resolution. The problem was a blocking read from
/dev/random.

I'm the one who put that there, over 10 years ago. Do we need it?

From my reading of <http://cr.yp.to/djbdns/dnscache-conf.html> and
dnscache-conf.c, the seed needn't consist of top-notch randomness.
A sysadmin following DJB to the letter (rather than using this
djbdns-run package) would run dnscache-conf once to configure a
dnscache instance. dnscache-conf would cook 128 bytes of randomness
-- without direct assistance from any kernel device -- and write
it to a file. dnscache would read the same file on every startup.

Therefore, we...

1. Generate a random seed iff it doesn't exist (not on every startup)
2. Generate it from /dev/urandom instead of /dev/random

...so that the configuration we generate more nearly matches that of
DJB's documented procedure, and the kind of problem I encountered
is much more difficult to trigger.

While here, add LICENSE (2-clause-bsd) and otherwise placate pkglint.

Bump version.