DNSSEC as a push-button service

Written by Rick van Rein in category: Security, Users

An impression of the DNSSEC extension to the zone management user interfaceAt SURFnet, we have a system called SURFdomeinen that simplifies domain management to save our clients work and concerns.  In early 2010, this system was home to about 2500 zones, and it is expected to grow as DNSSEC comes more in demand. The zones are hosted for the Dutch universities and schools of higher education, but even such advanced users appreciate not having to deal with the nitty-gritty details of DNS.

In essence, what this web-based system does is separate conceptual DNS management from operational DNS management.  SURFnet handles all the operational issues, ranging from high-availability hosting to verifying if zones are properly defined.  The web-frontend of SURFdomeinen makes it possible to edit a domain without knowledge of such details.

When introducing DNSSEC, the technicalities of DNS get more complex, especially for newcomers without operational knowledge of DNS.  No wonder then, that we wanted to hide as much of it from our users as possible.  But even for our operational staff the concerns are quite different, and we thought it better to define a new role of DNS security officer to make it simpler to service the issues related to security, rollover timing and other cryptographic cans of worms.

As it turns out, OpenDNSSEC is perfectly suitable for this approach.  It is intended to relieve the DNS operator from most cryptographic and procedure-bound problems, by automating as much as possible.  The only task an OpenDNSSEC operator has is setting up the security and timing parameters that seem suitable.  After that, it is child’s play to plugin more domains, have them signed, and so on.

In a picture, the roles and their separating software layers look like this:

Different levels of concern: conceptual, operational, security

Image components gratuitously provided by OpenClipArt.org

We don’t think it will be possible to conceal the use of DNSSEC entirely from the end user.  One reason is that DNSSEC is not as forgiving as DNS when it comes to zones that break standards.  It is therefore good that the end user makes a deliberate choice to switch on DNSSEC.  We expect them to start off with a harmless experimental domain or two before embarking on it for all their domains.  We should design that level of control into the SURFdomeinen web-interface.

Our ideal for an end-user interface to DNSSEC is a mere pushbutton or toggle to activate and de-activate DNSSEC; In practice, such changes cannot be made instantly, so perhaps we need to add a warning to make this clear and warn off too experimental interactions.  But that ought to be how complex the whole interaction gets: The end user clicks and is asked for confirmation.  Say yes, the procedures for signing your domain will be signed, without the need for this end user to worry anymore about it.  Specifically, without downtime to anyone on the Internet.  The same for removal of signatures.

Respond

*