DNS operators who configure their own systems usually rely on Linux or a BSD variant in combination with BIND or PowerDNS. If BIND named's current DNSSEC functionality isn't enough for you, you can also combine named (or another authoritative name server) with OpenDNSSEC, a complete solution for automated key management and signing.
Appliances, particularly Infoblox appliances, are widely used in large commercial settings. Nearly all Dutch banks use them, for example, as do institutions such as Leiden University.
If you are already using Infloblox appliances, signing your domains or enabling validation on your (caching) resolvers is in principle very straightforward. Signing involves just a couple of clicks, while validation is enabled by default. Nevertheless, it's important to check the default DNSSEC settings. The system time also has to be synchronised correctly for DNSSEC to work properly.
How to use this article
This article deals with the DNSSEC configuration for a validating resolver running on an Infoblox appliance. The configuration of an Infoblox appliance as an authoritative name server is described in a separate article.
This article has been written by reference to an OVA image with Infoblox NIOS version 8.2.2, running on VMware ESXi version 6.5.0.
The main functionality and options available in each situation are discussed, so that you are able to realise a complete (and, where possible, automated) configuration. For additional details and less-used options, see the Infoblox NIOS 8.2 Administrator Guide.
Infoblox DDI appliances
The Trinzic product line by Infoblox is a series of physical and virtual appliances for DNS/DHCP/IPAM (DDI). The system internals are based on Fedora Linux and BIND.
This article has been written by reference to an IB-V825, a virtual machine (VM) with NIOS version 8.2.2 loaded. A virtual evaluation version of such a machine is available from the Infoblox website.
We strongly advise Infoblox customers with support contracts to upgrade their NIOS software to the latest version before getting to work with DNSSEC.
System time
For DNSSEC to work properly, first you need to make sure that your system time is correctly synchronised. Whereas the traditional DNS protocol used only relative timestamps (TTLs), DNSSEC makes use of absolute timestamps. That is necessary because the digital signatures (in the RRSIG records) have absolute validity periods.
Automatic appliance system time synchronisation requires configuration of the NTP service. The service provides a hierarchical infrastructure for synchronising system clocks (on the basis of UTC) over the internet using UDP/123. For detailed guidance on configuring Infoblox's built-in NTP server, see the hands-on article on DNSSEC signing on an Infoblox appliance (section 2).
DNSSEC settings
Once you've dealt with the time synchronisation, the next step is to check and, where necessary, adjust the default DNSSEC settings. First, make sure that the EDNS0 option is enabled. EDNS0 provides an extension to the basic DNS protocol, enabling support for the larger packages and associated flags and fields required for DNSSEC.
To enable EDNS0, go to the 'Data Management' -> 'DNS' tab and select 'Grid DNS Properties' from the Toolbar. Click on 'Toggle Advanced Mode', which will result in a lot of extra tabs appearing. Then open the 'General'/'Advanced' tab. About halfway down, you'll see the option 'Disable EDNS0'. Make sure that EDNS0 is not disabled.
DNSSEC validation
The DNSSEC-specific settings are in the same window, on the 'Basic'/'DNSSEC' tab. By default, support both for DNSSEC in general ('Enable DNSSEC') and for validation in particular ('Enable DNSSEC validation') is enabled.
This setting is used to enable DNSSEC validation for the entire grid. If you want to enable (or disable) validation on a particular Grid Member (typically a caching resolver), you first need to go to the 'Data Management' -> 'DNS' -> 'Members' tab. There you select the server in question and click the 'Edit' icon. Next, in the 'Member DNS Properties' window, you select the 'DNSSEC'/'Basic' tab, where you can overrule the grid-wide settings.
Expired signatures and negative trust anchors
On the same screen, you'll see the option 'Accept expired signatures'. This option should be enabled only in exceptional circumstances, e.g. if your resolver is blocking certain DNS records because the relevant domain's administrator has forgotten to renew the signatures. That usually implies that something has 'gone down', since renewal of the RRSIG records is a high-frequency procedure and therefore automated in most cases. Under such circumstances, you may configure the validating resolver to temporarily accept expired signatures until the problem has been resolved.
Whereas the 'Accept expired signatures' option is used to (temporarily) allow all expired signatures, the 'Negative Trust Anchors' functionality enables you to whitelist particular zones (on a longer-term basis, if necessary). Under 'Negative Trust Anchors', you would typically list zones that have DNSSEC problems — e.g. configuration problems — but that people in your organisation need to access, for an on-line (cloud) application, for example. Zones listed under 'Negative Trust Anchors' are not validated at all.
Trust anchors
Under 'Trust Anchors', you list the domains (and associated public keys) that you trust absolutely. Before the root zone was signed, trust anchor listing was used to explicitly register DNSSEC-enabled top-level domains (TLDs) on validating resolvers. However, now that the root zone and most subordinate TLDs are DNSSEC-enabled, it is no longer necessary to anchor such 'islands of trust'. Because the Infoblox appliance doesn't support the RFC 5011 protocol, validating resolver operators will need to check that the new public root KSK has indeed been installed and activated on their systems as a trust anchor. If it hasn't, a manual (out-of-band) procedure will need to be followed.
Manual installation of KSK-2017
The first step in manual installation of the new trust anchor is to get the public KSKs from IANA's website. However, before installing the new public key on your resolver as a trust anchor, it's important to verify its authenticity. See the 'Manual installation' section of the article 'Trust anchor installation for new root KSK' for details of how to securely fetch and verify the current root keys.
Once you have fetched and verified the new KSK-2017 (key ID 20326), you can add it to your Infoblox grid as an extra trust anchor. To do that, go to the 'Data Management' -> 'DNS' tab and select 'Grid DNS Properties' from the Toolbar. The KSK-2017 can then be added at the bottom of the 'DNSSEC'/'Basic' tab. Strictly speaking, what you are dealing with is merely the hash of the public key (similar to the information in a DS record). It is therefore important to use the correct cryptographic settings: KSK-2017 is published as a type-2 (SHA-256) message digest (hash) of a public key based on DNSSEC algorithm number 8 (RSA/SHA-256).
If the current public root KSK is not yet installed on your system, we strongly advise installing the KSK-2017 trust anchor when you next configure your appliance(s). Infoblox Nederland previously announced that users were being actively informed about installation.
In conclusion
If you have the latest version of NIOS running, configuring DNSSEC validation on an Infoblox appliance should be very straightforward. All you need to do is check the default settings. We therefore strongly recommend upgrading to the latest version before getting to work with DNSSEC. For customers with support contracts, upgrading is free. However, for DNSSEC to work properly, you need to make sure that your system time is correctly synchronised. It is therefore important to begin by configuring the NTP service.
Because the Infoblox software doesn't support the RFC 5011 protocol, the new root KSK-2017 will need to be installed manually as a trust anchor if it isn't yet available on your system. The shortcoming highlighted above can't be disregarded in this context, since we are dealing with a DNS appliance. Such appliances need to be capable of rapid deployment with as little configuration input as possible. Infoblox is a big player on this market, and numerous influential organisations depend on their product.
What's more, the slowest DNSSEC-adopters — mainly the banks and other large organisations — are quite often Infoblox users. Tardy DNSSEC implementation will not help them to make good their deficit.