DNSSEC validation on an Infoblox appliance

New KSK-2017 trust anchor requires manual installation

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. Unfortunately, the Infoblox appliance doesn't support the RFC 5011 protocol, implying that the new root KSK-2017 needs to be installed manually on your validating resolver as a trust anchor.

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'.

The Trust Anchors option is nevertheless currently very relevant. That is because the root zone's KSKpair is currently being rolled over. In other words, ICANN, the root zone's administrator, is in the process of replacing the existing cryptographic key pair that forms the basis for the entire DNSSEC infrastructure (KSK-2010) with a new key pair (KSK-2017).

Root KSK rollover

The rollover itself was to have taken place on 11 October 2017, but had to be postponed because not enough validating resolvers had installed the new trust anchor. A new date has yet to be announced, but validating resolver operators are being urged to update their systems as a matter of urgency, if they haven't already done so.

New trust anchor

That implies checking that the new public root KSK has indeed been installed and activated on their systems as a trust anchor. The reason being that, as soon as the rollover proper takes place, any digital signatures based on the old KSK-2010 key pair will cease to be valid. Consequently, any validating resolver that doesn't have the new trust anchor installed will be unable to verify the signatures attached to DNS records, making all domain names unreachable for people and applications that rely on the resolver in question.

With resolvers that don't install new trust anchors automatically (on the basis of the RFC 5011 protocol), including Infoblox appliances, the new trust anchor has to be installed manually ('out of band').

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).


Although postponement of the rollover means that the installation of KSK-2017 is for the time being less urgent than it was recently, we strongly advise installing the new trust anchor while you are configuring 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.

The Infoblox software doesn't support the RFC 5011 protocol, implying that the new root KSK-2017 needs to be installed manually as a trust anchor. 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.


  • Wednesday 25 April 2018


    Signing of government domains: rapid progress continues


    In the Netherlands, 80% of government websites are now signed

    Read more
  • Tuesday 26 September 2017

    Internet security

    A fight on three fronts


    Our war on internet abuse

    Read more
  • Thursday 11 January 2018

    SIDN Labs

    Best wishes for 2018!


    Looking back at SIDN Connect 2017 and ahead at the year to come

    Read more


Your browser is too old to optimally experience this website. Upgrade your browser to improve your experience.