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.