NicTool Synopsis

[LogicX]

After spending a few weeks working with Nictool, and getting it all setup, and reading through far more of the code than I ever had desire to, I'd like to make a large general post about my setup, my feelings torward nictool and djbdns, and notes for what to look out for in your setup.

Background

I've previously only used BIND 8.4.x, manually modifying named.conf on primary and secondary servers, manually creating zone files on primary, and using TSIG keys to replicate changes to the secondaries.  Approaching nearly 300 zones, things were getting out of control.

Scope of Setup

I now have a NicTool network consisting of 4 Servers:

• Server A
  • 1 MySQL Daemon
  • 1 NicToolServer
  • tinydns user, with ssh keys: O, P & authorized_keys O
  • Services running:
    • 4 tinydns as bind:bin (loguser: bin:bin)
    • 4 axfrdns as bind:bin (loguser: bin:bin)
    • 10 djbdns exports as tinydns:tinydns (loguser: bin:bin)
• Server B
  • tinydns user, with ssh authorized_keys O
  • 1 NicToolClient
  • Services running:
    • 4 tinydns as bind:bin (loguser: bin:bin)
    • 4 axfrdns as bind:bin (loguser: bin:bin)
• Server H
  • tinydns user, with ssh authorized_keys P
  • Services running:
    • 1 tinydns as bind:bin (loguser: bin:bin)
    • 1 axfrdns as bind:bin (loguser: bin:bin)
• Server G
  • tinydns user, with ssh_authorized_keys P
  • Services running:
    • 1 tinydns as bind:bin (loguser: bin:bin)
    • 1 axfrdns as bind:bin (loguser: bin:bin)

Limitations

• 'tinydns' user hardcoded for rsync transfers
• DNS server FQDN hardcoded for rsync transfers (tinydns @ ns_server)
• No option for local path updates -- only rsync (see patch below)
• Be aware that NameServer delegation permissions in NicTool Client works only if the subgroups are hierarchically below the group they're gaining nameservers from.  See http://www.tnpi.biz/support/forums/index.php?t=tree&th=329&start=0&rid=81" target="_blank">this thread.

Patches/Fixes

• While using http://www.tnpi.biz/internet/dns/djbdns-freebsd.shtml" target="_blank">Matt's Guide to installing djbdns be aware that if you already have Mail Toaster installed, you already have a service directory and can skip the steps to retrieve and configure service (also note that Mail Toaster's setup puts it in /var/service, not /service)
• NicTool Server and Client require SOAP Lite, which needs http://nictool.com/docs/server/HTTP.pm.patch" target="_blank">Matt's patch to work. Also to catch mod_perl2 usage, http://nictool.com/docs/server/DBI.pm.patch" target="_blank">Matt's Apache::DBI patch http://www.tnpi.biz/support/forums/index.php?t=tree&th=292&start=0&rid=81" target="_blank">Discussion Thread.
• There is currently no export tool for anything but djbdns being distributed.  A good first attempt might be to take inter7's dnszone (part of http://www.inter7.com/?page=dnsadmin" target="_blank">dnsadmin) and recode it in perl to take advantage of the NicToolServer API
• djbdns export tool install.pl script hardcodes log user to dnslog (modify /install/path/log/run manually after executing) or see Rob Lensen's http://www.tnpi.biz/support/forums/index.php?t=tree&th=293&start=0&rid=81" target="_blank">thread with his patches.
• be sure to setup permissions properly on /usr/local/tinydns-name/root so the export tool has write permission when rsync copies to that destination. (see permission change examples below)
• be sure to MANUALLY ssh to both the dns.domain.com AND the respective IP FROM tinydns @ djbdns_export_tool_running_server to tinydns @ DNS_SERVER -- then say yes to the responses to add the host to your known hosts (update script will fail at this point otherwise)
• In my experience the tinydns-conf and axfrdns-conf scripts did not properly set permissions of /usr/local/axfrdns && /usr/local/tinydns directory trees. I rectified as follows:
  • chown -R user:group /usr/local/axfrdns /usr/local/tinydns
  • chown -R loguser:loggroup[/i] /usr/local/axfrdns /usr/local/tinydns
  • chown tinydns_export_ssh_user /usr/local/tinydns
• If you want to update a local tinydns, without dealing with ssh keys, checkout this http://www.tnpi.biz/support/forums/index.php?t=tree&th=322&start=0&rid=81" target="_blank">thread discussion and my http://mschroll.com/projects/nt_export_djb.pl.diff" target="_blank">patch.
• Be aware that install.pl's README's parameter example is incorrect compared with install.pl's usage output.  install.pl's usage output takes precdence (concerning placement of user/pass for DB server).
• The first time you run the djbdns export tool it will give error: "No filehandle passed at /home/tinydns/ns1.imcc.ca/nt_export_djb.pl line 433." Due to there being no data.orig for it to md5 compare again.  Ignore this.
• In my experience, after initiating the export tool, even with -force flag, I've had to make a change to a zone to have the export tool push the update through to the server. YMMV.

