Contents: 0 ENFORCER-NG INTRODUCTION 1 HIGH-LEVEL DESIGN GOALS 2 KEY FEATURES 3 CHANGES FOR THE USER 4 TODO BEFORE FINAL RELEASE 5 FUTURE FEATURES 6 BUILDING FROM SOURCE REPOSITORY 7 ENFORCER INTERNALS 8 NEVER ASKED QUESTIONS 0 ENFORCER-NG INTRODUCTION One of the explicit design goals is to manage a large number of zones simultaneously. Together with the progressing requirements it becomes increasingly harder to satisfy them with the current Enforcer. It was agreed that a complete redesign and implementation is the best way to go for the future. Enter Enforcer NG (from here on simply called Enforcer). This document describes the highlights and differences between the two implementations as well as the state of affairs during the first alpha release. Please not that other documentation regarding the Enforcer in this release is likely not up to date and inaccurate. 1 HIGH-LEVEL DESIGN GOALS - Support for a large number of zones. The enforcer should reasonably be useable with many zones. Think order of magnitude 50.000 concurrent zones. - Allow for future rollover strategies. Provide a generic framework to implement other kinds of rollovers in the future. - Drop in replacement. Should replace the current enforcer but keep the same interface and provide migration scripts from earlier installs. 2 KEY FEATURES - Single key signing (CSK). Using a single key as both KSK and ZSK. And safely switch to or from a split key scenario. - Algorithm rollover - Policy rollover - Multiple concurrent active keys. Possibly of different algorithms. - Multiple HSM's. - Support for unsigned zones. Also dubbed pass-through or null algorithm. This also includes graceful rolling from and to a regular signed zone. - Time safe. Taking the Enforcer down has no impact on the DNSSEC validity of the managed zones. The enforcer can be started later and it will pick up where it left of (this will of course delay pending rollovers). - Command channel The enforcer includes a command channel from the user to the daemon much like the signer does. The user can interact with the daemon and inspect the current state. - Scheduling behavior The Enforcer is a daemon defining tasks for itself. These tasks have a precomputed execution time, so the enforcer can sleep completely till the next scheduled task. - Emergency rollover It is possible as a user to force the enforcer to introduce a new key at any given time ignoring the schedule. The Enforcer will then try to use that key as soon as possible and deprecate the old key(s). The procedure is exactly the same as a configured manual rollover, where a rollover takes place only on user indication. - HSM key pre-generation As entropy is a scarce resource, generating new keys can take a considerable amount of time. The Enforcer tries to keep a pool of pre-generated keys ready to speed up general key management. - Configurable rollover strategy Rollover type is configurable on a per key basis. defaults: KskDoubleSignature ZskPrePublication CskPrePublication Configurations using these settings would minimize transactions with the parent and minimize the number of signatures over the data. see Internet Draft: draft-mekking-dnsop-dnssec-key-timing-bis-02 3 CHANGES FOR THE USER - TTL for zonedata signatures A design decision is that the Enforcer does not have access to the zonefiles. But in order to do completely safe rollovers it must know the value of the longest TTL in the zone. A new tag is introduced in kasp.xml: . If not specified the enforcer will fall back to the old behaviour and use a TTL of 5 days for the signatures over the regular resource records. IMPORTANT NOTE: This TTL is NEVER published. The enforcer uses it to make sure rollovers are always DNSSEC valid. The actual TTLs in the zonefile are used by the signer and published. - ds-seen command has ds-gone counterpart. The decoupling of keys and rollovers (more on this later) makes this command necessary. ds-retract lists every key which DS is currently published at the parent but must be removed. With ds-gone the user can specify that a certain key is actually removed, just like the ds-seen command. - Command channel Just like the signer the enforcer can be interacted with via a client, 'ods-enforcer' in this case. 'ods-enforcer help' for more information about the available commands. 4 TODO BEFORE FINAL RELEASE - Provide migration scripts to support the transition from an earlier OpenDNSSEC installation. - Provide database backend. 5 FUTURE FEATURES - Support for 5011 - Handling of offline HSMs and possibly report next expected HSM access. - Adding zones interactively. The database should become the authoritative source for the configuration. Upon adding a zone via the command channel zonelist.xml should be written. - Support for standby keys. 6 BUILDING FROM SOURCE REPOSITORY When building the Enforcer from the subversion repository two new software dependencies are added: java and protocolbuffers 7 ENFORCER INTERNALS The inner working and behavior of the enforcer is fairly technical and mathematical of nature and this is no place to go in depth about that. There are however some key concepts which may be interesting for some trying to understand the Enforcer's possibilities and limitations. Others may skip this section as no operational information is discussed. The first step in the Enforcer NG is to introduce a cache centered approach rather than a rollover centered approach. In a rollover centered approach the Enforcer would take key A and B, then in a predefined order steps are being taken to introduce B and outroduce A. This is simple to implement but not very flexible. For example it would not be possible to interrupt a rollover from A to B at an arbitrary point in time and start a rollover to key C. The cache centered approach has no notion of what a rollover is but rather how caching validators *may* see the zone. A goal of the Enforcer is to keep the served zones at all times in a DNSSEC valid state (i.e. not bogus), regardless of what is being asked of it. To achieve this keys are completely decoupled from rollovers and policy. Each time the enforcer is active it tries to bring every key to some next state without breaking DNSSEC validation. The DNSSEC rules are mathematically defined but no rolling procedures are defined, it just evaluates validity of a possible move. This is the reason the Enforcer can do all kind of 'weird' rollovers such as algorithm, policy, or HSM rollover. For example, rolling from a split key scenario with a shared KSK to a single key scenario of another algorithm is nothing special. As a consequence the Enforcer SHOULD NEVER output a signer configuration that may lead to some validators declaring the zone bogus. It should be noted that the Enforcer (right now) does not have any senses and needs to trust the signer to run within some interval and publish the zone as well as trust the user not to lie about the DS submission at the parent. Other than that, the user may provide novel/silly input, which may lead to a silly zone but never bogus. 8 NEVER ASKED QUESTIONS Q: How do I perform policy rollover? A: edit zonelist.xml change the policy tag and execute "ods-enforcer update zonelist". Key will now be generated according to the new policy. Alternatively edit the policy in kasp.xml and execute "ods-enforcer update kasp". Q: How do I gracefully unsign my zone? A: Remove all , and/or sections in the policy and than update the kasp. All published keys will now retract. Q: Can I speed up the process when debugging the enforcer? A: Yes, use "ods-enforcer time leap" to immediately execute the first task scheduled. WARNING, never use this in production, this WILL break validation. Q: My KSK does not seem to roll? Q: My ZSK gets replaced before it is fully introduced? A: First check if your KSK and ZSK have the same algorithm configured. If they do, it is possible that you've set your Zone TLL smaller than your ZSK lifetime. A sane policy would have the key lifetime several orders of magnitude bigger than the TTL. Be sure to set your lifetime > MaxZoneTTL + KeyTTL.