本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 在 Amazon Route 53 中設定 DNSSEC 簽署 網域名稱系統安全延伸 (DNSSEC) 簽署可讓 DNS 解析程式驗證 DNS 回答是否來自 Amazon Route 53，並且未遭到竄改。當您使用 DNSSEC 簽署時，託管區域的每個回應都會使用公有金鑰密碼編譯來簽署。如需 DNSSEC 的概觀，請參閱 [AWS re：Invent 2021 - Amazon Route 53： A year in review](https://www.youtube.com/watch?v=77V23phAaAE) 的 DNSSEC 一節。 在本章中，我們將說明如何啟用 Route 53 的 DNSSEC 簽署、如何使用 key-signing keys (金鑰簽署金鑰) (KSK)，以及如何排除問題。您可以在 中使用 DNSSEC 簽署， AWS 管理主控台 或以程式設計方式使用 API。如需有關藉助 CLI 或開發套件來使用 Route 53 的詳細資訊，請參閱 [設定 Amazon Route 53](setting-up-route-53.md)。 啟用 DNSSEC 簽署之前，請注意下列事項： + 若要協助防止區域中斷，並避免網域無法使用的問題，您必須快速處理並解決 DNSSEC 錯誤。強烈建議您設定 CloudWatch 提醒，在偵測到 `DNSSECInternalFailure` 或 `DNSSECKeySigningKeysNeedingAction` 錯誤時發出警示。如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控託管區域](monitoring-hosted-zones-with-cloudwatch.md)。 + DNSSEC 中有兩種金鑰：金鑰簽署金鑰 (KSK) 和區域簽署金鑰 (ZSK)。在 Route 53 DNSSEC 簽署中，每個 KSK 均基於您所擁有的 AWS KMS 中的[非對稱客戶受管金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept)。您必須負責 KSK 管理，其中包括在需要時輪換它。ZSK 管理由 Route 53 進行。 + 當您啟用託管區域的 DNSSEC 簽署時，Route 53 會將 TTL 限制為一週。如果您為託管區域中的記錄設定超過一週的 TTL，則不會收到錯誤。不過，Route 53 會為該記錄強制執行一週的 TTL。對於 TTL 不到一週的記錄，以及在未啟用 DNSSEC 簽章的其他託管區域中的記錄，則不會受到影響。 + 當您使用 DNSSEC 簽章時，不支援多廠商組態。如果您已設定白標籤名稱伺服器 (也稱為虛名伺服器或私有名稱伺服器)，請確定這些名稱伺服器是由單一 DNS 提供者提供。 + 某些 DNS 提供者在其授權 DNS 中不支援委派簽署人 (DS) 記錄。如果您的父區域是由不支援 DS 查詢 (未在 DS 查詢回應中設定 AA 旗標) 的 DNS 提供者託管，則當您在其子區域中啟用 DNSSEC 時，子區域將會變成無法解析。請確定您的 DNS 供應商支援 DS 記錄。 + 設定 IAM 許可，以允許區域擁有者以外的其他使用者新增或移除區域中的記錄，這樣會很有幫助。例如，區域擁有者可以新增 KSK 並啟用簽署，也可能負責金鑰輪換。不過，其他人可能負責處理該託管區域的其他記錄。如需 IAM 政策範例，請參閱 [網域記錄擁有者的許可範例](access-control-managing-permissions.md#example-permissions-record-owner)。 + 若要檢查 TLD 是否支援 DNSSEC，請參閱 [可向 Amazon Route 53 註冊的網域](registrar-tld-list.md)。 **Topics** + [啟用 DNSSEC 簽署並建立信任鏈](dns-configuring-dnssec-enable-signing.md) + [停用 DNSSEC 簽署](dns-configuring-dnssec-disable.md) + [使用 DNSSEC 的客戶受管金鑰](dns-configuring-dnssec-cmk-requirements.md) + [使用金鑰簽署金鑰 (KSK)](dns-configuring-dnssec-ksk.md) + [Route 53 中的 KMS 金鑰和 ZSK 管理](dns-configuring-dnssec-zsk-management.md) + [DNSSEC 不存在於 Route 53 中的證明](dns-configuring-dnssec-proof-of-nonexistence.md) + [DNSSEC 簽署故障診斷](dns-configuring-dnssec-troubleshoot.md) # 啟用 DNSSEC 簽署並建立信任鏈 **** 遞增步驟適用於託管區域擁有者和父區域維護者。這可以是同一個人，但如果不是，區域擁有者應通知父區域維護者並與其合作。 我們建議您按照本文中的步驟簽署您的區域並將其納入信任鏈中。以下步驟會將加入 DNSSEC 的風險降至最低。 **注意** 在開始之前，請務必先閱讀 [在 Amazon Route 53 中設定 DNSSEC 簽署](dns-configuring-dnssec.md) 中的先決條件。 啟用 DNSSEC 簽署需要執行三個步驟，如以下章節所述。 **Topics** + [步驟 1：準備啟用 DNSSEC 簽署](#dns-configuring-dnssec-enable-signing-step-1) + [步驟 2：啟用 DNSSEC 簽署並建立 KSK](#dns-configuring-dnssec-enable) + [步驟 3：建立信任鏈](#dns-configuring-dnssec-chain-of-trust) ## 步驟 1：準備啟用 DNSSEC 簽署 準備步驟透過監控區域可用性並縮短啟用簽署與插入委派簽署人 (DS) 記錄之間的等待時間，協助您將加入 DNSSEC 的風險降至最低。 **準備啟用 DNSSEC 簽署** 1. 監控區域可用性。 您可以監控該區域在您網域名稱中的可用性。此可協助您處理在啟用 DNSSEC 簽署後可能需要倒回步驟的任何問題。您可以藉由使用查詢日誌記錄，監控具有大部分流量的網域名稱。如需設定查詢日誌記錄的詳細資訊，請參閱 [監控 Amazon Route 53](monitoring-overview.md)。 可以透過 Shell 指令碼或透過第三方服務進行監控。但是，其不應是判斷是否需要回復的唯一信號。您也可能會因為網域名稱不可用，而得到來自客戶的反饋。 1. 降低區域的最大 TTL。 區域的最大 TTL 是區域中最長的 TTL 記錄。在以下區域示例中，區域的最大 TTL 為 1 天 (86400 秒)。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) 降低區域的最大 TTL 將有助於縮短啟用簽署與插入委派簽署人 (DS) 記錄之間的等待時間。建議將區域的最大 TTL 降至 1 小時 (3600 秒)。如果解析器在快取簽署記錄時發生任何問題，這讓您在一個小時後即可回復。 **回復：**復原 TTL 變更。 1. 降低 SOA TTL 和 SOA 最小值欄位。 SOA 最小值欄位是 SOA 記錄資料中的最後一個欄位。在以下 SOA 記錄示例中，最小值欄位的值為 5 分鐘（300 秒）。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) SOA TTL 和 SOA 最小值欄位決定解析器記住否定答案的時間長度。啟用簽署後，Route 53 名稱伺服器開始傳回用於否定答案的 NSEC 記錄。NSEC 包含解析器可能用於合成否定答案的資訊。如果因為 NSEC 資訊導致解析器對一個名稱給予否定的答案而必須回復，則只需等待 SOA TTL 和 SOA 最小值欄位中的最大值的時間後，解析器即會停止假設。 **回復：**復原 SOA 變更。 1. 確認 TTL 和 SOA 最小值欄位變更生效。 使用 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) 以確保到目前為止所做的變更已傳播到所有 Route 53 DNS 伺服器。 ## 步驟 2：啟用 DNSSEC 簽署並建立 KSK 您可以在 Route 53 主控台上使用 AWS CLI 或 啟用 DNSSEC 簽署並建立金鑰簽署金鑰 (KSK)。 + [CLI](#dnssec_CLI) + [主控台](#dnssec_console) 當您提供或建立 KMS 金鑰時，有幾個需求。如需詳細資訊，請參閱[使用 DNSSEC 的客戶受管金鑰](dns-configuring-dnssec-cmk-requirements.md)。 ------ #### [ CLI ] 您可以使用您已有的金鑰，或透過使用您自己的 `hostedzone_id`、`cmk_arn`、`ksk_name`，和`unique_string` 的值 (以使請求為唯一) 執行類似如下的 AWS CLI 命令以建立金鑰 ： ``` 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 ``` 如需客戶受管金鑰的詳細資訊，請參閱 [使用 DNSSEC 的客戶受管金鑰](dns-configuring-dnssec-cmk-requirements.md)。另請參閱 [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)。 若要啟用 DNSSEC 簽署，請使用您自己的 值執行如下所示的 AWS CLI 命令`hostedzone_id`： ``` aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` 如需詳細資訊，請參閱 [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html) 和 [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)。 ------ #### [ Console ] **啟用 DNSSEC 簽署並建立 KSK** 1. 登入 AWS 管理主控台 並開啟 Route 53 主控台，網址為 https：//[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在導覽窗格中，選擇**託管區域**，然後選擇您要啟用 DNSSEC 簽署的託管區域。 1. 在 **DNSSEC signing (DNSSEC 簽署)** 標籤上，選擇 **Enable DNSSEC signing (啟用 DNSSEC 簽署)**。 **注意** 如果本部分中的選項是 **Disable DNSSEC signing (停用 DNSSEC 簽署)**，則表明您已完成啟用 DNSSEC 簽署的第一步。請確定您建立或已經存在 DNSSEC 託管區域的信任鏈，然後即可完成此任務。如需詳細資訊，請參閱[步驟 3：建立信任鏈](#dns-configuring-dnssec-chain-of-trust)。 1. 在 **Key-signing key (KSK) creation** (建立金鑰簽署金鑰 (KSK)) 部分中，選擇 **Create new KSK** (建立新的 KSK), 並在 **Provide KSK name** (提供 KSK 名稱) 中，輸入 Route 53 將為您建立的 KSK 的名稱。名稱僅能包含字母、數字和底線 (\$1)。它必須獨一無二。 1. 在 **Customer managed CMK (客戶受管的 CMK)** 下，請為 Route 53 選擇客戶受管的金鑰，以便在為您建立 KSK 時使用。您可以使用適用於 DNSSEC 簽署的現有客戶受管金鑰，也可以建立新的客戶受管金鑰。 當您提供或建立客戶受管的金鑰時，有幾點要求需要滿足。如需詳細資訊，請參閱[使用 DNSSEC 的客戶受管金鑰](dns-configuring-dnssec-cmk-requirements.md)。 1. 輸入現有客戶受管金鑰的別名。如果您想要使用新的客戶受管金鑰，請輸入客戶受管金鑰的別名，Route 53 即會為您建立一個金鑰。 **注意** 如果您選擇讓 Route 53 建立客戶受管金鑰，請注意每個客戶受管金鑰都要分別支付費用。有關更多資訊，請參閱 [AWS 金鑰 Management Service 定價](https://aws.amazon.com/kms/pricing/)。 1. 選擇 **Enable DNSSEC signing (啟用 DNSSEC 簽署)**。 ------ **啟用區域簽署後，請完成以下步驟** (不論您是使用主控台或是 CLI)： 1. 確認區域簽署已生效。 如果您使用 AWS CLI，您可以使用來自`EnableHostedZoneDNSSEC()`呼叫輸出的操作 ID 來執行 [get-change ](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html)或 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)，以確保所有 Route 53 DNS 伺服器正在簽署回應 （狀態 = `INSYNC`)。 1. 等待至少前一個區域的最大 TTL 的時間。 等待解析器清除其快取中所有的未簽署記錄。為此，您應等待至少前一個區域的最大 TTL 的時間。在上述 `example.com` 區域中，等待時間會是 1 天。 1. 監控客戶問題報告。 啟用區域簽署後，客戶可能會開始看到與網路裝置和解析器有關的問題。建議的監控期為 2 週。 以下為您可能看到的問題示例： + 有些網路裝置可以將 DNS 回答大小限制為 512 位元組以下，這對於有些簽署回答來說太小。應重新設定這些網路裝置，以允許更大的 DNS 回答大小。 + 有些網路裝置會對 DNS 回答進行深入檢查，並去除有些其不理解的記錄，像是用於 DNSSEC 的記錄。應重新設定這些裝置。 + 有些客戶的解析器宣稱可以接受比其網路支援的更大的 UDP 回應。您可以測試網路能力並適當地設定解析器。如需詳細資訊，請參閱 [DNS 回覆大小測試伺服器](https://www.dns-oarc.net/oarc/services/replysizetest/)。 **回復：**呼叫 [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) 然後回復 [步驟 1：準備啟用 DNSSEC 簽署](#dns-configuring-dnssec-enable-signing-step-1) 中的步驟。 ## 步驟 3：建立信任鏈 在 Route 53 中啟用託管區域的 DNSSEC 簽署之後，建立託管區域的信任鏈，以完成 DNSSEC 簽署設定。您可以藉由在*父*託管區域中建立委派簽署人 (DS) 記錄來完成此任務 (使用 Route 53 提供的資訊)。視網域的註冊位置而定，您可以將記錄新增至 Route 53 或其他網域註冊商中的父託管區域。 **建立信任鏈以進行 DNSSEC 簽署** 1. 登入 AWS 管理主控台 並開啟 Route 53 主控台，網址為 https：//[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在導覽窗格中，選擇 **Hosted zones (託管區域)**，然後選擇您想要建立 DNSSEC 信任鏈的託管區域。*您必須先啟用 DNSSEC 簽署。* 1. 在 **DNSSEC signing (DNSSEC 簽署)** 標籤中的 **DNSSEC signing (DNSSEC 簽署)** 下，選擇 **View information to create DS record (檢視資訊以建立 DS 記錄)**。 **注意** 如果您看不到 **View information to create DS record (檢視資訊以建立 DS 記錄)**，則必須先啟用 DNSSEC 簽署，才能建立信任鏈。選擇 **Enable DNSSEC signing** (啟用 DNSSEC 簽署) 並完成 [步驟 2：啟用 DNSSEC 簽署並建立 KSK](#dns-configuring-dnssec-enable) 中所述的步驟，然後回到這些步驟以建立信任鏈。 1. 在 **Establish a chain of trust (建立信任鏈)** 下，選擇 ** Route 53 registrar (Route 53 註冊商)** 或 **Another domain registrar (其他網域註冊商)**，視您的網域註冊位置而定。 1. 使用步驟 3提供的值，以為 Route 53 中的父託管區域建立 DS 記錄。如果您的網域名稱不在 Route 53 託管，請使用提供的值在網域註冊商網站上建立 DS 記錄。 為父區域建立信任鏈： + 如果您的網域是透過 Route 53 管理，請遵循下列步驟： 請確定您設定正確的簽署演算法 (ECDSAP256SHA256 和類型 13) 和摘要演算法 (SHA-256 和類型 2)。 如果 Route 53 是您的註冊商，請在 Route 53 主控台中執行以下操作： 1. 請注意 **Key type (金鑰類型)**、**Signing algorithm (簽署演算法)** 以及 **Public key (公有金鑰)** 值。在導覽窗格中，選擇 **Registered domains (已註冊的網域)**。 1. 選取網域，然後在 **DNSSEC 金鑰**索引標籤中，選擇**新增金鑰**。 1. 在 **Manage DNSSEC keys** (管理 DNSSEC 金鑰) 對話方塊中，從下拉式選單中為 **Route 53 registrar** (Route 53 註冊商) 選擇適當的 **Key type** (金鑰類型) 和 **Algorithm** (演算法)。 1. 複製 Route 53 註冊商的 **Public key (公有金鑰)**。在 **Manage DNSSEC keys** (管理 DNSSEC 金鑰)對話方塊中，將值貼到 **Public key** (公有金鑰) 方塊中。 1. 選擇**新增**。 Route 53 會將 DS 記錄從公有金鑰新增至父區域。例如，如果您的網域為 `example.com`，則 DS 記錄會新增至 .com DNS 區域。 + 如果您的網域是在另一個登錄檔上管理，請遵循**另一個網域登錄檔**一節中的指示。 為確保以下步驟順利進行，請對父區域導入一個低 DS TTL。建議將 DS TTL 設為 5 分鐘 (300 秒)，以便在需要回復變更時更快速恢復。 + 為子區域建立信任鏈： 如果您的父區域由其他註冊機構管理，請聯絡您的註冊商以導入您區域的 DS 記錄。一般來說，您將無法調整 DS 記錄的 TTL。 + 如果您的父區域託管在 Route 53 上，請聯絡父區域擁有者，以導入您區域的 DS 記錄。 提供 `$ds_record_value` 給父區域擁有者。您可以透過點擊主控台中的 **View Information to create DS record** (查看資訊以建立 DS 記錄) 並複製 **DS record** (DS 記錄) 欄位，或透過呼叫 [GetDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) API 並檢索 ‘DSRecord’ 欄位的值，取得此資訊： ``` aws --region us-east-1 route53 get-dnssec --hosted-zone-id $hostedzone_id ``` 父區域擁有者可以透過 Route 53 主控台或 CLI 插入記錄。 + 若要使用 插入 DS 記錄 AWS CLI，父區域擁有者會建立並命名類似下列範例的 JSON 檔案。父區域擁有者可能會將檔案命名為類似 `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" } ] } } ] } } ``` 然後執行以下命令： ``` aws --region us-east-1 route53 change-resource-record-sets --cli-input-json file://inserting_ds.json ``` + 若要使用主控台插入 DS 記錄， 請在 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 開啟 Route 53 主控台。 在導覽窗格中，選擇 **Hosted zones** (託管區域)，即託管區域的名稱，然後選擇 **Create record** (建立記錄) 按鈕。請確認 **Routing policy** (路由政策) 選擇簡單路由。 在**記錄名稱**欄位中輸入與 相同的名稱`$zone_name`，從**記錄類型**下拉式清單中選取 DS，然後在`$ds_record_value`**值**欄位中輸入 的值，然後選擇**建立記錄**。 **回復：**從父區域中刪除 DS，等待 DS TTL 的時間，然後回到建立信任的步驟。如果父區域託管在 Route 53 上，則父區域擁有者可以在 JSON 檔案將 `Action` 從 `UPSERT` 變更為 `DELETE`，然後重新執上面的 CLI 示例。 1. 根據網域記錄的 TTL，等候更新傳播。 如果父區域位於 Route 53 DNS 服務上，則父區域擁有者可以透過 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API 確認完全傳播。 否則，您可以定期探測 DS 記錄的父區域，之後再等待 10 分鐘，以提高 DS 記錄插入已完全傳播的概率。請注意，有些註冊商已有 DS 插入排程，例如，每天一次。 當您在父區域中導入委派簽署人 (DS) 記錄時，已取得 DS 的驗證解析器將開始驗證來自區域的回應。 為確保建立信任的步驟順利進行，請完成以下操作： 1. 查找最大 NS TTL。 有兩組與您的區域相關聯的 NS 記錄： + 委派 NS 記錄 — 這是父區域所持有的您區域的 NS 記錄。您可以藉由執行以下 Unix 命令來查找此記錄 (如果您的區域是 example.com，則父區域是 com)： `dig -t NS com` 選擇其中一個 NS 記錄，然後執行以下操作： `dig @one of the NS records of your parent zone -t NS example.com` 例如： `dig @b.gtld-servers.net. -t NS example.com` + 區域內 NS 記錄 — 這是在您區域中的 NS 記錄。您可以藉由執行以下 Unix 命令來查找此記錄： `dig @one of the NS records of your zone -t NS example.com` 例如： `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` 記下兩個區域的最大 TTL。 1. 等待最大 NS TTL 的時間。 在 DS 插入之前，解析器會收到簽署回應，但不會驗證簽章。插入 DS 記錄時，在該區域的 NS 記錄過期前，解析器都看不到該記錄。當解析器重新獲取 NS 記錄時，亦將傳回 DS 記錄。 如果您的客戶在具有不同步時鐘的主機上執行解析器，請確保時鐘在正確時間的 1 小時以內。 完成此步驟後，所有具有 DNSSEC 意識的解析器都將驗證您的區域。 1. 請觀察名稱解析。 您應該觀察到，解析器在驗證您的區域方面沒有任何問題。確認您亦將客戶向您報告問題所需要的時間納入考慮。 我們建議監控長達 2 週。 1. （選用）延長 DS 和 NS TTL。 如果對設定滿意，則可以儲存您所做的 TTL 和 SOA 變更。請注意，Route 53 將已簽署區域的 TTL 限制為 1 週。如需詳細資訊，請參閱[在 Amazon Route 53 中設定 DNSSEC 簽署](dns-configuring-dnssec.md)。 如果您能變更 DS TTL，我們建議您將其設為 1 小時。 # 停用 DNSSEC 簽署 在 Route 53 中停用 DNSSEC 簽署的步驟會根據您託管區域所屬的信任鏈而有所不同。 例如，您的託管區域可能有一個具有委派簽署人 (DS) 記錄的父區域，其做為信任鏈的一部分。您的託管區域本身也可能是啟用 DNSSEC 簽署之子區域的父區域，這是信任鏈的另一個部分。請先調查並確定託管區域的完整信任鏈，然後再採取步驟停用 DNSSEC 簽署。 當您停用簽署時，必須小心復原啟用 DNSSEC 簽署之託管區域的信任鏈。若要從信任鏈中移除託管區域，您可以移除包含此託管區域之信任鏈的所有 DS 記錄。這表示您必須依序執行下列作業： 1. 針對屬於信任鏈一部分的子區域，移除此託管區域擁有的任何 DS 記錄。 1. 移除父區域的 DS 記錄。如果您擁有信任島 (父區域中沒有 DS 記錄，且此區域中沒有子區域的 DS 記錄)，則可以略過此步驟。 1. 如果您無法移除 DS 記錄，則為了從信任鏈中移除區域，請從父區域移除 NS 記錄。如需詳細資訊，請參閱[新增或變更網域的名稱伺服器和黏附記錄](domain-name-servers-glue-records.md)。 以下遞增步驟讓您能監控個別步驟的有效性，以免您的區域出現 DNS 可用性問題。 **停用 DNSSEC 簽署** 1. 監控區域可用性。 您可以監控該區域在您網域名稱中的可用性。此可協助您處理在啟用 DNSSEC 簽署後可能需要倒回步驟的任何問題。您可以藉由使用查詢日誌記錄，監控具有大部分流量的網域名稱。如需設定查詢日誌記錄的詳細資訊，請參閱 [監控 Amazon Route 53](monitoring-overview.md)。 可以透過 Shell 指令碼或透過付費服務進行監控。但是，其不應是判斷是否需要回復的唯一信號。您也可能會因為網域名稱不可用，而得到來自客戶的反饋。 1. 查找目前 DS TTL。 您可以藉由執行以下 Unix 命令來查找 DS TTL： `dig -t DS example.com example.com` 1. 查找最大 NS TTL。 有兩組與您的區域相關聯的 NS 記錄： + 委派 NS 記錄 — 這是父區域所持有的您區域的 NS 記錄。您可以藉由執行以下 Unix 命令來查找此記錄： 首先，找到父區域的 NS（如果您的區域是 example.com，則父區域是 com）： `dig -t NS com` 選擇其中一個 NS 記錄，然後執行以下操作： `dig @one of the NS records of your parent zone -t NS example.com` 例如： `dig @b.gtld-servers.net. -t NS example.com` + 區域內 NS 記錄 — 這是在您區域中的 NS 記錄。您可以藉由執行以下 Unix 命令來查找此記錄： `dig @one of the NS records of your zone -t NS example.com` 例如： `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` 記下兩個區域的最大 TTL。 1. 移除父區域的 DS 記錄。 請聯絡父區域擁有者以移除 DS 記錄。 **回復：**重新插入 DS 記錄，確認 DS 插入已生效，並等待最大 NS (而不是 DS) TTL 的時間，然後所有解析程式將會再次開始驗證。 1. 確認 DS 移除已生效。 如果父區域位於 Route 53 DNS 服務上，則父區域擁有者可以透過 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) API 確認完全傳播。 否則，您可以定期探測 DS 記錄的父區域，之後再等待 10 分鐘，以提高 DS 記錄移除已完全傳播的概率。請注意，有些註冊商已有 DS 移除排程，例如，每天一次。 1. 等待 DS TTL 的時間。 等到所有解析器都已使其快取中的 DS 記錄過期。 1. 停用 DNSSEC 簽署並停止金鑰簽署金鑰 (KSK)。 + [CLI](#CLI_dnssec_disable) + [主控台](#console_dnssec_disable) ------ #### [ CLI ] 呼叫 [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) 和 [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) API。 例如： ``` 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 ] **停用 DNSSEC 簽署** 1. 登入 AWS 管理主控台 ，並在 https：//[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 開啟 Route 53 主控台。 1. 在導覽窗格中，選擇 **Hosted zones (託管區域)**，然後選擇您要停用 DNSSEC 簽署的託管區域。 1. 在 **DNSSEC signing (DNSSEC 簽署)** 標籤上，選擇 **Disable DNSSEC signing (停用 DNSSEC 簽署)**。 1. 在 **Disable DNSSEC signing (停用 DNSSEC 簽署)** 頁面上，根據您要停用 DNSSEC 簽署之區域的案例，選擇下列選項之一。 + **僅限父區域** — 此區域具有包含 DS 記錄的父區域。在此案例中，您必須移除父區域的 DS 記錄。 + **僅限子區域** — 此區域具有一或多個子區域之信任鏈的 DS 記錄。在此案例中，您必須移除區域的 DS 記錄。 + **父區域和子區域** — 此區域同時具有一或多個子區域之信任鏈的 DS 記錄*和*包含 DS 記錄的父區域。對於此案例，請按順序執行下列動作： 1. 移除區域的 DS 記錄。 1. 移除父區域的 DS 記錄。 如果您有信任島，則可以略過此步驟。 1. 決定您在步驟 4 中移除的每個 DS 記錄的 TTL 是多少，並確定最長的 TTL 期間已過期。 1. 選取核取方塊，確認您已按順序執行這些步驟。 1. 在欄位中鍵入 *disable (停用)*，如圖所示，然後選擇 **Disable (停用)**。 **若要停止金鑰簽署金鑰 (KSK)** 1. 登入 AWS 管理主控台 並開啟 Route 53 主控台，網址為 https：//[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在導覽窗格中，選擇 **Hosted zones** (託管區域)，然後選擇您要停止的金鑰簽署金鑰 (KSK)。 1. 在 **Key-signing keys (KSKs)** (金鑰簽署金鑰 (KSK)) 部分中，選擇要停止的 KSK，然後在 **Actions** (動作) 之下，選擇 **Edit KSK** (編輯 KSK)，將 **KSK status** (KSK 狀態) 設為 **Inactive** (非作用中)，然後選擇 **Save KSK** (儲存 KSK)。 ------ **回復：**呼叫 [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) 和 [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) API。 例如： ``` 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. 確認停用區域簽署已生效。 使用來自 `EnableHostedZoneDNSSEC()` 呼叫的 Id 執行 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)，以確保所有 Route 53 DNS 伺服器已停止簽署回應（狀態 = `INSYNC`)。 1. 請觀察名稱解析。 您應該觀察到，沒有會導致解析器驗證您區域的問題。允許 1 到 2 週以將客戶向您報告問題所需要的時間一併納入考慮。 1. (選用) 清除。 如果您不會重新啟用簽名，則可以透過 [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html) 清除 KSK，並刪除相應的客戶受管金鑰，以節省成本。 # 使用 DNSSEC 的客戶受管金鑰 當您在 Amazon Route 53 中啟用 DNSSEC 簽署時，Route 53 會為您建立金鑰簽署金鑰 (KSK)。若要建立 KSK，Route 53 必須使用 AWS Key Management Service 支援 DNSSEC 的客戶受管金鑰。本節說明客戶受管金鑰的詳細資料和要求，這些金鑰在您使用 DNSSEC 時很有幫助。 當您使用 DNSSEC 的客戶受管金鑰時，請謹記以下幾點： + 與 DNSSEC 簽署一起使用的客戶受管金鑰必須位於美國東部 (維吉尼亞北部) 區域。 + 客戶受管金鑰必須是具有 [ECC\$1NIST\$1P256 金鑰規格](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc)的[非對稱客戶受管金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks)。這些客戶受管金鑰僅用於簽署和驗證。如需建立非對稱客戶受管金鑰的說明，請參閱《 AWS Key Management Service 開發人員指南》中的[建立非對稱客戶受管金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk)。如需尋找現有客戶受管金鑰的密碼編譯組態的說明，請參閱《 AWS Key Management Service 開發人員指南》中的[檢視客戶受管金鑰的密碼編譯組態](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html)。 + 如果您自行建立客戶受管金鑰，以便在 Route 53 中搭配 DNSSEC 使用，則必須包含讓 Route 53 具有必要許可的特定金鑰政策陳述式。Route 53 必須能夠存取您的客戶受管金鑰，以便為您建立 KSK。如需詳細資訊，請參閱[DNSSEC 簽署需要 Route 53 客戶受管金鑰許可](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC)。 + Route 53 可以在 中建立客戶受管金鑰 AWS KMS ，以搭配 DNSSEC 簽署使用，而無需其他 AWS KMS 許可。但是，如果您想要在建立金鑰後對其進行編輯，則必須具有特定的許可。您必須擁有的特定許可如下：`kms:UpdateKeyDescription`、`kms:UpdateAlias` 以及 `kms:PutKeyPolicy`。 + 請注意，無論是您自己建立客戶受管金鑰，還是 Route 53 為您建立金鑰，都會針對您擁有的每個客戶受管金鑰收取個別費用。如需詳細資訊，請參閱 [AWS Key Management Service 定價](https://aws.amazon.com/kms/pricing/)。 # 使用金鑰簽署金鑰 (KSK) 當您啟用 DNSSEC 簽署時，Route 53 會為您建立金鑰簽署金鑰 (KSK)。在 Route 53 中，每個託管區域中最多可擁有兩個 KSK。啟用 DNSSEC 簽署之後，您可以新增、移除或編輯您的 KSK。 當您使用 KSK 時，請注意下列事項： + 在刪除 KSK 之前，您必須先編輯 KSK，將其狀態設定為 **Inactive (非作用中)**。 + 為託管區域啟用 DNSSEC 簽署時，Route 53 會將 TTL 限制為一週。如果您將託管區域中記錄的 TTL 設定為一週以上，則不會收到錯誤，但 Route 53 會強制執行一週的 TTL。 + 若要協助防止區域中斷，並避免網域無法使用的問題，您必須快速處理並解決 DNSSEC 錯誤。強烈建議您設定 CloudWatch 提醒，在偵測到 `DNSSECInternalFailure` 或 `DNSSECKeySigningKeysNeedingAction` 錯誤時發出警示。如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控託管區域](monitoring-hosted-zones-with-cloudwatch.md)。 + 本節描述的 KSK 操作可讓您輪換區域的 KSK。如需詳細資訊和逐步範例，請參閱部落格文章[使用 Amazon Route 53 設定 DNSSEC 簽署和驗證](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/)中的 *DNSSEC 金鑰輪換*。 若要在 中使用 KSKs AWS 管理主控台，請遵循下列各節中的指引。 ## 新增金鑰簽署金鑰 (KSK) 當您啟用 DNSSEC 簽署時，Route 53 會為您建立金鑰簽署 (KSK)。您也可以單獨新增 KSK。在 Route 53 中，每個託管區域中最多可擁有兩個 KSK。 建立 KSK 時，您必須提供或請求 Route 53 建立客戶受管金鑰以搭配 KSK 使用。當您提供或建立客戶受管的金鑰時，有幾點要求需要滿足。如需詳細資訊，請參閱[使用 DNSSEC 的客戶受管金鑰](dns-configuring-dnssec-cmk-requirements.md)。 請遵循下列步驟，在 AWS 管理主控台中新增 KSK。 **新增 KSK** 1. 登入 AWS 管理主控台 並開啟 Route 53 主控台，網址為 https：//[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在導覽窗格中，選擇 **Hosted zones (託管區域)**，然後選擇託管區域。 1. 在 **DNSSEC** 標籤上的 **Key-signing keys (KSKs) (金鑰簽署金鑰 (KSK))** 中，選擇 **Switch to advanced view (切換至進階檢視)**，然後在 **Actions (動作)** 下選擇** Add KSK (新增 KSK)**。 1. 在 **KSK** 下，輸入 Route 53 將為您建立的 KSK 名稱。名稱僅能包含字母、數字和底線 (\$1)。它必須獨一無二。 1. 輸入適用於 DNSSEC 簽署之客戶受管金鑰的別名，或輸入 Route 53 將為您建立之新客戶受管金鑰的別名。 **注意** 如果您選擇讓 Route 53 建立客戶受管金鑰，請注意每個客戶受管金鑰都要分別支付費用。如需詳細資訊，請參閱 [AWS Key Management Service 定價](https://aws.amazon.com/kms/pricing/)。 1. 選擇 **Create KSK (建立 KSK)**。 ## 編輯金鑰簽署金鑰 (KSK) 您可以將 KSK 的狀態編輯為 **Active (作用中)** 或 **Inactive (非作用中)**。當 KSK 處於作用中狀態時，Route 53 會使用該 KSK 進行 DNSSEC 簽署。在刪除 KSK 之前，您必須先編輯 KSK，將其狀態設定為 **Inactive (非作用中)**。 請遵循下列步驟，在 AWS 管理主控台中編輯 KSK。 **編輯 KSK** 1. 登入 AWS 管理主控台 並開啟 Route 53 主控台，網址為 https：//[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在導覽窗格中，選擇 **Hosted zones (託管區域)**，然後選擇託管區域。 1. 在 **DNSSEC signing** (DNSSEC 簽署) 標籤上的 **Key-signing keys (KSKs)** (金鑰簽署金鑰 (KSK)) 中，選擇 **Switch to advanced view** (切換至進階檢視)，然後，在 **Actions** (動作) 下選擇 **Edit KSK** (編輯 KSK)。 1. 對 KSK 進行所需的更新，然後選擇 **Save (儲存)**。 ## 刪除金鑰簽署金鑰 (KSK) 在刪除 KSK 之前，您必須先編輯 KSK，將其狀態設定為 **Inactive (非作用中)**。 您可能會刪除 KSK 的一點原因是做為例行金鑰輪換的環節之一。定期輪換密碼編譯金鑰是一種最佳實務。您的組織可能會針對輪換金鑰的頻率提供標準指引。 請依照下列步驟，在 AWS 管理主控台中刪除 KSK。 **刪除 KSK** 1. 登入 AWS 管理主控台 並開啟 Route 53 主控台，網址為 https：//[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在導覽窗格中，選擇 **Hosted zones (託管區域)**，然後選擇託管區域。 1. 在 **DNSSEC** 標籤上的 **Key-signing keys (KSKs) (金鑰簽署金鑰 (KSK))** 中，選擇 **Switch to advanced view (切換至進階檢視)**，然後在 **Actions (動作)** 下選擇 **Delete KSK (刪除 KSK)**。 1. 按照指引確認刪除 KSK。 # Route 53 中的 KMS 金鑰和 ZSK 管理 本節說明目前 Route 53 用於已啟用 DNSSEC 簽署的區域的做法。 **注意** Route 53 使用以下可能會變更的規則。將來的任何變更都不會降低您區域或 Route 53 的安全狀態。 **Route 53 如何使用與您的 KSK AWS KMS 相關聯的** 在 DNSSEC 中，KSK 用於生成 DNSKEY 資源紀錄集的資源紀錄簽名 (RRSIG)。All `ACTIVE` KSK 均用於生成 RRSIG。Route 53 會透過呼叫相關聯 KMS 金鑰上的 `Sign` AWS KMS API 來產生 RRSIG。如需詳細資訊，請參閱《AWS KMS API 指南》**中的[簽署](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html)。這些 RRSIG 不會計入區域的資源紀錄集限制。 RRSIG 會過期。為防止 RRSIG 過期，會每一到七天再生成一次 RRSIG 以定期對其進行重新整理。 每次呼叫以下任一項 API 時，也會重新整理 RRSIG： + [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) 每次 Route 53 執行重新整理時，我們都會生成 15 個 RRSIG 來確保未來幾天的可用性，以防相關聯的 KMS 金鑰變得無法存取。在估計 KMS 金鑰成本時，您可以假定每天定期重新整理一次。KMS 金鑰政策的意外變更，可能會讓 KMS 金鑰變得無法存取。無法存取的 KMS 金鑰會將關聯的 KSK 狀態設定為 `ACTION_NEEDED`。我們強烈建議您藉由設定 CloudWatch 警示來監控此情況 (只要偵測到 `DNSSECKeySigningKeysNeedingAction` 錯誤時)，因為驗證解析程式將在最後一個 RRSIG 過期後開始無法查找。如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控託管區域](monitoring-hosted-zones-with-cloudwatch.md)。 **Route 53 如何管理您區域的 ZSK** 啟用 DNSSEC 簽署的每個新託管區域均有一個 `ACTIVE` 區域簽署金鑰 (ZSK)。ZSK 由每個託管區域單獨生成，並為 Route 53 所有。目前的金鑰演算法是 ECDSAP256SHA256。 我們將在簽署開始後的 7-30 天內，開始對區域執行定期 ZSK 輪換。目前，Route 53 使用發佈前金鑰滾動法。如需詳細資訊，請參閱[發佈前區域簽署金鑰滾動法](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1)。此方法會將另一個 ZSK 帶至該區域。輪換將每 7-30 天重複一次。 如果區域的任何 KSK 處於 `ACTION_NEEDED` 狀態，Route 53 將暫停 ZSK 輪換，因為 Route 53 無法重新生成 DNSKEY 資源紀錄集的 RRSIG，以考慮區域 ZSK 中的變更。情況解除後，ZSK 輪換將自動恢復。 # DNSSEC 不存在於 Route 53 中的證明 **注意** Route 53 使用以下可能會變更的規則。將來的任何變更都不會降低您區域或 Route 53 的安全狀態。 DNSSEC 有三種不存在證明： + 記錄與查詢名稱相符的不存在證明。 + 類型與查詢名稱相符的不存在證明。 + 用於生成回應記錄的通配符記錄的不存在證明。 Route 53 使用 BL 方法實現記錄與查詢名稱相符的不存在證明。如需詳細資訊，請參閱 [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00)。這種方法可生成精簡表示的證明，並避免區域遍歷。 萬一存在與查詢名稱相符，但與查詢類型不相符的記錄 (例如查詢 web.example.com/AAAA，但只有 web.example.com/A 存在)，我們會傳回包含所有支援資源紀錄類型的最小 NSEC (下一次安全) 記錄。 當 Route 53 從通配符記錄合成答案時，回應將不隨附下一次安全記錄，或通配符的 NSEC 記錄。此類 NSEC 記錄用於某些實作 (通常是執行離線簽署的實作)，以防止回應中的資源紀錄簽署 (RRSIG) 被重複用於欺騙不同的回應。Route 53 將線上簽署用於 non-DNSKEY 記錄來產生回應特定的 RRSIG，不能將這些 RRSIG 重複用於不同的回應。 # DNSSEC 簽署故障診斷 本節中的資訊可協助您解決 DNSSEC 簽署的問題，包括啟用、停用及金鑰簽署金鑰 (KSK)。 啟用 DNSSEC 在開始啟用 DNSSEC 簽署之前，請務必先閱讀 [在 Amazon Route 53 中設定 DNSSEC 簽署](dns-configuring-dnssec.md) 中的先決條件。 停用 DNSSEC 為了安全地停用 DNSSEC，Route 53 會檢查目標區域是否位於信任鏈中。其會檢查目標區域的父項是否具有目標區域的任何 NS 記錄以及目標區域的 DS 記錄。如果目標區域無法公開解析，例如，在查詢 NS 和 DS 時得到 SERVFAIL 回應，Route 53 就無法判斷停用 DNSSEC 是否安全。您可以聯絡您的父區域以修正這些問題，並於稍後再重試停用 DNSSEC。 KSK 狀態為 **Action needed (需採取動作)** 當 Route 53 DNSSEC 無法存取對應的 （由於許可 AWS KMS key 或刪除） 時，KSK 可以將其狀態變更為**所需的動作** AWS KMS key （或`ACTION_NEEDED`處於 [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) 狀態）。 如果 KSK 的狀態為 **Action needed** (需採取動作)，意味著最終其將導致使用 DNSSEC 驗證解析器的客戶端發生區域中斷，而您必須快速採取行動以防止生產區域變得無法解析。 若要修正這個問題，請確定您 KSK 作為依據的客戶受管金鑰已啟用且具有正確的許可。如需所需許可的詳細資訊，請參閱[DNSSEC 簽署需要 Route 53 客戶受管金鑰許可](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC)。 修正 KSK 之後，請使用 主控台或 再次啟用它 AWS CLI，如 中所述[步驟 2：啟用 DNSSEC 簽署並建立 KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable)。 若要避免未來發生此問題，請考慮新增 Amazon CloudWatch 指標，以追蹤 中建議的 KSK 狀態[在 Amazon Route 53 中設定 DNSSEC 簽署](dns-configuring-dnssec.md)。 KSK 狀態為 **Internal failure (內部故障)** 當 KSK 的狀態為 **Internal failure** (內部故障) (或在 [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html) 狀態中為 `INTERNAL_FAILURE`) 時，在問題解決之前，您無法使用任何其他 DNSSEC 實體。您必須採取行動，才能使用 DNSSEC 簽署，包括使用此 KSK 或您的其他 KSK。 若要修正此問題，請再試一次啟用或停用 KSK。 若要在使用 API 時修正此問題，請嘗試啟用簽署 ([EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)) 或停用簽署 ([ DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html))。 務必及時修正 **Internal failure (內部故障)** 問題。在修正此問題之前，除了修正 **Internal failure (內部故障)** 的操作之外，您無法對託管區域進行任何其他變更。