The Future

I'd like to find or code the following addons:

• BIND export tool
• BIND conversion/import tool
• Per-SubGroup SOA Templates
• A tool which draws out the IP Hierarchy based on reverse zones, and what domains use those IPs
• Copy Zones In NicToolClient interface
• Create sets of zones mirroring all the records of a current zone (ala, every zone has MX, TXT, www CNAME records, and we just want all those across 40 new zones)
• Go add your own suggestions to the http://www.tnpi.biz/support/forums/index.php?t=tree&th=323&start=0&rid=81" target="_blank">Feature thread.
• Something to interface with ISC DHCPD and submit changes to NicToolServer through the API
• A Dynamic IP Update script which interfaces with NicToolServer's API

Conclusion

I now have a very nice, working DNS setup where I don't have to worry about secondaries being out of sync, or there being much replication time. (with the time set to 120 seconds, and md5 comparisons enabled)
djbdns seems to strive to be a very simplistic DNS daemon.  Minimal frills, privilege separation, and task separation. (even TCP and UDP requests are handled by separate daemons).

The amount of time that this current will save me was well worth the time to get it setup.  Also the perspective I now have of all zones, especially with the description field, is priceless.

I think that NicTool has extreme potential to change the world of DNS, albeit with some improvements in documentation and implementation guides.  I encourage anyone who installs it to contribute back some suggestions, patches, or documentation, as the original developers have obviously put a lot of hard work into making NicTool very usable, and universal.

[mike_tcis]

A few additions to your excellent synopsis:

- If installing on FreeBSD via ports, you must have Apache2 and MySQL installed prior to installing the Perl modules (probably obvious, but its good to document every step anyway)

- Install mod_perl2 from ports prior to installing p5-Apache-DBI

- When installing p5-Apache-DBI, you'll need to use:

make install WITH_MODPERL2=YES

..otherwise it looks for mod_perl and fails.

--Mike

[matt]

Excellent job Mike, very nice work.  I'll add a link to this post from the nictool.com install pages.  I have also rated the topic highly, but I'm not sure what that effects.

Matt

[LogicX]

I just realized that the chown -R command I instruct to be run on /usr/local/tinydns-ns.domain.com is creating a security vulnerability.

because the /usr/local/tinydns-ns.domain.com/run file is then owned by bind, and not root, if tinydns were compromised the run file could host any number of commands which would then run as root the next time supervise executes it.

The run file should be owned by root:wheel so that it is not abled to be modified by an unprivileged user.

I'll update the main instructions.

[rainer_d]

I have a question about the various directories involved.

In the GUI, I have to enter a path for the data-directory of the namserver.
Then, this article talks about creating a special tinydns-user.

The install.pl script requires a directory, too.

So, which one is which? And what permissions do I need exactly ?

I've used

tinydns-conf bind bin /usr/local/tinydns-bla ...
(and used that service's data-directory as data-directory in the GUI-dialog)

and a seperate tinydns user with $HOME /usr/home/tinydns.

I assume, the data-directory in /usr/local/tinydns-bla.. needs to be writeable by the tinydns-user (not "bind").
And the "directory" for the install.pl-script is ~tinydns/bla?


I've run
./install.pl /usr/home/tinydns/dns-1 3 tinydns bin localhost nictool nictool PASSWORD mysql -r md5 -force -noserials -buildcdb

and got:

print() on closed filehandle O at ./install.pl line 62, <F> line 1.
print() on closed filehandle O at ./install.pl line 62, <F> line 2.
cannot create /usr/home/tinydns/dns-1/env/NT_DB_HOST_NAME: No such file or directory
cannot create /usr/home/tinydns/dns-1/env/NT_DB_NAME: No such file or directory
cannot create /usr/home/tinydns/dns-1/env/NT_DB_PASSWORD: No such file or directory
cannot create /usr/home/tinydns/dns-1/env/NT_DB_TYPE: No such file or directory
cannot create /usr/home/tinydns/dns-1/env/NT_DB_USER_NAME: No such file or directory
chown: /usr/home/tinydns/dns-1/log/status: No such file or directory
chown: /usr/home/tinydns/dns-1/log/main: No such file or directory


Any ideas?

Rainer

[rainer_d]

rainer_d wrote on Wed, 15 June 2005 12:47

I have a question about the various directories involved. In the GUI, I have to enter a path for the data-directory of the namserver. Then, this article talks about creating a special tinydns-user.

OK, I got it working, sort of.
The install.pl script had a little error (for me) in that it said:

system("cp -rf sample $dir");

but it seems to be better to say

system("cp -rf sample/* $dir");

After that, it copies all the directories and let's me run the synchronisation-process.


Rainer