DNSSEC (Domain Name System Security Extensions) is a security protocol that adds cryptographic signatures to DNS records. This ensures that users are connecting to legitimate websites rather than malicious ones. It also helps prevent attacks like DNS spoofing or cache poisoning by verifying the authenticity and integrity of DNS responses.

Amazon Route 53 is a scalable and highly available domain name system (DNS) web service that helps route end-user requests to applications hosted on AWS. It supports domain registration, DNS routing, and target health checking to ensure reliable application performance. Route 53 also supports security features like DNSSEC. Integrating Amazon Route 53 with DNSSEC tightens security to ensure the authenticity of DNS responses. This helps protect users from malicious attacks, increasing trust and integrity for the Amazon Route 53 hosted domains.

In this note, you will learn how to create a chain of trust using DNSSEC with an Amazon Route 53 hosted zone. And since we’re following DevOps best practices, this use case is built using Terraform and automated using GitHub Actions.

Pre-requisite This note expands on a previous use case, where a static web page was securely accessed over HTTPS (port 443) through a custom domain name instead of using the default load balancer DNS. That setup was achieved using Amazon Route 53 for DNS management and Amazon Certificate Manager (ACM) for SSL/TLS certificate management attached to a load balancer to ensure secure, reliable access to the application. Please familiarize yourself with the AWS cloud services discussed in  - automate-amazon-route-53-hosted-zone-acm-and-load-balancer-provisioning-with-terraform-and-github-actions, since this use case builds upon that.

Deploy AWS cloud resources If you are interested and want to follow along, please refer to the GitHub repository: kunduso/add-aws-elb-ec2-private-subnet-terraform. Please note that the branch name is enable-dnssec-route53.

DNSSEC adds digital signatures to DNS records so that when someone looks up a domain (like amazon.com), they can verify that the DNS info came from the right source and wasn’t tampered with. In AWS, that is achieved by - (i) creating an asymmetric KMS Key for DNSSEC signing, (ii) enabling it for use with Amazon Route53, (iii) associating the KMS Key with the Amazon Route53 hosted zone to create a Key Signing Key, (iv) activating DNSSEC for the hosted zone, and (v) updating the DS records with the domain registrar to link the domain to the DNSSEC chain of trust.

Here is a link to a detailed guide from AWS-Docs on enabling DNSSEC signing and establishing a chain of trust, and a YouTube video: Securing Route 53 hosted zone with DNSSEC.

Let’s go through these in detail, along with the Terraform code.

1. Create an Asymmetric KMS Key for DNSSEC Signing The above Terraform code creates an asymmetric KMS key specifically for DNSSEC signing. The key must be created in the us-east-1 region. It uses the ECC_NIST_P256 algorithm for signing. The key_usage is set to "SIGN_VERIFY" as it is used for cryptographic signing operations.

This asymmetric key pair is crucial for DNSSEC’s security model, where: - The private key component remains secured within AWS KMS - The public key component is used in DNS to allow verification of the signed records The KMS key for DNSSEC must be created in the us-east-1 (N. Virginia) region, specifically because this is a limitation imposed by Amazon Route 53 for DNSSEC implementation

2. Configure KMS Key Policy for Route 53 DNSSEC Access The policy configuration grants necessary permissions for the AWS account root user and the Route 53 DNSSEC service. The first statement (not shown due to space) enables full KMS permissions for the account root user. The second and third statements allow Route 53’s DNSSEC service to perform required operations like signing, describing the key, and managing grants. The condition ensures grants are only created for AWS services.

3. Create a Key Signing Key (KSK) for the Hosted Zone The image above demonstrates creating a Key Signing Key that Amazon Route 53 uses to sign the DNSKEY record set. It associates the KMS key with the hosted zone and sets it ACTIVE for immediate use. The depends_on block manages the sequence of resource provisioning and de-provisioning.

4. Enable DNSSEC Signing for the Hosted Zone This step in the provisioning process enables DNSSEC signing for the hosted zone. The depends_on block ensures the key signing key and ACM certificate validation are completed before enabling DNSSEC. That is necessary to maintain the DNS resolution during the DNSSEC enablement process.

Those are all the AWS cloud resources required to enable DNSSEC on the hosted zone. The next step is to establish the chain of trust by populating the DS records from the Amazon Route 53 DNSSEC Key signing key details.

The repository also contains an output.tf file that displays the values after the terraform apply step is successfully run. Here is a screenshot after a successful terraform apply step: The ds_record provides the key_tag, the signing_algorithm, the digest_algorithm, and finally, the digest.

5. Update the Delegation Signer (DS) Records The values from the terraform apply output must be updated into the DNSSEC DS records. Below is a screenshot of the placeholder to update in Squarespace. Once these values are updated, the DNSSEC chain of trust is established.

DNSSEC Verification There are a few mechanisms to check if the chain of trust is established.

Below is a screenshot of the result of running the PowerShell command Resolve-DnsName -Name kunduso.com -Type DNSKEY This output shows that DNSSEC is configured correctly for kunduso.com. Let’s break down what the DNSKEY records mean:

The first DNSKEY record has a flag value of 256, which identifies it as the Zone Signing Key (ZSK). This key is used to sign all records within the zone. It uses Algorithm 13, which corresponds to ECDSAP256SHA256.

The second DNSKEY record has a flag value of 257, identifying it as the Key Signing Key (KSK). Like the ZSK, it also uses Algorithm 13 (ECDSAP256SHA256). This key is important because it is referenced by the Delegation Signer (DS) record in the parent zone—in this case, it is managed by Squarespace.

The presence of both the ZSK and KSK, using the correct algorithm, aligns with Amazon Route 53 DNSSEC best practices. Their successful return confirms that DNSSEC is configured correctly, the keys are correctly published in the DNS zone, and the DNS infrastructure is accurately serving DNSSEC-related records. However, please note that this is only partially verified.

The next step is to resolve the DnsName for DS records, which is managed via the PowerShell command Resolve-DnsName -Name kunduso.com -Type DS As you can examine, the SOA record was returned instead of the DS record, which indicates that the DS record has not yet been published in the parent zone (in this case, the .com zone at the registrar) and hence, the chain of trust has not yet established.

We see these query returns because the PowerShell command was run before updating the DS Records at Squarespace to show what to expect if the DS record isn’t updated.

Now that we know what to look for, I updated the DS Records at Squarespace. And execute the same PowerShell command: This output shows that the DS records have been successfully published in the parent zone (.com), and the DNSSEC chain of trust is now established.

And that brings us to the end of this note. Enabling DNSSEC for Amazon Route 53 hosted zones allows cloud engineering teams to add an essential layer of security to the DNS infrastructure, protecting customers from DNS spoofing and cache poisoning attacks. If you have any questions or suggestions, please do not hesitate to use the comments section below.

Note: This note is part of a series on elastic load balancing. To learn more, please click on the links below. Add an application load balancer to Amazon EC2 using Terraform Add an application load balancer to Amazon EC2 instances in a private subnet Create an Amazon EC2 Auto Scaling group and load balancer using Terraform and GitHub Actions Automate Amazon Route 53 hosted zone, ACM, and Load Balancer provisioning with Terraform and GitHub Actions Attach AWS WAF to load balancer using Terraform and GitHub Actions Enable Domain Name System (DNS) query logging for Amazon Route 53 hosted zones using Terraform