the argument to have a tinydns-run package appears to be made by analogy with the dnscache-run package.
however, i'm not convinced that the analogy holds.
dnscache-run defines a specific, commonly-used instantiation of
dnscache: a resolving nameserver for the local host running on the
loopback interface. Such a setup has a default configuration and
demands no interaction from the local administrator to set up.
As an authoritative nameserver, tinydns has no such explict default
configuration. The administrator needs to know (at least):
* what IP address the nameserver should listen on
* what domains should be served
* what records should be included in those domains
This is a non-trivial amount of configuration -- so much so that it
seems unlikely to be useful to prompt for all of it via debconf, in
which case the server would not be well-configured anyway.
So, what would such a package look like?
The most heavyweight package i can imagine would presumably:
0) create a tinydns user and a dnslog user, if they do not already exist
1) guess at the preferred IP address to listen on (choose from the
non-loopback IP addresses on the host somehow? maybe prompt via debconf
for the IP address)
2) ask the user what domains to be served? (would this be debconf abuse?)
3) run tinydns-conf to set up the servicedir
4) make a root/data file, (either empty or containing the ns records
gathered in stage 2) and compile it to root/data.cdb
5) link the servicedir into the running daemontools or runit
supervision suite.
The administrator would be left with the task of updating root/data as
needed.
If you still think such a package would be useful, do you have any
proposals for how to gather reasonable defaults for steps 1 and 2?
--dkg
signature.asc
Description: OpenPGP digital signature
