The Domain Name System is the directory of the Internet, a fundamental service which is required for all the other applications to work. The DNS is so basic and given for granted that its pitfalls are often overlooked; but if your domain name resolution stops working or is captured by an attacker, you are completely out of luck – the sky will fall onto your head.
To fix a number of security flaws in the original DNS design, the DNSSEC extensions have been created. In fact, they have been around for almost twenty years, but their deployment has been slow, because they were perceived as complex, hard to manage, and prone to errors. This is now untrue, and there really is no reason to delay deployment any more.
If you run your own authoritative name servers, DNSSEC deployment typically requires you to work on your primary server to create the two keys (ZSK and KSK), edit a few configuration lines, and generate the DS records; some server applications will even manage key creation and rollover for you. On secondary servers, it is usually enough to activate DNSSEC in the configuration.
The most annoying part usually ends up being the communication of your DS records to the registrar that you used to register the domain name, if you are not a registrar yourself; not all registrars are DNSSEC-friendly yet. Also, as with DKIM keys, KSK rollover requires some planning; you will need to generate the key, communicate the new DS record and get it published together with the old one, then wait for ample propagation time, then deploy the new key and get the old DS record removed. As this procedure may require some attention, the system is designed so that the KSK can be changed seldom, once every one or two years, while maintaining security through the automatic rollover of ZSKs.
If your authoritative name servers are outsourced to your registrar or to another company, then you will have to ask them to do the work for you.
Also, you should take the time to ensure that all your recursive name servers are DNSSEC-enabled. Again, it usually is just a matter of correct configuration; once turned on, even if this will be transparent to final users, the replies to queries for names in DNSSEC-enabled zones will be automatically validated; your users and your servers will be protected from DNS cache poisoning attacks, and will be able to use the innovative technologies built on top of DNSSEC, such as DANE.
From a technical standpoint, there are a few more things to consider. As secure DNS replies are bigger, DNS traffic will move from UDP port 53 to TCP port 53, which needs to be open and reachable. Also, your name servers will be subject to increased bandwidth usage and CPU load; however, as most DNS zones are not signed yet, the immediate increase may not be that significant (it really depends on your usage patterns).
Finally, to ensure adequate security, TES recommends that you use a KSK at least 1024-bit long, and a ZSK at least 2048-bit long.
