# Configuring DNSSEC signing in Amazon Route 53 Domain Name System Security Extensions (DNSSEC) signing lets DNS resolvers validate that a DNS response came from Amazon Route 53 and has not been tampered with. When you use DNSSEC signing, every response for a hosted zone is signed using public key cryptography. For an overview of DNSSEC, see the DNSSEC section of [AWS re:Invent 2021 - Amazon Route 53: A year in review](https://www.youtube.com/watch?v=77V23phAaAE). In this chapter, we explain how to enable DNSSEC signing for Route 53, how to work with key-signing keys (KSKs), and how to troubleshoot issues. You can work with DNSSEC signing in the AWS Management Console or programmatically with the API. For more information about using the CLI or SDKs to work with Route 53, see [Set up Amazon Route 53](setting-up-route-53.md). Before you enable DNSSEC signing, note the following: + To help prevent a zone outage and avoid problems with your domain becoming unavailable, you must quickly address and resolve DNSSEC errors. We strongly recommend that you set up a CloudWatch alarm that alerts you whenever a `DNSSECInternalFailure` or `DNSSECKeySigningKeysNeedingAction` error is detected. For more information, see [Monitoring hosted zones using Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). + There are two kinds of keys in DNSSEC: a key-signing key (KSK) and a zone-signing key (ZSK). In Route 53 DNSSEC signing, each KSK is based on an [asymmetric customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept) in AWS KMS that you own. You are responsible for KSK management, which includes rotating it if needed. ZSK management is performed by Route 53. + When you enable DNSSEC signing for a hosted zone, Route 53 limits the TTL to one week. If you set a TTL of more than one week for records in the hosted zone, you don't get an error. However, Route 53 enforces a TTL of one week for the records. Records that have a TTL of less than one week and records in other hosted zones that do not have DNSSEC signing enabled are not affected. + When you use DNSSEC signing, multi-vendor configurations are not supported. If you have configured white-label name servers (also known as vanity name servers or private name servers), make sure those name servers are provided by a single DNS provider. + Some DNS providers do not support Delegation Signer (DS) records in their authoritative DNS. If your parent zone is hosted by a DNS provider who does not support DS queries (not setting AA flag in the DS query response), then when you enable DNSSEC in its child zone, the child zone will become unresolvable. Make sure your DNS provider supports DS records. + It can be helpful to set up IAM permissions to allow another user, besides the zone owner, to add or remove records in the zone. For example, a zone owner can add a KSK and enable signing, and might also be responsible for key rotation. However, someone else might be responsible for working with other records for the hosted zone. For an example IAM policy, see [Example permissions for a domain record owner](access-control-managing-permissions.md#example-permissions-record-owner). + To check to see if the TLD has DNSSEC support, see [Domains that you can register with Amazon Route 53](registrar-tld-list.md). **Topics** + [ # Enabling DNSSEC signing and establishing a chain of trust ](dns-configuring-dnssec-enable-signing.md) + [ # Disabling DNSSEC signing ](dns-configuring-dnssec-disable.md) + [ # Working with customer managed keys for DNSSEC ](dns-configuring-dnssec-cmk-requirements.md) + [ # Working with key-signing keys (KSKs) ](dns-configuring-dnssec-ksk.md) + [ # KMS key and ZSK management in Route 53 ](dns-configuring-dnssec-zsk-management.md) + [ # DNSSEC proofs of nonexistence in Route 53 ](dns-configuring-dnssec-proof-of-nonexistence.md) + [ # Troubleshooting DNSSEC signing ](dns-configuring-dnssec-troubleshoot.md) # Enabling DNSSEC signing and establishing a chain of trust **** The incremental steps apply to the hosted zone owner and the parent zone maintainer. This can be the same person, but if not, the zone owner should notify and work with the parent zone maintainer. We recommend following the steps in this article to have your zone signed and included in the chain of trust. The following steps will minimize the risk of onboarding onto DNSSEC. **Note** Make sure you read the prerequisites before you start in [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md). There are three steps to take to enable DNSSEC signing, as described in the following sections. **Topics** + [ ## Step 1: Prepare for enabling DNSSEC signing ](#dns-configuring-dnssec-enable-signing-step-1) + [ ## Step 2: Enable DNSSEC signing and create a KSK ](#dns-configuring-dnssec-enable) + [ ## Step 3: Establish chain of trust ](#dns-configuring-dnssec-chain-of-trust) ## Step 1: Prepare for enabling DNSSEC signing The preparation steps help you minimize the risk of onboarding to DNSSEC by monitoring zone availability and lowering wait times between enabling signing and the insertion of the Delegation Signer (DS) record. **To prepare for enabling DNSSEC signing** 1. Monitor zone availability. You can monitor the zone for the availability of your domain names. This can help you address any issues that might warrant rolling a step back after you enable DNSSEC signing. You can monitor for your domain names with most traffic by using query logging. For more information about setting up query logging, see [Monitoring Amazon Route 53](monitoring-overview.md). The monitoring can be done through a shell script, or through a third party service. It shouldn't, however, be the only signal to determine if a rollback is required. You might also get feedback from your customers due to a domain not being available. 1. Lower the zone's maximum TTL. The zone’s maximum TTL is the longest TTL record in the zone. In the following example zone, the zone’s maximum TTL is 1 day (86400 seconds). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) Lowering the zone's maximum TTL will help reduce the wait time between enabling signing and the insertion of the Delegation Signer (DS) record. We recommend lowering the zone's maximum TTL to 1 hour (3600 seconds). This allows you to roll back after only an hour if any resolver has problems with caching signed records. **Rollback:** undo the TTL changes. 1. Lower the SOA TTL and SOA minimum field. The SOA minimum field is the last field in the SOA record data. In the following example SOA record, the minimum field has the value of 5 minutes (300 seconds). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) 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. **Rollback:** undo the SOA changes. 1. Make sure the TTL and SOA minimum field changes are effective. Use [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) to make sure your changes so far have been propagated to all Route 53 DNS servers. ## Step 2: Enable DNSSEC signing and create a KSK You can enable DNSSEC signing and create a key-signing key (KSK) by using AWS CLI or on the Route 53 console. + [CLI](#dnssec_CLI) + [Console](#dnssec_console) When you provide or create a KMS key, there are several requirements. For more information, see [Working with customer managed keys for DNSSEC](dns-configuring-dnssec-cmk-requirements.md). ------ #### [ CLI ] You can use a key that you already have, or create one by running an AWS CLI command like the following using your own values for `hostedzone_id`, `cmk_arn`, `ksk_name`, and `unique_string` (to make the request unique): ``` aws --region us-east-1 route53 create-key-signing-key \ --hosted-zone-id $hostedzone_id \ --key-management-service-arn $cmk_arn --name $ksk_name \ --status ACTIVE \ --caller-reference $unique_string ``` For more information about customer managed keys, see [Working with customer managed keys for DNSSEC](dns-configuring-dnssec-cmk-requirements.md). See also [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html). To enable DNSSEC signing, run an AWS CLI command like the following, using your own value for the `hostedzone_id`: ``` aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` For more information, see [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html) and [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html). ------ #### [ Console ] **To enable DNSSEC signing and create a KSK** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**, and then choose a hosted zone that you want to enable DNSSEC signing for. 1. On the **DNSSEC signing** tab, choose **Enable DNSSEC signing**. **Note** If the option in this section is **Disable DNSSEC signing**, you have already completed the first step in enabling DNSSEC signing. Be sure that you establish, or that there already exists, a chain of trust for the hosted zone for DNSSEC, and then you're done. For more information, see [Step 3: Establish chain of trust](#dns-configuring-dnssec-chain-of-trust). 1. In the **Key-signing key (KSK) creation** section, choose **Create new KSK**, and under **Provide KSK name**, enter a name for the KSK that Route 53 will create for you. The name can include numbers, letters, and underscores (\$1). It must be unique. 1. Under **Customer managed CMK**, choose the customer managed key for Route 53 to use when it creates the KSK for you. You can use an existing customer managed key that applies to DNSSEC signing, or create a new customer managed key. When you provide or create a customer managed key, there are several requirements. For more information, see [Working with customer managed keys for DNSSEC](dns-configuring-dnssec-cmk-requirements.md). 1. Enter the alias for an existing customer managed key. If you want to use a new customer managed key, enter an alias for the customer managed key, and Route 53 will create one for you. **Note** If you choose to have Route 53 create a customer managed key, be aware that separate charges apply for each customer managed key. For more information, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/). 1. Choose **Enable DNSSEC signing**. ------ **After you enable zone signing, complete the following steps** (whether you used the console or the CLI): 1. Ensure zone signing is effective. If you used AWS CLI, you can use the operation Id from the output of the `EnableHostedZoneDNSSEC()` call to run [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) or [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) to make sure that all Route 53 DNS Servers are signing responses (status = `INSYNC`). 1. Wait for at least the previous zone’s maximum TTL. Wait for resolvers to flush all unsigned records from their cache. To achieve this you should wait for at least the previous zone’s maximum TTL. In the `example.com` zone above, the wait time would be 1 day. 1. Monitor for reports of customer issues. After you have enabled zone signing, your customers might start seeing issues related to network devices and resolvers. The recommended monitoring period is 2 weeks. The following are examples of issues that you might see: + Some network devices can limit DNS response size to under 512 bytes, which is too small for some signed responses. These network devices should be reconfigured to allow larger DNS response sizes. + Some network devices do a deep inspection on DNS responses and strips certain records it doesn’t understand, like the ones used for DNSSEC. These devices should be reconfigured. + Some customers’ resolvers claim that they can accept a larger UDP response than their network supports. You can test your network capability and configure your resolvers appropriately. For more information see, [DNS Reply Size Test Server](https://www.dns-oarc.net/oarc/services/replysizetest/). **Rollback:** call [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) then rollback the steps in [Step 1: Prepare for enabling DNSSEC signing](#dns-configuring-dnssec-enable-signing-step-1). ## Step 3: Establish chain of trust After you enable DNSSEC signing for a hosted zone in Route 53, establish a chain of trust for the hosted zone to complete your DNSSEC signing setup. You do this by creating a Delegation Signer (DS) record in the *parent* hosted zone, for your hosted zone, using the information that Route 53 provides. Depending on where your domain is registered, you add the record to the parent hosted zone in Route 53 or at another domain registrar. **To establish a chain of trust for DNSSEC signing** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**, and then choose a hosted zone that you want to establish a DNSSEC chain of trust for. *You must enable DNSSEC signing first.* 1. On the **DNSSEC signing** tab, under **DNSSEC signing**, choose **View information to create DS record**. **Note** If you don't see **View information to create DS record** in this section, then you must enable DNSSEC signing before you establish the chain of trust. Choose **Enable DNSSEC signing** and complete the steps as described in [Step 2: Enable DNSSEC signing and create a KSK](#dns-configuring-dnssec-enable), and then return to these steps to establish the chain of trust. 1. Under **Establish a chain of trust**, choose either **Route 53 registrar** or **Another domain registrar**, depending on where your domain is registered. 1. Use the provided values from step 3 to create a DS record for the parent hosted zone in Route 53. If your domain is not hosted at Route 53, use the provided values to create a DS record at your domain registrar website. Establish a chain of trust for the parent zone: + If your domain is managed through Route 53, follow these steps: Make sure that you configure the correct signing algorithm (ECDSAP256SHA256 and type 13) and digest algorithm (SHA-256 and type 2). If Route 53 is your registrar, do the following in the Route 53 console: 1. Note the **Key type**, **Signing algorithm**, and **Public key** values. In the navigation pane, choose **Registered domains**. 1. Select a domain, and then, within the **DNSSEC keys** tab, choose **Add key**. 1. In the **Manage DNSSEC keys** dialog box, choose the appropriate **Key type** and **Algorithm** for the **Route 53 registrar** from the dropdown menus. 1. Copy the **Public key** for the Route 53 registrar. In the **Manage DNSSEC keys** dialog box, paste the value into the **Public key** box. 1. Choose **Add**. Route 53 will add the DS record to the parent zone from the public key. For example, if your domain is `example.com`, the DS record is added to the .com DNS zone. + If your domain is managed on another registry, follow the instructions in the **Another domain registrar** section. To make sure the following steps go smoothly, introduce a low DS TTL to the parent zone. We recommend setting the DS TTL to 5 minutes (300 seconds) for faster recovery if you need to roll your changes back. + Establish a chain of trust for the child zone: If your parent zone is administered by another registry, contact your registrar to introduce the DS record for your zone. Typically you will not be able to adjust the TTL of the DS record. + If your parent zone is hosted on Route 53, contact the parent zone owner to introduce the DS record for your zone. Provide the `$ds_record_value` to the parent zone owner. You can get it by clicking on the **View Information to create DS record** in the console and copying the **DS record** field, or by calling [GetDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) API and retrieving the value of the ‘DSRecord’ field: ``` aws --region us-east-1 route53 get-dnssec --hosted-zone-id $hostedzone_id ``` The parent zone owner can insert the record through the Route 53 console or CLI. + To insert the DS record by using AWS CLI, the parent zone owner creates and names a JSON file similar to the following example. The parent zone owner might name the file something like `inserting_ds.json`. ``` { "HostedZoneId": "$parent_zone_id", "ChangeBatch": { "Comment": "Inserting DS for zone $zone_name", "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "$zone_name", "Type": "DS", "TTL": 300, "ResourceRecords": [ { "Value": "$ds_record_value" } ] } } ] } } ``` Then run the following command: ``` aws --region us-east-1 route53 change-resource-record-sets --cli-input-json file://inserting_ds.json ``` + To insert the DS record by using the console, Open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). In the navigation pane, choose **Hosted zones**, the name of your hosted zone and then **Create record** button. Make sure you choose Simple routing for the **Routing policy**. In the **Record name** field enter the same name as the `$zone_name`, select DS from the **Record type** drop-down, and enter the value of `$ds_record_value` into the **Value** field, and choose **Create records**. **Rollback:** remove the DS from the parent zone, wait for the DS TTL, and then roll back the steps for establishing trust. If the parent zone is hosted on Route 53, the parent zone owner can change the `Action` from `UPSERT` to `DELETE` in the JSON file, and re-run the example CLI above. 1. Wait for the updates to propagate, based on the TTL for your domain records. If the parent zone is on Route 53 DNS service, the parent zone owner can confirm full propagation through the [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API. Otherwise, you can periodically probe the parent zone for the DS record, and then wait another 10 minutes afterwards to increase the probability of the DS record insertion being fully propagated. Do note that some registrars have scheduled DS insertion, for example, once a day. When you introduce the Delegation Signer (DS) record in the parent zone, the validated resolvers that have picked up the DS will start validating responses from the zone. To make sure the steps for establishing trust go smoothly, complete the following: 1. Find the maximum NS TTL. There are 2 sets of NS records associated with your zones: + The delegation NS record — this is the NS record for your zone held by the parent zone. You can find this by running the following Unix commands (if your zone is example.com, the parent zone is com): `dig -t NS com` Pick one of the NS records and then run the following: `dig @one of the NS records of your parent zone -t NS example.com` For example: `dig @b.gtld-servers.net. -t NS example.com` + The in-zone NS record — this is the NS record in your zone. You can find this by running the following Unix command: `dig @one of the NS records of your zone -t NS example.com` For example: `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` Note the maximum TTL for both zones. 1. Wait for the maximum NS TTL. Prior to the DS insertion, resolvers are getting a signed response, but aren't validating the signature. When the DS record is inserted, resolvers will not see it until the NS record for the zone expires. When resolvers re-fetch the NS record, the DS record will then be also returned. If your customer is running a resolver on a host with an out of sync clock, make sure the clock is within 1 hour of the correct time. After completing this step, all DNSSEC-aware resolvers will validate your zone. 1. Observe name resolution. You should observe that there are no issues with resolvers validating your zone. Make sure you also account for the time needed for your customers to report problems to you. We recommend monitoring for up to 2 weeks. 1. (Optional) Lengthen the DS and NS TTLs. If you are satisfied with the setup, you can save the TTL and SOA changes you made. Note that Route 53 limits the TTL to 1 week for signed zones. For more information, see [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md). If you can change the DS TTL, we recommend that you set it to 1 hour. # Disabling DNSSEC signing The steps for disabling DNSSEC signing in Route 53 vary, depending on the chain of trust that your hosted zone is part of. For example, your hosted zone might have a parent zone that has a Delegation Signer (DS) record, as part of a chain of trust. Your hosted zone might also be itself a parent zone for child zones that have enabled DNSSEC signing, which is another part of the chain of trust. Investigate and determine the full chain of trust for your hosted zone before you take the steps to disable DNSSEC signing. The chain of trust for your hosted zone that enables DNSSEC signing must be carefully undone as you disable signing. To remove your hosted zone from the chain of trust, you remove all DS records that are in place for the chain of trust that includes this hosted zone. This means that you must do the following, in order: 1. Remove any DS records that this hosted zone has for child zones that are part of a chain of trust. 1. Remove the DS record from the parent zone. Skip this step if you have an island of trust (there are no DS records in the parent zone and no DS records for child zones in this zone). 1. If you are not able to remove DS records, in order to remove the zone from the chain of trust, remove NS records from the parent zone. For more information, see [Adding or changing name servers and glue records for a domain](domain-name-servers-glue-records.md). The following incremental steps allow you to monitor the effectiveness of the individual steps to avoid DNS availability issues in your zone. **To disable DNSSEC signing** 1. Monitor zone availability. You can monitor the zone for the availability of your domain names. This can help you address any issues that might warrant rolling a step back after you enable DNSSEC signing. You can monitor for your domain names with most traffic by using query logging. For more information about setting up query logging, see [Monitoring Amazon Route 53](monitoring-overview.md). The monitoring can be done through a shell script, or through a paid service. It shouldn't, however, be the only signal to determine if a rollback is required. You might also get feedback from your customers due to a domain not being available. 1. Find the current DS TTL. You can find the DS TTL by running the following Unix command: `dig -t DS example.com example.com` 1. Find the maximum NS TTL. There are 2 sets of NS records associated with your zones: + The delegation NS record — this is the NS record for your zone held by the parent zone. You can find this by running the following Unix commands: First find the NS of your parent zone (if your zone is example.com, the parent zone is com): `dig -t NS com` Pick one of the NS records and then run the following: `dig @one of the NS records of your parent zone -t NS example.com` For example: `dig @b.gtld-servers.net. -t NS example.com` + The in-zone NS record — this is the NS record in your zone. You can find this by running the following Unix command: `dig @one of the NS records of your zone -t NS example.com` For example: `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` Note the maximum TTL for both zones. 1. Remove the DS record from the parent zone. Contact the parent zone owner to remove the DS record. **Rollback:** re-insert the DS record, confirm DS insertion is effective, and wait for the maximum NS (not DS) TTL before all resolvers will start validating again. 1. Confirm the DS removal is effective. If the parent zone is on Route 53 DNS service, the parent zone owner can confirm full propagation through the [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API. Otherwise, you can periodically probe the parent zone for the DS record, and then wait another 10 minutes afterwards to increase the probability of the DS record removal being fully propagated. Do note that some registrars have scheduled DS removal, for example once a day. 1. Wait for the DS TTL. Wait until all resolvers have expired the DS record from their caches. 1. Disable DNSSEC signing and deactivate the key-signing key (KSK). + [CLI](#CLI_dnssec_disable) + [Console](#console_dnssec_disable) ------ #### [ CLI ] Call [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) and [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) APIs. For example: ``` aws --region us-east-1 route53 disable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id aws --region us-east-1 route53 deactivate-key-signing-key \ --hosted-zone-id $hostedzone_id --name $ksk_name ``` ------ #### [ Console ] **To disable DNSSEC signing** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**, and then choose a hosted zone that you want to disable DNSSEC signing for. 1. On the **DNSSEC signing** tab, choose **Disable DNSSEC signing**. 1. On the **Disable DNSSEC signing** page, choose one of the following options, depending on your scenario for the zone that you're disabling DNSSEC signing for. + **Parent zone only** — This zone has a parent zone with a DS record. In this scenario, you must remove the parent zone's DS record. + **Child zones only** — This zone has a DS record for a chain of trust with one or more child zones. In this scenario, you must remove the zone's DS records. + **Parent and child zones** — This zone has both a DS record for a chain of trust with one or more child zones *and* a parent zone with a DS record. In this scenario, do the following, in order: 1. Remove the zone's DS records. 1. Remove the parent zone's DS record. If you have an island of trust, you can skip this step. 1. Determine what the TTL is for each DS record that you remove in Step 4.,Make sure that the longest TTL period has expired. 1. Select the check box to confirm that you have followed the steps in order. 1. Type *disable* in the field, as shown, and then choose **Disable**. **To deactivate the key-signing key (KSK)** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**, and then choose a hosted zone that you want to deactivate the key-signing key (KSK) for. 1. In the **Key-signing keys (KSKs)** section, choose the KSK you want to deactivate, and under **Actions**, choose **Edit KSK**, set **KSK status** to **Inactive**, and then choose **Save KSK**. ------ **Rollback:** call [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) and [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) APIs. For example: ``` aws --region us-east-1 route53 activate-key-signing-key \ --hosted-zone-id $hostedzone_id --name $ksk_name aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` 1. Confirm disabling zone signing is effective. Use the Id from the `EnableHostedZoneDNSSEC()` call to run [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) to make sure that all Route 53 DNS Servers have stopped signing responses (status = `INSYNC`). 1. Observe name resolution. You should observe that there are no issues resulting in resolvers validating your zone. Allow 1-2 weeks to also account for the time needed for your customers to report problems to you. 1. (Optional) Clean up. If you will not re-enable signing, you can clean up the KSKs through [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html) and delete the corresponding customer managed key to save costs. # Working with customer managed keys for DNSSEC When you enable DNSSEC signing in Amazon Route 53, Route 53 creates a key-signing key (KSK) for you. To create a KSK, Route 53 must use a customer managed key in AWS Key Management Service that supports DNSSEC. This section describes the details and requirements for the customer managed key that are helpful to know as you work with DNSSEC. Keep the following in mind when you work with customer managed keys for DNSSEC: + The customer managed key that you use with DNSSEC signing must be in the US East (N. Virginia) Region. + The customer managed key must be an [asymmetric customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks) with an [ECC\$1NIST\$1P256 key spec](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc). These customer managed keys are used only for signing and verification. For help creating an asymmetric customer managed key, see [Creating asymmetric customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) in the AWS Key Management Service Developer Guide. For help finding the cryptographic configuration of an existing customer managed key, see [Viewing the cryptographic configuration of customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html) in the AWS Key Management Service Developer Guide. + If you create a customer managed key yourself to use with DNSSEC in Route 53, you must include specific key policy statements that give Route 53 the required permissions. Route 53 must be able to access your customer managed key so that it can create a KSK for you. For more information, see [Route 53 customer managed key permissions required for DNSSEC signing](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC). + Route 53 can create a customer managed key for you in AWS KMS to use with DNSSEC signing without additional AWS KMS permissions. However, you must have specific permissions if you want to edit the key after it's created. The specific permissions that you must have are the following: `kms:UpdateKeyDescription`, `kms:UpdateAlias`, and `kms:PutKeyPolicy`. + Be aware that separate charges apply for each customer managed key that you have, whether you create the customer managed key or Route 53 creates it for you. For more information, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/). # Working with key-signing keys (KSKs) When you enable DNSSEC signing, Route 53 creates a key-signing key (KSK) for you. You can have up to two KSKs per hosted zone in Route 53. After you enable DNSSEC signing, you can add, remove, or edit your KSKs. Note the following when you work with your KSKs: + Before you can delete a KSK, you must edit the KSK to set its status to **Inactive**. + When DNSSEC signing is enabled for a hosted zone, Route 53 limits the TTL to one week. If you set a TTL for records in the hosted zone to more than one week, you don't get an error, but Route 53 enforces a TTL of one week. + To help prevent a zone outage and avoid problems with your domain becoming unavailable, you must quickly address and resolve DNSSEC errors. We strongly recommend that you set up a CloudWatch alarm that alerts you whenever a `DNSSECInternalFailure` or `DNSSECKeySigningKeysNeedingAction` error is detected. For more information, see [Monitoring hosted zones using Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). + The KSK operations described in this section allow you to rotate your zone’s KSKs. For more information and a step-by-step example, see *DNSSEC Key Rotation* in the blog post [ Configuring DNSSEC signing and validation with Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/). To work with KSKs in the AWS Management Console, follow the guidance in the following sections. ## Add a key-signing key (KSK) When you enable DNSSEC signing, Route 53 creates a key-signing (KSK) for you. You can also add KSKs separately. You can have up to two KSKs per hosted zone in Route 53. When you create a KSK, you must provide or request Route 53 to create a customer managed key to use with the KSK. When you provide or create a customer managed key, there are several requirements. For more information, see [Working with customer managed keys for DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Follow these steps to add a KSK in the AWS Management Console. **To add a KSK** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**, and then choose a hosted zone. 1. On the **DNSSEC signing** tab, under **Key-signing keys (KSKs)**, choose **Switch to advanced view**, and then, under **Actions**, choose **Add KSK**. 1. Under **KSK**, enter a name for the KSK that Route 53 will create for you. The name can include numbers, letters, and underscores (\$1). It must be unique. 1. Enter the alias for a customer managed key that applies to DNSSEC signing, or enter an alias for a new customer managed key that Route 53 will create for you. **Note** If you choose to have Route 53 create a customer managed key, be aware that separate charges apply for each customer managed key. For more information, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/). 1. Choose **Create KSK**. ## Edit a key-signing key (KSK) You can edit the status of a KSK to be **Active** or **Inactive**. When a KSK is active, Route 53 uses that KSK for DNSSEC signing. Before you can delete a KSK, you must edit the KSK to set its status to **Inactive**. Follow these steps to edit a KSK in the AWS Management Console. **To edit a KSK** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**, and then choose a hosted zone. 1. On the **DNSSEC signing** tab, under **Key-signing keys (KSKs)**, choose **Switch to advanced view**, and then, under **Actions**, choose **Edit KSK**. 1. Make the desired updates to the KSK, and then choose **Save**. ## Delete a key-signing key (KSK) Before you can delete a KSK, you must edit the KSK to set its status to **Inactive**. One reason that you might delete a KSK is as part of routine key rotation. It's a best practice to rotate cryptographic keys periodically. Your organization might have standard guidance for how often to rotate keys. Follow these steps to delete a KSK in the AWS Management Console. **To delete a KSK** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **Hosted zones**, and then choose a hosted zone. 1. On the **DNSSEC signing** tab, under **Key-signing keys (KSKs)**, choose **Switch to advanced view**, and then under **Actions**, choose **Delete KSK**. 1. Follow the guidance to confirm deleting the KSK. # KMS key and ZSK management in Route 53 This section describes the current practice Route 53 uses for your DNSSEC signing enabled zones. **Note** Route 53 uses the following rule which might change. Any future changes will not reduce your zone's or Route 53's security posture. **How Route 53 uses the AWS KMS associated with your KSK** In DNSSEC, the KSK is used to generate the resource record signature (RRSIG) for the DNSKEY resource record set. All `ACTIVE` KSKs are used in the RRSIG generation. Route 53 generates an RRSIG by calling the `Sign` AWS KMS API on the associated KMS key. For more information, see [Sign](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) in the *AWS KMS API guide*. These RRSIGs do not count towards the zone’s resource record set limit. RRSIG has an expiration. To prevent the RRSIGs from expiring, the RRSIGs are refreshed regularly by regenerating them every one to seven days. The RRSIGs are also refreshed every time you call any of these APIs: + [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) + [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html) + [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) + [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html) + [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) + [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) Every time Route 53 performs a refresh, we generate 15 RRSIGs to cover the next few days in case the associated KMS key becomes inaccessible. For KMS key cost estimation, you can assume a once a day regular refresh. A KMS key might become inaccessible by inadvertent changes to the KMS key policy. Inaccessible KMS key will set the associated KSK’s status to `ACTION_NEEDED`. We strongly recommend that you monitor this condition by setting up a CloudWatch alarm whenever a `DNSSECKeySigningKeysNeedingAction` error is detected because validating resolvers will start failing lookups after the last RRSIG expires. For more information, see [Monitoring hosted zones using Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). **How Route 53 manages your zone’s ZSK** Each new hosted zone with DNSSEC signing enabled will have one `ACTIVE` zone signing key (ZSK). The ZSK is generated separately for each hosted zone and is owned by Route 53. The current key algorithm is ECDSAP256SHA256. We will start performing regular ZSK rotation on the zone within 7–30 days of the start of signing. Currently, Route 53 uses the Pre-Publish Key Rollover method. For more information, see [Pre-Publish Zone Signing Key Rollover](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1). This method will introduce another ZSK to the zone. The rotation will be repeated every 7–30 days. Route 53 will suspend ZSK rotation if any of the zone’s KSK is in `ACTION_NEEDED` status because Route 53 will not be able to regenerate the RRSIGs for DNSKEY resource record sets to account for the changes in the zone’s ZSK. ZSK rotation will automatically resume after the condition is cleared. # DNSSEC proofs of nonexistence in Route 53 **Note** Route 53 uses the following rule which might change. Any future changes will not reduce your zone's or Route 53's security posture. There are three kinds of proof of nonexistence in DNSSEC: + Proof of nonexistence of a record matching the query name. + Proof of nonexistence of a type matching the query type. + Proof of existence of a wildcard record used to generate the record in response. Route 53 implements the proof of nonexistence of a record matching the query name using the BL method. For more information, see [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00). It's a method that produces a compact representation of the proof and prevents zone walking. In cases where there is a record matching the query name but not the query type (such as querying for web.example.com/AAAA but there is only web.example.com/A present), we return a minimal NSEC (next secure) record containing all supported resource record types. When Route 53 synthesizes an answer from a wildcard record, the response will not be accompanied with a next secure record, or NSEC record for the wildcard. Such NSEC record is used in some implementations, typically those performing offline signing, to prevent the resource record signatures (RRSIG) in the response from being re-used to spoof a different response. Route 53 uses online signing for non-DNSKEY records to generate RRSIGs specific to the response which cannot be re-used for a different response. # Troubleshooting DNSSEC signing The information in this section can help you address issues with DNSSEC signing, including enabling, disabling, and with your key-signing keys (KSKs). Enabling DNSSEC Make sure you have read the prerequisites in [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md) before you start enabling DNSSEC signing. Disabling DNSSEC In order to safely disable DNSSEC, Route 53 will check whether the target zone is in the chain of trust. It checks if the parent of the target zone has any NS records of the target zone and DS records of the target zone. If the target zone is not publicly resolvable, for example, getting a SERVFAIL response when querying for NS and DS, Route 53 cannot determine whether it is safe to disable DNSSEC. You can contact your parent zone to fix those issues, and retry disabling DNSSEC later. KSK status is **Action needed** A KSK can change its status to **Action needed** (or `ACTION_NEEDED` in a [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) status), when Route 53 DNSSEC loses access to a corresponding AWS KMS key (due to a change in permissions or AWS KMS key deletion). If the status of a KSK is **Action needed**, it means that eventually it'll cause a zone outage for clients using DNSSEC validating resolvers and you must act fast to prevent a production zone becoming un-resolvable. To correct the problem, make sure that the customer managed key that your KSK is based on is enabled and has the correct permissions. For more information about the required permissions, see [Route 53 customer managed key permissions required for DNSSEC signing](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC). After you have fixed the KSK, activate it again by using the console or the AWS CLI, as described in [Step 2: Enable DNSSEC signing and create a KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable). To prevent this issue in the future, consider adding an Amazon CloudWatch metric to track the state of the KSK as suggested in [Configuring DNSSEC signing in Amazon Route 53](dns-configuring-dnssec.md). KSK status is **Internal failure** When a KSK has a status of **Internal failure** (or `INTERNAL_FAILURE` in a [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) status), you can't work with any other DNSSEC entities until the problem is resolved. You must take action before you can work with DNSSEC signing, including working with this KSK or your other KSK. To correct the problem, try again to activate or deactivate the KSK. To correct the problem when working with the APIs, try enabling signing ([EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)) or disabling signing ([ DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)). It's important that you correct **Internal failure** problems promptly. You can't make any other changes to the hosted zone until you correct the problem, except the operations to fix the **Internal failure**.