Actor responsibilities towards DNSSEC

Written by Rick van Rein in category: Procedures, Security, Technical, Users

Layers of system induce layers of responsibilities

We are working towards a DNS signing system with various roles at a number of levels. At each of these levels we assign responsibilities, many of which will not be new to the people involved. We are not primarily worried about people with bad intentions (wihtin our organisation), so we do not split roles as zealously as we would if we’d have a cryptographic ball. What we came up with probably makes sense for any community with internal trust, including registrars and companies who do DNSSEC in-house. It is because of the internal trust that we do not object against humans fulfilling more than one role. The roles that we distinguish are:

Conceptual DNS user. This is the end-user who edits DNS zones over a web interface, without any knowledge about operational issues surrounding DNS or DNSSEC. Their responsibilities are straightforward by design:

  • Translating user requirements to conceptual DNS requirements
  • Editing zones accordingly through our web interface “SURFdomeinen”
  • Make a deliberate choice whether to use DNSSEC or not

DNS operator. These are the technicians working behind the SURFdomeinen web interface who maintain the actual publication of the web-entered zone information. In case DNSSEC is requested, the zone data must be sidetracked through a signer before being published. Responsibilities are more technical in nature, but do not involve cryptographic knowledge:

  • Server management: Authoritative DNS servers, notification processing, redundancy.
  • Sidetracking through OpenDNSSEC: If DNSSEC is requested, do not publish the unsigned zone but get it from the OpenDNSSEC signer instead.
  • Monitoring: Presence of valid zone data, processing updates in reasonable time.
  • Processing/propagating zone updates.
  • Zone backup, recovery, redundancy.

Security Officer. These are the people responsible for mindful use of the cryptographic facilities of OpenDNSSEC. They preferably have an active working knowledge of cryptography in general. Responsibilities center around:

  • Choose algorithms, key sizes, timing. Stay up to date with developments.
  • Ensure ZSK rollovers take place in a timely fashion.
  • Ensure KSK rollovers take place in a timely fashion, including parent exchanges.
  • Possibly monitor key material for freshness, signature correctness, key sizes.
  • Overview key backup and recovery, as well as redundancy.
  • Manage the Hardware Security Modules: Partitioning, access control, emergency handling.
  • Manage the OpenDNSSEC signers: Access control, emergency handling.
  • If selected: secure PIN entry to bootstrap Hardware Security Modules after downtime.

Backup Officer. These are responsible for ensuring that fairly recent information is available in a backup location, and can be recovered in disastrous cases. Responsbilities are:

  • Key backups: Arranging the responsible party, regularly making the backups, informing OpenDNSSEC about the success in doing so.
  • Database backups: Dumping the database used by OpenDNSSEC to couple keys to zones and to know that lifecycle state; moving that dump offsite; being able to restore it if need be.

Some people actually play multiple of these roles. As stated, we assume that parties are mutually trusted, so there is no need for separation of roles with the aim to avoid too much control. If you run a digital mint and plan to publish unspent coin identifiers in signed DNS, you should not copy this setup without thinking it over twice.