AWS now supports DNS Security Extensions (DNSSEC) signing on public zones for Amazon Route 53 and validation for Amazon Route 53 Resolver. DNSSEC is a specification that provides data integrity assurance for DNS and helps customers meet compliance mandates (for example, FedRAMP and security standards such as NIST). When you enable DNSSEC signing for a hosted zone, Route 53 adds cryptographic signatures to your DNS records. However, signing, by itself, is not sufficient to secure your zone. You also must establish a chain of trust to the zone. When you enable DNSSEC validation for your VPC in Route 53 Resolver, the resolver validates those signatures, confirming that no one tampered with the record. This helps protect you against DNS spoofing, cache poisoning, or other DNS-related man-in-the-middle attacks.
In this blog post, I’ll show you how to enable and disable DNSSEC signing for a hosted zone in Route 53, how to establish a chain of trust to the zone, how to rotate keys without downtime, and how to enable DNSSEC validation for a VPC.
Enabling hosted zone signing in Route 53
You can enable hosted zone signing using the AWS Management Console, CLI, or SDKs. In this post, I’ll show you how to do it by using the console.
Establishing a chain of trust
Next, you set up the chain of trust.
After your registrar adds the DS record for your domain name, you’re all set! Now clients querying your DNS records that use a DNSSEC-enabled resolver can confirm the authenticity of the information received.
If you prefer to use the CLI instead of the console to create a KSK and enable DNS signing for a hosted zone, do the following:aws route53 create-key-signing-key --hosted-zone-id <hz-id> --key-management-service-arn <kms-key-arn> --name <ksk-name> --status ACTIVE --caller-reference <caller-reference> --region <region>aws route53 enable-hosted-zone-dnssec --hosted-zone-id <hz-id> --region <region>
Note: After you run these commands to enable DNSSEC signing, you must follow the earlier steps to set up the chain of trust.
DNSSEC for child zones
To enable DNSSEC signing for a child zone, follow the same steps that you used for a registered domain name. Remember that to establish the chain of trust, you must add the DS record to the parent zone.
Note that for the chain of trust to work correctly, you must enable DNSSEC signing for the parent zone as well. For example, if I enable signing for subdomain1.example.aws, I add a DS record for subdomain1 to the zone example.aws. In addition, I must enable signing for example.aws for DNSSEC to work.
DNSSEC key rotation
Route 53 takes care of most DNSSEC complexities for you, including the handling and rotation of the zone signing key (ZSK). (I haven’t mentioned the ZSK before because Route 53 creates and manages the key for you.) However, you are responsible for rotating the KSK. You might have to perform this rotation every few months, depending on your security policy.
There are several ways to perform a successful KSK rotation. Here, I’ll show you how to rotate your KSKs using the double-RRset method. The basic steps for this method are to do the following:
Incorrectly rotating your KSKs could break DNS resolution for the hosted zone so it’s important to follow the steps carefully.
To add a new KSK, do the following:
To determine the time to live (TTL) values, do the following:dig example.aws NS +short
ns-452.awsdns-56.com.
ns-608.awsdns-12.net.
ns-1346.awsdns-40.org.
ns-1902.awsdns-45.co.uk.
dig example.aws DNSKEY @ns-452.awsdns-56.com
;; ANSWER SECTION:
example.aws. 3600 IN DNSKEY 256 3 13 LNKVN9x3UiSSSKglE2yh5Jcy2v0FKz0jWV1suB7WqME+xkYSubsG8blw GrWBdQ14TOonWpNBgtXhff7Lml02yA==
example.aws. 3600 IN DNSKEY 257 3 13 rCTT3fhLtCy0N1PK4NzdR071gAt2vFPRiGKJ/qOFakqpXBkMhSzD9HZXHPVnQr9fIM7WHvMtE96QAXmAdhggMQ==
The first query returns the nameservers for the example.aws domain’s records. I chose one of them (ns-452.awsdns-56.com), and specified it in the second query to return information about the DNSKEY record. In the results of the second query, I looked for the DNSKEY record that started with 257 and had the same public key as the old KSK. The second column shows the TTL (in seconds) of the record.dig aws NS +short
dns1.nic.aws.
dnsc.nic.aws.
dnsa.nic.aws.
dns3.nic.aws.
dns2.nic.aws.
dns4.nic.aws.
dnsd.nic.aws.
dnsb.nic.aws.dig example.aws DS @dns1.nic.aws
;; ANSWER SECTION:
example.aws. 86400 IN DS 5037 13 2 84C6986D75148EEE3518455C41D7BF2CAB5AC5F9B4F6A69056D765FAF60153E4
The first query returns the nameservers for the aws domain’s records. I chose one of them (dns1.nic.aws), and specified it in the second query. The response to that query listed the TTL (in seconds) of the DS record, in the second column.
IMPORTANT: Wait an interval of at least the maximum of the TTL values returned by the queries (typically 2 days). The previous records are still cached until their TTLs expire, which means that some clients might still be using the old DS or DNSKEY records. If you complete the following step too soon, you could break the chain of trust, which might make your domain unavailable on the internet.
To remove the old DS record, do the following:
To deactivate and delete the original KSK, do the following:
Disabling DNSSEC signing
To turn off DNSSEC for a hosted zone, you delete the DS record that you added when you enabled DNSSEC, and then confirm to Route 53 that you want to disable DNSSEC signing. After you delete the DS record, you must wait for the TTL of that record to expire (typically 2 days).
Important: If you don’t wait for the TTL of the DS record to expire before you continue, your domain could become unavailable on the internet.
After you delete the DS record and the TTL for the record expires, complete disabling DNSSEC signing by doing the following:
The following screenshot shows the steps in the AWS Management Console. Important: If you disable DNSSEC signing before you turn off DNSSEC by deleting the DS record, your domain might become unavailable on the internet.
Enabling DNSSEC validation for a VPC
If you use Amazon Route 53 Resolver for VPCs, you can choose to enable DNSSEC validation on one or more of your VPCs. When you enable DNSSEC validation, when a domain is queried that has an invalid DNSSEC signature, it will resolve as SERVFAIL. Querying unsigned domains is not affected.
To enable DNSSEC validation, do the following:
Alternatively, you can use the AWS CLI to enable validation by doing the following:aws route53resolver update-resolver-dnssec-config --resource-id <vpc-id> --validation ENABLE --region <region>
Testing DNSSEC validation
To test DNSSEC validation on your VPC, log in to an Amazon EC2 instance within the VPC, and then query a domain that is signed incorrectly. For example, you can query the domain dnssec-failed.org. If DNS validation is set up correctly for your VPC, you’ll see a SERVFAIL response, similar to the following:
Compatibility, cryptography, and risks
Finally, let’s look at some common questions around compatibility, encryption, and implementation risks with DNSSEC.
DNSSEC is backwards compatible with traditional DNS, which means that if you use a DNSSEC-enabled resolver, unsigned domains resolve just fine. If you use a DNS resolver that does not support DNSSEC, signed domains will resolve correctly too. However, no validation will be performed.
The following table illustrates the behavior for signed and unsigned domains, with and without DNSSEC validation enabled.
When I hear the word “cryptography,” I often associate it with encryption. However, although DNSSEC uses cryptographic keys, it does not encrypt DNS records. It uses the keys only for signing and validating signatures. In fact, DNSSEC does not modify your existing DNS records at all. It only adds special records that clients use to validate the authenticity of DNS responses.
There are some risks when you enable DNSSEC. The implementation is complex, it adds the task of maintaining and rotating keys, and if it’s set up incorrectly, DNSSEC might make your domain name unavailable on the internet. The good news is that Route 53 takes care of most of that complexity. When you follow the walkthroughs in this blog post, make sure that you follow the correct order of the steps, and pay attention to the minimum wait times (TTLs).
Available now
DNSSEC signing for Route 53 Public DNS and DNSSEC validation for Route 53 Resolver is available today. You can enable DNSSEC signing for all existing and new public hosted zones, and set up DNSSEC validation for your VPCs, by using the AWS Management Console, AWS Command Line Interface (CLI), or AWS SDKs. There is no extra charge to enable DNSSEC signing or validation, however, you do incur AWS KMS charges for the customer managed keys and signing requests. For more information, see the AWS KMS pricing page.
For more information on Route 53, visit the documentation here.
Jorge Prado is a Senior Technical Account Manager at AWS in North Carolina. He is passionate about helping Enterprise Support customers find the right solutions and achieve operational excellence. His focus is on networking technologies. In his free time he enjoys reading, watching movies and playing video games with his kids.
About The Author
More Stories
The Shift in Peering Threatening the Internet’s Foundations
Remembering Alan Barrett: A Builder of the African Internet
From Email to Case Study: What We Learned About Connecting Refugee Communities in Just One Year