How to Enable DNSSEC in your domains

The Domain Name System Security Extensions (DNSSEC) is a set of specifications that extend the DNS protocol by adding cryptographic authentication for responses received from authoritative DNS servers. Its goal is to defend against techniques that hackers use to direct computers to rogue websites and servers.

DNSSEC adds two important features to the DNS protocol:

Data origin authentication allows a resolver to cryptographically verify that the data it received came from the zone where it believes the data originated.
Data integrity protection lets the resolver know that the data hasn't been modified in transit since it was originally signed by the zone owner with the zone's private key.

How do DNS resolvers know how to trust in the DNSSEC keys?

A zone's public key is signed, just like the other data in the zone. However, the public key is not signed by the zone's private key, but by the parent zone's private key.

Every zone's public key is signed by its parent zone, except for the root zone: it has no parent to sign its key.

Therefore, the root zone's public key is an important starting point for validating DNS data. If a resolver trusts the root zone's public key, it can trust the public keys of top-level zones signed by the root's private key, such as the public key for the org zone. And because the resolver can trust the public key for the org zone, it can trust public keys signed by their respective private key, such as the public key for icann.org. (In actual practice, the parent zone doesn't sign the child zone's key directly--the actual mechanism is more complicated--but the effect is the same as if the parent had signed the child's key.)

The sequence of cryptographic key signing is called a chain of trust.

How much does it cost to enable DNSSEC in AWS?

Amazon Route 53 does not charge you to enable DNSSEC signing on your public hosted zones or to enable DNSSEC validation for Amazon Route 53 Resolver. However, when you enable DNSSEC signing on your public hosted zones, you incur AWS Key Management Service (KMS) charges for storing the private key and using the instances of the key to sign your zones. For more information about KMS charges, see the AWS KMS pricing page.

Note that you can choose to use a single customer-managed AWS KMS key that is stored in KMS across multiple public hosted zones.

How do we enable DNSSEC?

Let’s consider we have a root zone in AWS, where we host all our domains, but it still depends on GoDaddy, for example, how could we enable DNSSEC in this case?

First of all, we need to take some considerations:

DNS propagation can take anywhere from a few minutes to 24 hours, depending on the geographical location of the user, the type of DNS record being updated, and the TTL (time to live) value set for the record. During this time, the updated DNS information may not be available to all users and systems immediately.

Pre-requisites

To configure DNSSEC for a domain, your domain, and DNS service provider must meet the following prerequisites:

The registry for the top-level domain (TLD) must support DNSSEC. To determine whether the registry for your TLD supports DNSSEC, see Domains that you can register with Amazon Route 53.
The DNS service provider for the domain must support DNSSEC.
You must configure DNSSEC with the DNS service provider for your domain before you add public keys for the domain to Route 53.
The number of public keys that you can add to a domain depends on the TLD for the domain:
.com and .net domains – up to thirteen keys
All other domains – up to four keys

Before start recommendations

Lowering the zone's maximum TTL will help reduce the wait time between enabling signing and the insertion of the Delegation Signer (DS) record. Lowering the zone's maximum TTL to 1 hour (3600 seconds) allows us to roll back after only an hour if any resolver has problems caching signed records.

Lower the SOA TTL and SOA minimum field.

The SOA minimum field is the last field in the SOA record data.

The SOA TTL and SOA minimum field determines how long resolvers remember negative answers. After you enable signing, Route 53 name servers start returning NSEC records for negative answers. The NSEC contains information that resolvers might use to synthesize a negative answer. If you have to roll back because the NSEC information caused a resolver to assume a negative answer for a name, then you only have to wait for the maximum of the SOA TTL and SOA minimum field for the resolver to stop the assumption.

Make sure the TTL and SOA minimum field changes are effective.Use GetChange to ensure that your changes have been propagated to all Route 53 DNS servers.

Enabling DNSSEC signing at Route 53

Click on Enable DNSSEC signing at the DNSSEC signing tab, in the hosted zone console.

Choose to create a customer-managed CMK
Create KSK and enable signing
After enabling DNSSEC, click on View Information to Create a DS Record.

Check on Establish a chain of trust -> Another Domain Registrar section.

Go Daddy configuration steps

Go to Domain Portfolio -> Domain Settings for your domain and select DNSSEC.
Create a new DS record with the following information:

Key Tag: Key Tag in AWS
Algorithm: Signing Algorithm Type in AWS
Digest Type: Digest Algorithm Type in AWS
Digest: Digest in AWS

Testing

To check if the new configuration is properly set up and the DNS is answering as expected:

dig <YOUR_DOMAIN> dnskey +dnssec

We should receive two DNSKEYs (one for ZSK and another for KSK) and a signed resource record (RRSIG), confirming that the DNS servers are successfully using DNSSEC.

To check the chain of trust with the TLD:

dig com NS +short

The answer should retrieve the TLD server name

dig DS <DOMAIN_WITHOUT_WWW> +short

To make sure we get the DS record for the journeytrack domain from TLD. You should get the DS record shown in the DNSSEC recommendations to create the record.