We recently added an easy-to-use implementation of DNSSEC in our UI. The currently deployed version in our UI makes it nearly impossible to misconfigure. Every time you make a change, it is queued for review by one of our NOC engineers to ensure that the requested actions will not impact any existing chain of trust. Because of this, you can enable DNSSEC with confidence that we’re here to help!
When an authoritative name server digitally signs a zone, it generates two key pairs, a zone-signing key (ZSK) pair and a key-signing key (KSK) pair. The name server uses the private key of the ZSK pair to sign each RRset in a zone. (An RRset is a group of resource records that are of the same owner, class, and type.) It stores the public key of the ZSK pair in a DNSKEY record. The name server then uses the private key of the KSK pair to sign all DNSKEY records, including its own, and stores the corresponding public key in another DNSKEY record. As a result, a zone has two DNSKEY records; a DNSKEY record that holds the public key of the ZSK pair, and another DNSKEY record for the public key of the KSK pair.
The options presented in our UI dialog allow you to specify how you want to manage these keys.
Once these keys are generated, a Delegation Signer (DS) record is created based on the KSK and is used to authenticate the zone so a resolver can establish a chain of trust from the parent zone (typically the .com, .net, .org, etc.). You will need to add this DS record at your domain registrar (where you bought the domain, typically GoDaddy, Network Solutions etc.) to complete the chain of trust. The registrar places it in the parent zone on your behalf. Until the DS record is installed at your registrar, the chain of trust is not complete, so there is NO RISK to your domain failing to resolve.
In the Domains table, click once on the row for the domain you wish to enable DNSSEC on. Then click EDIT from the toolbar. This will open the main dialog in a new window that looks like this:
Click the checkbox beside “Enable DNSSEC Signing” to reveal the configurable options.
You will now see additional options as shown below:
Default Algorithm: The KSK and ZSK must use the same Algorithm per RFC 6840, so we only provide one selection menu. We currently offer two options. 256 bit or 512 bit.
Key Signing Key (KSK): The Key Signing Key is used to generate a digital signature for the Zone Signing Key. The KSK signs the public ZSK (which is stored in a DNSKEY record) creating an RRSIG for the DNSKEY. DNS will publish the public KSK so resolvers can use it to validate the public ZSK.
Default Key Size: We support various key sizes. Make a selection based on your requirements. (Our current DNSSEC implementation requires that the KSK and ZSK key size be the same. We’ll allow different key sizes in the future.) A larger key means your zone will take slightly longer to resolve (we’re talking milliseconds, not seconds), so it is not too significant. But don’t overdo it. Experts believe it will take 1.5 million years to crack a 2048 bit key.
Default Rollover Period: Choose how often you want to change this key, or put differently, the length of time it should remain valid. The longer (higher) it is, the less frequently you need to update the DS record at your registrar, but keys that are around longer are more susceptible to compromise. For those who want convenience, we offer “infinite” as an option by setting it to 0 (zero). For the super security conscious, we suggest 1 or 2 years (365 or 730 days).
Zone Signing Key (ZSK): Each zone/domain needs a zone-signing key pair. The private part of the key signs each RRset while the public part verifies the signature.
Default Key Size: Same as above. Make a selection based on your requirements.
Default Rollover Period: This is similar to the KSK rollover period, however, zone signing key rollovers are fully automated since they are signed by the KSK and managed by us, so here we recommend something lower for higher security. Additionally, each time you make a change to your zone, the rollover counter resets since new signatures are generated (RRSIG records). We recommend between 90 and 180 days.
Once you have completed configuration and click SAVE, your settings will be queued and reviewed by one of our NOC engineers. When complete, we will email you the Delegation Signer (DS) record for implementation at the root (via your domain registrar).
The DS record will look something like this:
example.com. DS (
12853 ; Key Tag
5 ; Algorithm (RSA/SHA-1)
2 ; Digest Type (SHA-256)
C4A5C4B7472D583980CF872A53D5150A6E0D714497F5D7F7AA5FEB27972B0BC5 ) ; Digest
When you log into your domain registrar, it should be apparent which value goes into each text box. You may need to consult your registrar’s support documentation for assistance. From the above example, you would really only need the values 12853, 5, 2 and the digest (which is a hash of the public key). The other wording after the semi-colon is simply to provide clarification.
Q. Is there any risk involved with enabling DNSSEC via the UI?
A. No. Simply enabling DNSSEC via the UI will not negatively impact your domain, other than adding more records and making it larger. It will create hidden DNSKEY records, will sign your zone and will create other related hidden records like RRSIG, but the mere existence of these additional records has no impact until you complete the chain of trust and add the DS record information at the root. Until you do that, no resolver will expect DNSSEC records, so it will not look for them.
Q. Can I turn off DNSSEC at any time?
A. Yes, you can simply uncheck the “Enable DNSSEC” checkbox at any time to disable it and remove all of the extra DNSSEC records. However, doing so BEFORE you have removed the DS record details from your registrar will break the chain of trust. This may result in your domain becoming unavailable (at least via resolvers that check DNSSEC, not all do yet). Because of this, we highly recommend removing the DS record at your registrar first, waiting 24 hours, and then disabling DNSSEC in our UI. But if you have issues with the chain of trust, you do not need to turn it off in our UI. Simply remove the DS record from your registrar to resume normal non-signed DNS resolution. Once enabled, customers generally never want or need to disable it.
Q. Can I change the DNSSEC parameters at any time?
A. Yes, you may. However, new algorithms and key sizes will break the chain of trust. To ensure this does not happen, when you make the change in the UI, your change will be queued for review. We will first generate a new DS record and provide it to you to ADD (not replace) at your registrar so the old keys can be safely phased out. Without a proper phase-out of the old key, the chain of trust will be broken and DNS may not resolve. Make changes carefully and infrequently, if at all.
Q. What happens when the KSK rollover period arrives?
A. 30 days prior to the KSK expiration/rollover period, we will generate a new key and email you the DS record. You may also receive a notification of this in the UI when you log in during this 30 day period. Failure to ADD (not replace) the DS record at your registrar during that 30 day window will result in your domain becoming untrusted. Therefore it is essential that you maintain accurate contact information by having at least one or more active user account email addresses. We will make weekly attempts to reach you during this 30 day period via email. We recommend making a calendar note to expect a new DS record from us at that time.
When you implement the new DS record we send during the 30 day window, your KSK will properly rollover and there will be no impact to the availability of your domain.
This is perhaps the most important aspect of DNSSEC! Ensuring your KSK never expires.
If you have any further questions, do not hesitate to create a support case. We’re here to help and make this easy for you!