DNSSEC Guide : Chapter 6. Advanced Discussions

Yes and no. Good security practice suggests that you should use unique key pairs for each zone, just like how you should have different passwords for your email account, social media login, and online banking credentials. On a technical level, this is completely feasible, but then multiple zones are at risk when one key pair is compromised. If you have hundreds or thousands (or even hundreds of thousands) of zones to administer, a single key pair for all might be less error-prone to manage. You may choose to use the same approach to password management: use unique passwords for your bank accounts and shopping sites, but use a standard password for your not-very-important logins. So categorize your zones, high valued zones (or zones that have specific key rollover requirements) get their own key pairs, while other more "generic" zones can use a single key pair for easier management.

No, it is not required that you create two separate sets of keys, but you should, for operational ease. The DNSSEC protocol itself does not require two classes of keys, but for operational practicality, having two classes of keys make the life of a typical DNS(SEC) administrator's life easier. One of the advantages of having separate ZSKs and KSKs is a better balance between security and ease of use: the KSK can be stored in a secure and less accessible area, while the ZSK is easily accessible for routine use. For more details and considerations on this topic, please refer to RFC 6781 Section 3 .

Please refer to Table 4.1, “ZSK KSK Comparison” for a comparison of how each of the keys are used.

There are at least three algorithm choices for DNSSEC as of this writing (late 2016):

While all three are supported by BIND, RSA is the only one that is mandated to be implemented with DNSSEC and, at the time of writing, is the most widely supported algorithm by both name servers and clients. For the time being, RSA/SHA-256 is the algorithm of choice.

However, RSA is a little long in the tooth, and ECDSA is emerging as the next new cryptographic standard. In fact, the US federal government recommended to stop using RSA altogether by September 2015, and migrate to using ECDSA or similar algorithms.

So for now, use RSA, but keep your eyes on emerging new standards or requirements. For details about rolling over DNSKEYs to a new algorithm, see the section called “DNSKEY Algorithm Rollovers”.

The choice of key sizes is a classic issue of finding the balance between performance and security. The larger the key size, the longer it takes for an attacker to crack the key; but larger keys also means more resources are needed both when generating signatures (authoritative servers) and verifying signatures (recursive servers).

Of the two sets of keys, ZSK is used much more frequently. Whenever zone data changes, or when signatures expire, ZSK is used, so performance certainly is of a bigger concern. As for KSK, it is used less frequently, so performance is less of a factor, but its impact is bigger because of its role in signing other keys.

In this guide, the following key length were chosen for each set, with the recommendation that they be rotated more frequently for better security:

These should be the minimum key sizes one should choose. At the time of writing (late 2016) the root zone and many TLDs are already using 2048 bit ZSKs.

If you choose to implement larger key sizes, keep in mind that larger key size results in larger DNS responses, and this may mean more load on network resources. Depending on network configuration, end users may even experience resolution failures due to the increased response sizes, as we have discussed in the section called “What's EDNS All About (And Why Should I Care)?”.