DNSSec Best Practice for Implementing DNSSec for RegistrarsThis document is meant for registrars and providers of name server service that are interested in providing the DNSSEC service to their customers within the .ee domain zone. The following is to be seen as advice for service providers in delivering a high quality service.
Crypto algorithmsKey algorithms and parameters used in the .ee zone have been published on the Estonian Internet Foundation's (EIS) homepage:
A service provider should take these values as the basis for their own key parameters. Weaker algorithms will make the service provider the weakest link in the DNSSEC trust chain and, thereby, a potential target for attacks. On the other hand, significantly more complex algorithms require more computing resources, while the security of the trust chain as a whole will not increase. The choices of EIS are based on the parameters used in root name servers.
A two key pair systemIt is recommended to use a two key pair system—ZSK and KSK. The ZSK or Zone Signing Key key pair is used for signing records of the specific zone. This key is used quite often, depending on the size of the zone and the number of records; therefore, it is reasonable to keep this key as short as possible in order to optimise computing resources. This in turn means that the key has to be rolled over relatively often for guaranteeing security and reliability. In order to avoid a situation whereby every such rollover requires a corresponding rollover of the key in the .ee zone, a second key pair is used to create the trust chain – KSK, or the Key Signing Key. The public part of the KSK key is forwarded to EIS to validate the DNS records. In order to minimise the rolling over of this key pair, more complex cryptographic algorithms are used for it.
Rollover of ZSK should be performed regularlyThe recommended lifetime of the 1024 bit RSA-SHA256 ZSK key pair is from 3 months to 1 year. EIS recommends rolling over keys of this length at least twice a year. All planned and regular rollovers of keys should be automated.
Use NSEC3NSEC will guarantee that inquiries to the zone regarding non-existing domain names will also get a signed response. However, NSEC3 will make it impossible to read the contents of the zone file with such enquiries.
As parameters for NSEC3, it is recommended to use one iteration with a 64-bit cryptographic salt, with a lifetime similar to that of the signatures.
Document and test proceduresDNSSEC protects against man-in-the-middle and DNS cache poisoning type of attacks. However, managing the keys required for it is another critical point in the DNS system that requires attention, as a mistake there may result in making the protected domain(s) unavailable to a large part of the world.
In order to avoid this, key management and rollover procedures in a regular situation as well as an action plan for a so-called crisis situation where the DNSSEC trust chain is already broken have to be ready. These are procedures that are not carried out every day. Therefore, it is important to have them in writing and tested accordingly. The most important procedures include:
- Regular rollover of keys – ZSK and KSK
- Emergency (attack, system failure, etc.) rollover of keys – ZSK and KSK
- System recovery plan
Publishing of DPS (DNSSEC Practice Statement)DPS is an external document describing DNSSEC management in the specific organization. The aim of the document is to present an overview of the principles, procedures and routines used and to give customers and partners a chance to decide whether they trust this solution.
The DPS should be publicly available in the service introduction section of the organisation's homepage.
One key for multiple zones or a separate key for each zoneThe same key pairs can be used for multiple DNS zones. However, it should be kept in mind that using the same key pair in multiple zones makes it a more significant target for attacks and, if the keys are compromised, the damage is greater. Therefore, if keys are used extensively, more attention should also be paid to their security, e.g. using a dedicated HSM (Hardware Security Module). At the same time, various HSM providers may set their limitations to the number of keys used.
Changing the registrarRegistrars and DNSSEC service providers need to cooperate if the customer has decided to change service providers. As it is necessary for the domain to retain continuous DNSSEC protection, the service provider from whom the customer is leaving should add the DNSSEC public key of the new service
provider to its zone next to the existing keys and serve the domain's DNS records, until it can be assumed that the keys of the new service provider have reached the caches of the majority of resolving name servers, i.e. up to two days after the key has been added.
Please see also:
- http://www.enisa.europa.eu/activities/Resilience-and-CIIP/networks-and- services-resilience/dnssec/gpgdnssec - Good Practices Guide for Deploying DNSSEC
- http://tools.ietf.org/html/rfc6781 - DNSSEC Operational Practices, Version 2
- http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-03 - DNSSEC Key Timing Considerations
- http://www.dnssec-deployment.org/documents/SettingtheParameters.pdf - DNSSEC Operations: Setting the Parameters
- http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf - Secure Domain Name System (DNS) Deployment Guide
- http://tools.ietf.org/html/rfc6841 - A Framework for DNSSEC Policies and DNSSEC Practice Statements