Why it takes time to switch DNSSEC on and off

Written by Rick van Rein in category: Security, Timing, Users
Setting up DNSSEC takes a bit of patience


As stated elsewhere, DNSSEC is not something that can be turned on and off instantaneously. It is probably useful to explain why that is, as it does affect end-user experiences: Why is my domain not secure as soon as I click this button?

Using DNSSEC means that your DNS data is digitally signed. And, to make such signatures reliably verifiable, it also involves telling the world that those signatures exist, and should be checked. The Internet is split into those that have taken DNSSEC on board and those that haven’t, and the distinction between those classes are made automatically. Those who do not validate will accept all zone data, but those that validate signatures will only accept properly signed and verifiably-unsigned zone data.

If DNSSEC had allowed insecure mechanisms for saying my domain is not digitally signed, then it would not have been difficult to circumvent all the efforts that went into signing domains. So that is not how it works; Instead, there is a secure way to establish whether a domain supports DNSSEC. ¬†The security of any such statements revolves around signatures, once more. Such DNSSEC-enabling or -disabling signatures are made by the domain’s parent. This already shows that the knowledge whether a domain is signed or not is scattered across zones, and across the Internet. Add to that the fact that arbitrary bits and pieces of DNS data may be cached in DNS resolvers anywhere in the world, and it should be clear that the domain state change from unsigned to signed and back cannot be made instantaneously.

As an example problem, it would be problematic if some resolver somewhere has cached the knowledge that a domain is signed, but when it tries to fetch a signature, it runs into a new version of the zone from which signatures have been removed. This would mean that the zone’s records could not be validated, and lead to that data disappearing from the Internet from the perspective of the clients of that resolver. That is not generally what we want!

The opposite can also happen: If a zone is expected to be signed but a validating resolver has cached data without signatures, it may end up not trusting the domain. Most implementations would retrieve the zone data anew, but this is not a guarantee (and can actually lead to operational difficulties in other scenarios) so it is better to avoid this situation.

So, to evade this sort of trouble, great care must go into adding signatures to and removing signatures from zones. The steps should be made in the right order, in a step-by-step procedure. Such procedures take some time; it is not possible to contact every cache that may hold information on our domain, requesting it to update, so their timeouts as setup in DNS have to be respected.

This is why it takes some time to secure a domain with DNSSEC, and why it takes a bit of time before the security is removed. And as a result, a simple toggle to switch DNSSEC on and off for a domain, although a wonderful abstraction, has the practical implication that some time is needed to actually make it happen. What we will do in our tool is to pop up a warning that the process requested will take some time to complete, and only after that can it be reversed. In essence, this is not a button to click too lightly, but do proceed if you are sure you want this.

There is another side to the short delay in getting a domain signed that will help us launch our DNSSEC service: It will enable our administrators to look into a zone for typical problems, and approve or reject a signing request. This may be helpful in avoiding downtime or other problems that the end user may be unaware of. Although we do not expect any real problems, it will be good initially to have some control over domains entering the DNSSEC arena.

No Comments

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.

No Comments

Welcome to the SURFnet DNSSEC blog

Written by Roland van Rijswijk in category: General

SURFnet has been active in the DNSSEC arena for quite some time now. Last year we deployed DNSSEC on our DNS resolvers and we have since learned a great deal about the operational aspects of DNSSEC. We regularly share this information with our constituency and our international peers at conferences and meetings. Since the beginning of this year we have also started work on a DNSSEC deployment for our authoritative DNSSEC infrastructure. This means that we have to integrate a DNSSEC signer, manage keys, etc. Our goal is to integrate this in our managed DNS environment – SURFdomeinen – in such a way that enabling DNSSEC becomes a simple “tick-the-checkbox” action for our users.

The idea to set up this blog came up during one of the project team meetings. We constantly learn new things while working on our DNSSEC deployment and are quite willing to share this information with the wider Internet community. Also, we hope this will result in a concise reference for rolling out DNSSEC as a service, something that may benefit the Internet community as a whole.

The focus of this blog will be to share some of the design considerations and discussions we had while working on our DNSSEC signer integration.

We would greatly appreciate feedback and/or contributions, so please feel free to submit comments or questions!

No Comments