The power of idempotence

Written by Rick van Rein in category: Architecture, Resilience
Painting orange on an orange wall? Idempotence at work!

WikiMedia Commons

If any design principle has been leading our architectural work around resilience for DNSSEC, it has been idempotence. It is one of those algebraic concepts that really helps to beat sense into a complex set of choices.

Idempotence means that doing the same thing twice is no different from doing it once. Painting orange on an orange wall still delivers an orange wall, to give an example.

The architecture that we defined for OpenDNSSEC signing involves redundant signers. And signers keep state. If one crashes, we are not necessarily aware of how much of the state has reached the secondary server; so how to handle that?

The solution is simple, and derives from the idea of idempotence; Rather than stating what zones to add or remove from the signing facilities, we simply state what the desired situation is. Concretely, we list the zones that we want to have signed, and the key repository to use for each. The underlying system is then required to determine changes with respect to the state it is aware of, and effect any such changes in the usual, automated ways that are part of OpenDNSSEC.

The great benefit derived from this is that the web interface (which we call SURFdomeinen) can be blissfully unaware of its communication partner’s state: Instead of knowing whether it is talking to the master or a slave that is preparing to become a master, it will simply upload the signed-zone list to whoever happens to be interested at that time. Master/slave rollovers need not be bothered with in SURFdomeinen, because the signers themselves care for the differentiation between the current and intended situations.

As it turns out, OpenDNSSEC is a great help with this approach. It does support commands to add or delete zones and policies, but under the hood these commands edit files and then ask the KASP Enforcer to determine what has changed, and update the database accordingly. Basically, OpenDNSSEC supports idempotence at heart! So instead of using the add/delete commands, what we do is generate parts of the configuration and ask the KASP Enforcer directly to update the database with changes. The two configuration files that we generate are:

  • /etc/opendnssec/zonelist.xml with the list of zones received. We use a transaction to pass in the zones and after having received all successfully we explicitly require a command to pass the zones on to the signer. This means that we will always get the full list, generate the complete zonelist.xml from it and let OpenDNSSEC sort out what changes there are.
  • /etc/opendnssec/kasp.xml with a policy for each of the institutions that we serve. As we upload zones, we annotate it with a textual handle for the institution, and use that to assign a policy to each zone as we enter it into the zonelist. The policy per institution is not used to vary cryptographic parameters, but it serves as the scope for a key sharing discipline. Knowing that HSMs generally limit the number of objects/keys they can hold, we decided to share keys within each institution.

If ever our master signer crashes, we assume the best we can, namely that any metadata on DNSSEC keys is in our redundantly shared database. Then all we need to do is upload the zonelist from SURFdomeinen to this slave, generate the configuration files from it and ask OpenDNSSEC to process them and continue signing.

Idempotence is a mathematical statement that says function f applied to the outcome of f always yields the same result as applying f only once but as abstract as that may be, it clearly is a concept that has direct impact on our understanding of the real world. And how to carve out its mechanics in computer scientific constructs. All the way down to the level of programming we have established how the concept can not only structure, but also simplify our reasoning and understanding of what goes on and what needs to be done.

Respond

*