Installing DNSSEC-Tools
From DNSSEC-Tools
DNSSEC-Tools contains a large number of components. Some of those components depend on other software. These pages will help you install everything you need to get DNSSEC-Tools working on your system.
Contents |
Operating Systems
DNSSEC-Tools is fairly portable and works on multiple systems. Pick from the following choices to describe how to install it on your platform of choice.
| Linux: | Fedora, Debian or Other Linux |
| Unix: | Installing on Unix |
| Windows: | Installing on Windows |
| Mac OS X: | Installing on OS X |
| Solaris | Installing on Solaris |
Configure flags
A number of configure flags are available for the dnssec-tools package. However, some of these flags may be confusing or even give some surprising results. This section clarifies some of the configure script behavior.
Why is this currently a problem
First, a couple of reasons why configure flags are a little complex in this setting;
- The DNSSEC-Tools package is a suite of tools, so some of the configure options that appear at the top-level of the package are really only specific to a particular tool within the suite. There is also some desire to keep various tools within the dnssec-tools package self-contained, so that it's somewhat possible to build and use only tools that are necessary for doing the job.
- The tool suite is a combination of Perl modules, perl scripts, C libraries and binaries build against these C libraries. Perl has its own notion of where in the directory structure it must place modules, documentation and scripts by default, while the C libraries and binaries (that don't rely on Perl) are configured to use /usr/local by default.
- The Perl location is not always standard. For instance, on an OSX system using macports, the perl path is typically /opt/local/bin/perl. Consequently, modules, documentation and scripts are all located somewhere under /opt/local/ _by default_, which is quite different than other *nix* based systems that would typically install these components under /usr/.
- Installing Perl modules in non-standard locations, while can be made to work, is often described as kludgy. This is because it is difficult to modify the tools in flight during install to make them look at the non-standard locations for modules.
Current configure surprises
Now, keeping in mind the above, here's what configure actually does:
- You can't say for sure where different pieces are installed after you have executed the "./configure; make; make install;" sequence, since some of this will depend on which perl instance was detected in your PATH.
- You will need root permissions in order to install all the perl-related components on the system. This is even if you've given a --prefix option that should not have needed any special privileges.
- While --prefix flag does the "right" thing for C libraries and binaries built using it, the flag does not control where any of the perl scripts are installed.
- The dnssec-tools.conf file and the dnssec-tools.1 man page are installed in $prefix/etc/dnssec-tools/ and $prefix/share/man/man1/ directories respectively. This is actually non-intuitive given that these files are installed as part of the 'perlinstall' dependency in the makefile, yet it is inconsistent with other perl-related install directories
Proposed configure behavior
Here's what configure should do in the future:
- Implement current behavior by default (when no flags are passed to configure)
- When --prefix is passed as an option, force perl to use a different install path and implement kludgy behavior described above
Status
- Support for this is in what will be 1.6
- There isn't an "old behaviour" switch, but probably should be. --enable-perl-self-install?
Notes on configuring (and not configuring) the validator module
Finally, some points on the configure behavior for the validator module:
- For most deployments of dnssec-deployment you _do not_ need to build and install the validator module. This includes most authoritative name server deployment scenarios that mostly require tools such as zonesigner, donuts and mapper. You can disable the validator configuration by simply using the --without-validator flag in configure.
- However, you _do_ need to build the validator (and supporting) modules if you need trustman (the trust anchor management tool) or any one of our DNSSEC-capable applications.
- Some configure flags that are visible in the top level of the dnssec-tools package are only specific to the validator module. These are --with-nsec3, --with-dlv, --with-ipv6. There's no need for you to specify these flags if you don't need the validator module. Specifically, zonesigner, donuts etc will still understand nsec3 zones if --without-nsec3 is passed as a flag to configure.
- NSEC3 and DLV support is experimental. NSEC3 support in the validator module was built against an older version of the specification and the code does not currently work.
- The validator module honors the --prefix option in that it will install libraries and binaries in the expected locations and looks for configuration files in the correct $prefix/dnssec-tools/etc directory; except for the root.hints file, which the validator will try to locate in various standard system directories. The validator module also allows the user to override the default locations for these configuration files during the ./configure process. However, in no case will 'make install' actually install any configure files in the directory specified. The user must install these files manually.
