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.
1.1 Appliances
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 KSK-2017 needs to be installed manually on your validating resolver as a trust anchor.
1.2 How to use this article
This article deals with the DNSSEC configuration for an authoritative name server running on Infoblox. The configuration of an Infoblox appliance as a validating resolver is described in another 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.
Contents
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.
2 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, while the key pairs used to sign the DNS records have administrative 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.
2.1 Grid NTP server
Each Infoblox Grid (a cluster of appliances controlled by the Grid Master) has its own inbuilt NTP server: a service that obtains system times from external NTP servers and distributes them to local NTP clients. With a new installation, you can configure the service when you run the Grid Setup Wizard, which is accessed by clicking 'Grid' -> 'Grid Manager' -> 'Members', and then 'Toolbar' -> 'Grid Properties' -> 'Setup Wizard'.
In step 5, the Wizard invites you to enable NTP and lets you enter a list of external NTP servers. For reliability, your configuration should have at least three external NTP servers, preferably Stratum-1 servers that take their system times directly from a reference clock. If you don't want to buy your own NTP hardware, you can find details of public servers on ntp.org.
2.2 NTP on an existing Grid
To configure NTP on an existing Infoblox Grid, begin by opening the tab 'Grid' -> 'Grid Manager' ('Members'). On the Toolbar to the right, you'll find an NTP menu, from which you select 'NTP Grid Config'.
On this screen's 'Basic'/'General' tab, you can manage the list of (external) NTP servers and their keys. Additional information about the keys is given later in this article.
2.3 NTP for Grid Members
The same NTP menu includes the option 'NTP Member Config', which you can select to specify NTP servers and keys for individual systems in the Grid. The option becomes active when you select a Member.
On this screen's 'Basic'/'General' tab, the NTP servers and keys specified for the whole Grid are listed by default ('Inherited'). The individual Member therefore uses the Grid's system time, as obtained from the supporting database/VPN.
If you want the Member in question to operate as an NTP server for other systems (typically in the local network), enable the option 'Enable the NTP server on this Member'.
If you want a particular Member to use different (external) NTP servers from those used by the Grid, click 'Override'. You will then be prompted to enter the NTP servers/keys for the Member in question.
If an individually configured Member cannot reach its NTP servers — e.g. due to network problems — the Grid Master is used as a backup server.
Within an HA (High Availability) pair, only the active node can synchronise its clock with external NTP servers; the passive node takes its system time from the active node.
2.4 Encryption
Unencrypted message exchange makes NTP clients and servers vulnerable to MITM attacks. Traffic to and from external NTP servers should therefore be encrypted. Encryption of traffic within a Grid is unnecessary, since all communication between Members is via the supporting database (replication) or the intermediate VPN.
NTP messages can be secured by symmetrical cryptography. Symmetrical encryption involves client and server both using the same private key.
It is therefore similar to the TSIG encryption used for DDNS and zone transfers (AXFR/IXFR) between DNS masters and slaves.
For the security of the DNSSEC installation, it is advisable to synchronise only with external NTP servers that make signals available in a secure form, or to set up your own Stratum-1 server.
2.5 Autokey and NTS
Infoblox currently supports only the MD5 MD5 and DES protocols, which are no longer considered secure. Although the supplier claims to use NTPv4 (RFC 5905), the two protocols were formerly the basis for NTPv3 (RFC 1305). Although neither protocol is now secure, they are the only options currently available. We therefore advise using MD5: it is the least insecure of the two, and certainly better than nothing.
The NTPv4 software also supports the newer, public-key-based Autokey protocol [1, 2]. However, it is usable only for inter-system traffic where each system has its own public IP address (i.e. does not rely on NAT). Cricket Liu, co-author of the authoritative 'DNS and BIND' and Chief DNS Architect at Infoblox, previously said that the company's engineers would look at realising Autokey support.
Autokey support never materialised, however, and has since ceased to be of interest. Autokey proved to have certain inherent problems and has now been overtaken by the new Network Time Security (NTS) technology. At the time of writing (summer 2018), NTS for NTP is nearing completion. However, until NTS is incorporated into a future version of the NTP, we must make do with MD5.
2.6 Installing private keys
Each external NTP server's private MD5 key therefore has to be entered manually, and then associated with the server in question, alongside the address.
2.7 NTP service
To enable the newly configured NTP service, go to the tab 'Grid' -> 'Grid Manager' -> 'NTP' ('Services'). There, you can select and initiate ('Play') the service in question.
Once you've confirmed, the NTP service initiates and you can continue to the DNSSEC settings.
3 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.
3.1 KSK and ZSK rollover settings
The DNSSEC-specific settings are in the same window, on the 'Basic'/'DNSSEC' tab. By default, support both for signing ('Enable DNSSEC') and for validation ('Enable DNSSEC validation') is enabled.
The timing settings for signing can be left as they are: ZSK and KSK rollovers after one month and twelve months, respectively, and re-signing of the DNS records every four days.
Although those intervals are very widely used, for most domains you could safely make them twice as long or longer. For example, you could set the rollovers to take place every three months and every two years, respectively, with DNS record re-signing once a month. That would reduce your time input (KSK rollovers currently involve manual refreshment of the key material held by the registry) and would prevent unnecessary dynamism/activity in the DNSSEC installation.
Infoblox does not support the use of a single key pair. However, that is of little practical significance: for good reason, most DNS operators choose to work with two key pairs (KSK and ZSK) anyway.
3.2 Encryption algorithms
As illustrated above, the default encryption algorithm for the KSK and ZSK pairs is RSA/SHA-256 (algorithm number 8, RSASHA256), with default key lengths of 2048 and 1024 bits, respectively. In principle, there is nothing wrong with that. However, we currently regard algorithm number 8 as the minimum required for adequate security. You may wish to set the key length to 2048 bits for both ZSK pairs.
RSA/SHA-512 (algorithm number 10, RSASHA512) was developed specifically for use on 64-bit processors. Its use on a device with a 32-bit processor (e.g. a mobile device) therefore requires extra processing power.
If the algorithms are changed on this screen, zones that have already been signed will automatically be migrated to the new settings at the next rollover. The chain of trust will therefore remain intact and the DNSSEC security will be continuous.
3.3 Elliptic Curve Cryptography (ECC)
In preference to RSA/SHA-256 or RSA/SHA-512, we would much rather use the modern and more DNSSEC-compatible ECDSA algorithms (number 13, ECDSAP256SHA256). However, they are not currently supported by Infoblox.
We therefore advise verifying that your appliance is configured to use RSA/SHA-256 or RSA/SHA-512. By default, earlier versions of NIOS used RSA/SHA1 (algorithm number 5). However, SHA-1 is no longer considered secure. Furthermore, that option involves the use of NSEC, an outmoded means of attaching DNSSEC signatures to NXDOMAIN replies ("Non-existent domain"), which is vulnerable to zone walking or zone enumeration, even in the context of a protected zone transfer. NSEC3 is not vulnerable in that way.
4 Signing
After going through the preparatory steps described above, you are ready to proceed to the actual signing of your zone, which we shall call example.nl. Go to the Zone page 'Data Management' -> 'DNS' -> 'Zones'. On the Toolbar to the right (above 'Grid DNS Properties', which you have just been using), you will see a DNSSEC menu:
Sign Zones
Unsign Zones
Import Keyset
Export Trust Anchors
Rollover Key-Signing Key
Rollover Zone-Signing Key
Check KSK Rollover Due
Apply Algorithm Changes
If you open the menu when managing a particular zone, the options apply to that zone only. If you go up a level, you can select one or multiple zones for configuration.
4.1 Authoritative zone
The information in this article is based on the assumption that an (authoritative) DNS installation is already in place and functioning properly. In our case, that implies that we have configured the Infoblox appliance as the primary server for the domain example.nl: The content of the associated zone file, db.example.nl, is presented below and available for downloading here.
$TTL 1d ; ttl is 1 day
@ IN SOA dns1.example.nl. dns.example.nl. (
2017101300 ; serial (date & version)
8h ; refresh every 8 hours
20m ; retry after 20 minutes
4w ; expire after 4 weeks
20m ; negative caching ttl is 20 minutes
)
; DNS name servers
IN NS dns1.example.nl. ; primary name server
IN NS dns2.example.nl. ; secondary name server
; SMTP mail gateways
IN MX 10 mx.example.nl. ; MX gateway
IN MX 100 fallback-mx.example.nl. ; fallback MX gateway
; hosts
IN A 192.168.129.36 ; server
IN AAAA a022:2f87:1098::2:14 ; server (IPv6)
www IN CNAME example.nl. ; WWW server
ftp IN CNAME example.nl. ; FTP server
mx IN A 192.168.128.34 ; mail gateway
mx IN AAAA a022:2f87:1098::1:6 ; mail gateway (IPv6)
mail IN A 192.168.128.35 ; mail server
mail IN AAAA a022:2f87:1098::1:7 ; mail server (IPv6)
; exterior hosts
dns1 IN A 172.16.64.5 ; primary name server
dns1 IN AAAA 2f87:a022:0941::8:5 ; primary name server (IPv6)
dns2 IN A 172.16.128.6 ; secondary name server
dns2 IN AAAA 2f87:a022:0941::16:6 ; secondary name server (IPv6)
fallback-mx IN A 10.184.172.36 ; fallback mail gateway
fallback-mx IN AAAA 0941:20a2:7f34::32:7 ; fallback mail gateway (IPv6)
(IPv6)
4.2 Signing procedure
Signing a zone involves merely clicking a button and confirming. The key pairs and DNSSEC records are then generated automatically. After that, the serial number of the zone (in the SOA record) is increased and notifications are sent to the slave servers, so that they are able to initiate a zone transfer.
Signing has to be done on the Grid Master, which therefore acts as the administrative master, possibly hidden. If the Grid Master is hidden, another DNS server (a Grid Member or an external server) is set as the primary server. External slaves receive their signed zone files by means of normal transfers (AXFR/IXFR). Where Grid Members are concerned, the exchange is via the supporting database (replication). Remember that DNSSEC has to be enabled (as described above) on Grid Members that function as secondaries for a signed zone.
Alternatively, the Grid Master can be configured as a slave to an external (hidden) master or a Hardware Security Module (HSM), which delivers a (signed) zone file via the (local/dedicated) network.
Unfortunately, the appliance software doesn't tell the user whether the signing procedure has been completed successfully. However, on the zone page itself, the presence of DNSSEC records (RRSIG, NSEC3, NSEC3PARAM and DNSKEY) and the DNSSEC logo at the top show that the zone has indeed been signed.
4.3 DS records
By selecting 'Export Trust Anchors' from the DNSSEC menu, the KSK DNSKEY record or the derived DS record can now be downloaded in file form. The downloaded key material then has to be uploaded to the registry, thus closing the chain of trust to the parent domain.
The record format for the upload depends on the registry. Some registries require a DS record, which can be published without modification. Others, including SIDN, ask you to upload a DNSKEY record, from which they generate a DS record (a hash) for publication. That enables the registries in question to retain full control over the cryptographic algorithms used.
The content of the dnskeys_records.txt file is as follows:
(AwEAAelukWWueMI8eDh5JwVatqr2E7cjqZWOfNzT3ybVde92g7bfty4ghpnOHABlR6+...) ;
key id = 60106
The DS record export function generates hashes for both SHA-1 (digest algorithm number 1) and SHA-256 (algorithm number 2).
The content of the ds_records.txt file is as follows:
example.nl. IN DS 60106 8 1 8CD8633C4E4D433D5B8A535BD64670FB626A1935
example.nl. IN DS 60106 8 2
2B27F5297B895B91C6A80133471858226DC7890D53BDCC0BA93CEA0E5427F297
The SHA-1 algorithm is no longer secure and should definitely not be used. Therefore, when uploading to a registry (or registrar) that permits you to provide your own ready-to-use DS record, you should always provide a record based on digest algorithm number 2.
The final option, 'BIND trusted-keys statement', generates a special, abbreviated version of the DNSKEY record, which can be imported to BIND named as trust anchor by using a trusted-keys statement.
4.4 Importing DS records from a delegated zone
To import public keys from a delegated zone, go to 'Data Management' -> 'DNS'. You can then select a zone and click the 'Import Keyset' option on the Toolbar's DNSSEC menu.
Both DNSKEYs and DS records can be imported. However, if you use a DNSKEY record, the appliance will generate a DS record itself using the insecure SHA-1 algorithm. We therefore recommend importing only DS records based on SHA-256.
It is not necessary to import DS records for subordinate zones in the same Infoblox Grid, because they are automatically included in the parent zone after signing or a KSK rollover.
5 Rollovers
On Infoblox appliances, key rollovers (described in RFC 6781) always used to be performed using the double signature method. However, from NIOS version 6.11 the pre-publish method has been available as well, albeit only for ZSK rollovers. The main difference between the two methods is that the double signature method allows you to perform an immediate rollover, but temporarily makes the zone twice as big (due to the double signatures), whereas the pre-publish method requires the new public key to be made available alongside the old DNSKEY before the rollover is implemented. The pre-publish method can nevertheless be used for an immediate emergency rollover if you always have a spare DNSKEY pre-published and keep the matching private key off line.
To change the active ZSK rollover method, go to the 'Data Management' -> 'DNS' tab and select 'Grid DNS Properties' from the Toolbar. On the 'DNSSEC'/'Basic' tab — discussed above in connection with changing the cryptographic settings for DNSSEC — there is a 'Zone-signing Key rollover method' toggle switch. The default setting is 'Pre-publish', so the switch can normally be left as it is.
5.1 ZSK rollovers
ZSK pairs have to be rolled over frequently, so the rollovers are always fully automated. In the event of security or other problems, the manual for NIOS version 6.10 advised un-signing and immediately re-signing the zone. We did not regard that as a good solution, since it implies temporarily disabling DNS record security. Fortunately, NIOS version 6.11 and following versions also support manual ZSK pair rollovers. To initiate a manual rollover, go to 'Data Management' -> 'DNS' -> 'Zones', select the zone whose keys you want to roll over, and then click 'Rollover Zone-Signing Key' in the DNSSEC menu.
As with zone signing, the appliance software doesn't tell the user whether the rollover procedure has been completed successfully. However, on the zone page itself, you can see that the rollover has been set in motion from the presence of the extra ZSK DNSKEY record (both flags have a value of 256).
In addition, it is now possible to immediately delete insecure key pairs. The software protects active key pairs against deletion, so you can delete only key pairs that have already been rolled over (i.e. have expired) or whose status is still pre-published. To delete a key pair, go to 'Data Management' -> 'DNS' -> 'Zones'. There you select the zone in question and click 'Edit'. On the Authoritative Zone editor's 'Advanced'/'DNSSEC' tab, individual KSK and ZSK pairs can be managed.
5.2 KSK rollovers
In the past, KSK rollovers had to be initiated manually, but this procedure is now automated as well. It's possible to disable automatic KSK rollovers by going to the 'DNSSEC'/'Basic' tab (considered above) and toggling the 'Enable automatic KSK rollover' option.
Although a KSK rollover requires human intervention, insofar as the new DNSKEY/DS records have to be uploaded to the registry manually, we recommend leaving the remainder of procedure in automatic mode. Seven days before a KSK pair is due to expire, the appliance software will alert the administrator to the upcoming rollover via the admin interface. Notifications by SNMP and/or e-mail can also be enabled. You can choose to be notified about all rollover events, or about only those events that require human intervention (deleting and adding key material from/to the parent zone).
5.3 Notifications
We regard a notice period of seven days as very short for a domain with a low rotation frequency. The admin interface is also somewhat lacking insofar as, if you select 'Check KSK Rollover Due' from the DNSSEC menu, you are not shown rollovers scheduled for more than a week ahead.
According to Liu, many DDI administrators open the Infoblox interface several times a day or even have the screen up all day. Despite having previously indicated that its engineers would look into the possibility of enabling notifications to be activated and dispatched earlier, Infoblox has retained the seven-day notice period.
Fortunately, forgetting about a rollover is not disastrous. Unlike DNSSEC-signatures, KSK/ZSK pairs have an administrative lifetime only. Furthermore, you can use the Infoblox API to, for example, consult the database yourself using Perl.
Finally, like ZSK pairs, KSK pairs can be rolled over manually by selecting 'Rollover Key-Signing Key' from the DNSSEC menu. After setting up a manual rollover, the new DNSKEY/DS records must of course be exported and uploaded to the registry.
6 Standing still means falling behind
The implementation of new DNSSEC functionality in the Infoblox software has been slow. By contrast, development (maturation) of the DNSSEC protocol has been progressing quickly, and Infoblox has therefore slipped behind the curve. A while ago, we published an article saying that Infoblox users were working with an outmoded system, and that most of the developer's promised improvements have not materialised.
Since then, many of our criticisms about the cryptography and the default settings have been addressed, with the result that the Infoblox appliance now serves as a useful out-of-the-box basic DNSSEC installation.
6.1 ECDSA algorithms
Nevertheless, Infoblox doesn't currently support ECDSA algorithms (numbers 13 and 14), which are currently gaining widespread favour [1, 2]. ECDSA makes the DNSSEC protocol more secure and compact, and we therefore strongly recommend its use where possible/available.
RSA/SHA1 is the most widely used cryptographic algorithm for generating KSK and ZSK. However, it is recommended to use RSA/SHA-256 [number 8] and RSA/SHA-512 [number 10] for better interoperability. It is not recommend to use RSA/MD5 cryptographic algorithm as it is not very secure. As stated in RFC 6944, there are known defects in MD5.
Judging by the following statement in the manual, Infoblox seems to have been willing to rectify its outmoded implementation: In fact, the reason why the use of algorithms 8 and 10 is advisable is not interoperability but security. Furthermore, the outdated statistic on the use of RSA/SHA-1 shows that Infoblox users should interpret the manual cautiously.
SIDN has supported the two ECDSA algorithms since March 2016. Via the DRS interface, registrars can therefore upload DNSKEY records for their .nl domains formatted using those two algorithms.
6.2 RFC 5011
Another point that urgently requires attention is NIOS's lack of support for RFC 5011. RFC 5011 sets out a protocol for the secure (i.e. signed) and automated installation of new trust anchors on a DNSSEC-validating resolver.
The protocol played a vital role in last year's rollover of the root KSK pair. The new trust anchor had to be manually installed on validating resolvers that didn't support RFC 5011, including Infoblox appliances. At the end of last year, the rollover had to be postponed because not enough validating resolvers had installed the new trust anchor.
6.3 Banks
The shortcomings 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.
7 In conclusion
Enabling DNSSEC on an Infoblox appliance is very straightforward. In principle, all it involves is selecting a menu option. Since NIOS version 6.11, the Infoblox software has also had the functionality needed to effectively manage everything associated with key rollovers. If you have the latest version of NIOS running, the only other thing 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.