Infoblox & DNSSEC

•

Infoblox NIOS implements very basic DNSSEC signing functionality. DNSSEC capabilities in general and key management capabilities in particular are very limited compared to other implementations. Several design choices seems to have been made without considering best current practices from operational experience. Unless the current design changes, we cannot  recommend Infoblox NIOS for managing DNSSEC-signed zones.

Key Rollovers

NIOS implements double signature key rollovers for both KSK and ZSK. Using double signature key rollovers for KSK makes sense as it requires only one transaction (DS update) with the parent domain and only one overhead signature. However, using double signature key rollovers for ZSK is not really a great idea, as it effectively doubles the number of signature resource record in the zone during the rollover. A pre-publish key rollover for ZSK would have been much more efficient.

KSK Rollovers

Every time a new KSK is introduced, the old KSK is kept in the zone 50% of the KSK key rollover interval (grace period). The grace period is always calculated based on the key lifetime and cannot be set/overridden manually. During the grace period time, no new key rollover can be performed nor can the current one be cancelled. The default KSK lifetime of 1 year results in a grace period of 182.5 days. It should be obvious to anyone that KSK grace period is absurdly long by default, and even longer when the KSK lifetime is extended. The grace period cannot be set manually. There is no way to tell NIOS that the DS has been submitted and published, and that the old KSK can be removed from the zone. On the other hand, if the new DS of that KSK can not (for some reason) be submitted and published in the parent domain within this time, the zone goes bogus. And there seems to be no way of preventing this from happening once a KSK roll has been initiated.

ZSK Rollovers

50% of the ZSK lifetime, all non-DNSKEY RRset are double signed (by both the old and the new ZSK) resulting in a zone file almost 50% larger 15 days per month. If the ZSK rollover would have been implemented as a pre-publish key rollover, there would have been no zone file increase.

Manual Key Rollovers

NIOS does not support manual (e.g. emergency) ZSK rollovers. Manual KSK rollovers are supported, but the as the old KSK is kept for an extended time (due to the grace period, see above) it is not usable for any emergency or other time constrained roll. It is not possible to see when future automatic rollovers are due nor any information on current grace periods.

Algorithm Rollovers

It is possible to change the KSK/ZSK algorithm, but the change will only take effect upon the next key rollover and will results in a broken zone (e.g. with a KSK using two different algorithms and a ZSK using the previous algorithm). It is not possible to change from NSEC to NSEC3 (or vice versa) without going unsigned.

NSEC3 Configuration

It is not possible to configure the number of NSEC3 iterations, configure the the NSEC salt length, nor roll (change) the NSEC3 salt.

Zone Signing

Signature refresh is not configurable. The manual states that “The Grid Master automatically renews signatures before their expiration date.”, which probably means Infoblox use the default BIND settings for online signing.

Recommendations

So, enough criticism. Here are some recommendations for Infoblox to fix the aforementioned issues:

  • Get rid of the grace period for KSK rollovers by having the operator confirm that the DS record is published and ready at the parent zone. For zones within the same grid (the NIOS management domain) this can be fully automatic. For zones outside the grid, confirmation can be made via GUI or via the new fancy RESTful API.
  • Implement pre-publish ZSK rollovers as described in RFC 6781. This will get rid of the grace period for ZSK and zone size will never increase due to ZSK rollovers.
  • Make it possible for the operator to find out when the next KSK/ZSK roll is about to happen (or if one is happening right now).
  • Support manual key rollovers.
  • Algorithm rollovers (including NSEC to NSEC3 transitions) are hard – you should probably just prohibit the operator to change algorithms while the zone is signed.
  • Make the number of NSEC3 iterations and salt length configurable. And state the defaults.
  • Make it possible for the operator to manually roll (change) the NSEC3 salt. Consider adding support for automatic NSEC3 rollovers.
  • Support a configurable signature refresh timer, or just state that the default ISC BIND timer is used.

Update 2013-09-27: One of our customers noted that during an KSK rollover, the administrator cannot see which key is the new key and which is the old key. Exporting trust anchors results in a DS/DNSKEY set with both keys.