如果您在代管區域中啟用 DNSSEC，系統會提供數種可用的進階網域名稱系統安全性擴充功能 (DNSSEC) 設定選項，包含各種簽署演算法和拒絕存在機制，以及支援要求或建議使用 DNSSEC 的記錄類型。
如需 DNSSEC 的概念總覽，請參閱「DNSSEC 總覽」。
委派 DNSSEC 簽署的子網域
啟用主網域的 DNSSEC 後，就能為委派的子網域啟用 DNSSEC。方法是先在 Cloud DNS 區域中建立 DS 記錄，並另外建立一或多個 NS 記錄。
如要為委派的子網域建立 DS 記錄，您必須取得區域的 DS 記錄。如果委派的區域也託管於 Cloud DNS 中，您可以在 Google Cloud 控制台或 Google Cloud CLI 中取得 DS 記錄。
控制台
前往 Google Cloud 控制台的「Cloud DNS」頁面。
前往要查看 DS 記錄的代管區域。
點選「Zone details」(區域詳細資料) 頁面右上角的「Registrar Setup」(註冊商設定)，查看區域的 DS 記錄。
「Registrar Setup」(註冊商設定) 頁面會顯示 DS 記錄。
按照「新增記錄」文中的指示，建立 NS 記錄。
gcloud
執行下列指令，取得委派子網域的 DS 記錄資訊：
gcloud dns dns-keys list --zone SUBDOMAIN_ZONE
將
SUBDOMAIN_ZONE替換為專案中委派子網域的 DNS 區域名稱。輸出內容如下所示：
ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
如要取得完整的 DS 記錄和金鑰的所有詳細資料，您需要 KEY_SIGNING 金鑰 (KSK) 的 ID (通常為零 (0))。執行下列指令：
gcloud dns dns-keys describe --zone SUBDOMAIN_ZONE KSK_ID \ --format "value(ds_record())"
更改下列內容：
SUBDOMAIN_ZONE：專案中委派子網域的 DNS 區域名稱KSK_ID：KSK ID 編號，通常為 0
輸出內容如下所示：
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
複製上一個指令的輸出內容，後續步驟中會用到。
如要為安全的子委派作業建立 DS 記錄，請執行下列指令來開始交易：
gcloud dns record-sets transaction start --zone PARENT_ZONE
將
PARENT_ZONE替換為專案中用來為委派子網域建立記錄的上層 DNS 區域名稱。輸出內容如下所示：
Transaction started [transaction.yaml].
接著，執行下列指令來新增記錄集：
gcloud dns record-sets transaction add --zone PARENT_ZONE \ --ttl TIME_TO_LIVE \ --type DS \ --name subdomain.example.com \ "DS_RECORD_AND_KEY"
更改下列內容：
PARENT_ZONE：專案中上層 DNS 區域的名稱TIME_TO_LIVE：區域的存留時間 (TTL)，以秒為單位，例如 3600subdomain.example.com：區域 DNS 名稱的子網域DS_RECORD_AND_KEY：步驟 2 中取得的 DS 記錄和金鑰，例如44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
輸出內容如下所示：
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb Record addition appended to transaction at [transaction.yaml].
如要新增 NS 記錄，請使用下列指令：
gcloud dns record-sets transaction add --zone PARENT_ZONE \ --ttl TIME_TO_LIVE \ --type NS \ --name subdomain.example.com \
更改下列內容：
PARENT_ZONE：專案中上層 DNS 區域的名稱TIME_TO_LIVE：區域的存留時間 (TTL)，以秒為單位，例如 3600subdomain.example.com：區域 DNS 名稱的子網域
輸入下列 RRData：
ns-cloud-e1.googledomains.com. \ ns-cloud-e2.googledomains.com. \ ns-cloud-e3.googledomains.com. \ ns-cloud-e4.googledomains.com.
輸出內容如下所示：
Record addition appended to transaction at [transaction.yaml].
如要執行交易，請使用下列指令：
gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
將
EXAMPLE_ZONE替換成專案中的 DNS 區域名稱。輸出內容如下所示：
Executed transaction [transaction.yaml] for managed-zone [dns-example]. Created [https://dns.googleapis.com/dns/v1/projects/example/managedZones/example_zone/changes/42]. ID START_TIME STATUS 42 2019-08-08T23:12:49.100Z PENDING
使用進階簽署選項
為代管區域啟用 DNSSEC，或是使用 DNSSEC 建立代管區域時，您可以選取 DNSSEC 簽署演算法及拒絕存在類型。
您可以在啟用 DNSSEC「之前」，變更代管區域的 DNSSEC 設定 (例如用於以密碼編譯方式簽署記錄的演算法)。假設代管區域已啟用 DNSSEC，為了變更設定，請先停用 DNSSEC，進行必要變更，然後使用下列指令重新啟用 DNSSEC：
gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on
將 EXAMPLE_ZONE 替換成專案中的 DNS 區域名稱。
詳情請參閱「為現有代管區域啟用 DNSSEC」。
下列指令會啟用使用 256 位元 ECDSA 和 NSEC 的 DNSSEC，透過 Cloud DNS 取得最小的 DNSSEC 簽署回應封包：
gcloud dns managed-zones update EXAMPLE_ZONE \ --dnssec-state on \ --ksk-algorithm ECDSAP256SHA256 --ksk-key-length 256 \ --zsk-algorithm ECDSAP256SHA256 --zsk-key-length 256 \ --denial-of-existence NSEC
將 EXAMPLE_ZONE 替換成專案中的 DNS 區域名稱。
如果提供了任何 KSK 或 ZSK 演算法或金鑰長度，就必須在指令中提供「所有」項目及相關引數：
--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length
您可以將拒絕存在機制指定為與演算法無關的 NSEC 或 NSEC3。
下表列出支援的演算法選項和引數。Cloud DNS 不允許使用其他任何演算法或參數。
| 演算法 | KSK 長度 | ZSK 長度 | 註解 |
|---|---|---|---|
| RSASHA256 | 2048 | 1024、2048 | |
| RSASHA512 | 2048 | 1024、2048 | 並非廣受支援 |
| ECDSAP256SHA256 | 256 | 256 | |
| ECDSAP384SHA384 | 384 | 384 | 並非廣受支援 |
如未指定演算法，Cloud DNS 會使用下列預設值：
| 金鑰類型 | 預設演算法 | 預設金鑰長度 |
|---|---|---|
| 金鑰簽署金鑰 (KSK) | RSASHA256 | 2048 |
| 區域簽署金鑰 (ZSK) | RSASHA256 | 1024 |
RSASHA256 和 RSASHA512 之間的安全性與效能差異極小，而已簽署回應的大小相同。金鑰長度很重要；金鑰越長，速度越慢且回應較大 (請參閱根區域和 TLD 的回應大小分析，以及 Windows 的伺服器端效能分析)。
只有在相對較新的系統中，解析器才支援 ECDSA。無法驗證 ECDSA 所簽署區域的舊版解析器，會將這類區域視為未簽署，如果您使用依賴 DNSSEC 的新記錄類型，可能會有安全疑慮。註冊商和註冊資料庫通常支援 256 位元 ECDSA，但仍有例外。支援 384 位元 ECDSA 的註冊資料庫很少，註冊商更是少之又少。如果不需要支援舊型用戶端，使用 ECDSA「可以」獲得良好的效果；因為使用的簽章小很多，運算速度也比較快。
避免對代管區域中的 KSK 和 ZSK 使用不同的演算法，這麼做會降低相容性且可能會危害安全。如未使用 DNSKEY 演算法來簽署區域中的所有記錄，部分 DNSSEC 驗證解析器可能會判定該區域驗證失敗。即使 RFC 6840 明確指出「解析器『不得』要求 DNSKEY RRset 中的所有演算法都必須有效運作」，仍會發生此情況。如果您不擔心上述問題發生 (即大多數驗證解析器都遵循 RFC 6840)，當您的網域註冊商或 TLD 註冊資料庫不支援 ECDSA，您又需要縮小回應大小時，就可以將 KSK 設為 RSASHA256，並將 ZSK 設為 ECDSA。
NSEC3 是預設的拒絕存在類型，會對嘗試探查區域中所有記錄的區域巡查者提供有限保護。NSEC3PARAM 設定固定不變：基於安全考量，NSEC3 opt-out 已停用，雜湊迭代額外增加 1 次 (共 2 次)，並採用 64 位元的鹽。
NSEC 的回應略小，但沒有任何區域巡查保護措施。使用 NSEC 也能減少查詢不存在的網域。Google 公用 DNS 和其他幾個 DNSSEC 驗證解析器，可從快取的 NSEC 記錄合成否定回應，無需查詢 Cloud DNS 區域。
RFC 8624 包含有關演算法選取的其他指引。
將受 DNSSEC 保護的區域搭配使用新的 DNS 記錄類型
網域全面啟用 DNSSEC 保護後，您可以開始使用數種新的 DNS 記錄類型，這些記錄類型利用 DNSSEC 簽署區域提供的真實性和完整性保證，來強化其他服務的安全性。
SSHFP
SSHFP 記錄含有 SSH 伺服器公開金鑰的指紋，SSH 用戶端應用程式可用來驗證 SSH 伺服器。SSH 用戶端第一次連線時，通常需要透過使用者互動確認伺服器的公開金鑰，如果金鑰已變更，便會產生警告訊息。設為使用 SSHFP 的 SSH 用戶端，一律會使用該伺服器 SSHFP 記錄中的金鑰；系統只會儲存不含 SSHFP 記錄的伺服器金鑰，以供重複使用。
SSHFP 記錄格式如下：
- 演算法編號
- 指紋類型編號
- 伺服器金鑰指紋
SSH 的演算法編號如下：
- RSA
- DSA
- ECDSA
- ED25519
指紋類型如下：
- SHA-1 (已淘汰，只在有相容性問題時使用)
- SHA-256
請參考 StackExchange 針對建立 SSHFP 提供的建議。此外，如要產生 SSHFP 記錄，您也可以使用現有的已知主機檔案或設定管理，透過相關工具來掃描伺服器。如需更多範例和連結，請參閱「SSHFP 記錄：DNS 提供公開 SSH 主機金鑰」。
TLSA 與 DANE
TLSA 記錄包含可用於驗證 X.509 憑證 (例如 HTTPS 使用的憑證) 的資訊，無需依賴預先設定的一組憑證授權單位 (CA) 進行簽署。
因此，您可設定自己的 CA 並產生 HTTPS 的憑證。此外，還能驗證通訊協定 (例如 SMTP) 的憑證，因為通常沒有任何應用程式支援預先設定的可信任 CA。
在 RFC 6698 及相關 RFC 中指定的「具名實體的網域驗證 (DANE)」，會透過特定方式使用 TLSA 記錄，保護許多通訊協定和應用程式。IETF Journal and Internet Society 提供實用的介紹文章及 DANE 總覽。
HTTPS
DANE 可讓您根據 OpenSSL 或 Cloudflare 的 CFSSL，使用以自己的 CA 基礎架構產生的憑證，以安全的方式設定 HTTPS 伺服器。
SIDNLab 提供 HTTPS 伺服器適用的 DANE 驗證工具，很適合用來測試 HTTPS 的 DANE 部署。
SMTP (電子郵件) TLS 憑證驗證
SMTP 電子郵件通訊協定容易遭受導致加密功能停用的降級攻擊，而 DANE 有辦法防止這些攻擊。
Internet Society 提供的教學課程分成兩個部分，說明如何搭配 Let's Encrypt 提供的免費自動化憑證，在 SMTP 中使用 DANE，並建議避免搭配使用 Let's Encrypt 憑證與特定 TLSA 記錄格式：
請參閱「常見錯誤」，查看實用建議，並瞭解適用於 HTTPS 和 SMTP 的 DANE 網域驗證工具。「Test your email」(測試您的電子郵件) 驗證工具也會檢查 DANE。
XMPP (Jabber Chat) TLS 憑證驗證
XMPP (及使用 SRV 記錄的其他服務) 也可以使用 DANE。這個 XMPP 範例使用 RFC 7673 中指定的 DANE-SRV 設定。
TXT (OpenPGP / GnuPG) 公開金鑰關聯
雖然在沒有 DNSSEC 的情況下也能使用 TXT，但經 DNSSEC 簽署的 TXT 記錄對於資訊的真實性更有保障。這對於透過 DNS 發布 OpenPGP (GnuPG) 公開金鑰非常重要，因為這些金鑰不像 X.509 憑證由知名的授權單位簽署。
舉例來說，如果「Alice」在 DNSSEC 簽署的 an.example 區域中發布下列 TXT 記錄，並在指定的 URI 上託管 ASCII 封裝格式的公開金鑰副本，「Bob」就可以透過合理的安全方式查看 alice@an.example 的 OpenPGP 金鑰 (這並非用來代替信任網絡驗證機制，而是可以讓原本不認識的雙方使用 OpenPGP 加密功能)：
alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"
您可以按照這些操作說明產生「版本 1 PKA」TXT 記錄 (在「在 DNS 中發布金鑰」文中使用這個名稱)。
在 DNS 中發布 PGP 金鑰的完整指南說明了如何建立 OpenPGP CERT 記錄 (但 Cloud DNS 不支援 CERT 或 OPENPGPKEY 記錄)。
如果您已在 Keybase.io 註冊 OpenPGP 金鑰，就不需要在自己的伺服器上託管金鑰，只需改用網址，例如 https://keybase.io/KEYBASE_USERNAME/key.asc (將 KEYBASE_USERNAME 替換為您的 Keybase.io 使用者名稱)。
如果您已將 OpenPGP 金鑰上傳至金鑰伺服器，也可以使用該金鑰伺服器的 hkp: URI，例如 hkp://subkeys.pgp.net 或 hkp://pgp.mit.edu。不過，如果防火牆封鎖通訊埠 11371，防火牆後方的使用者可能會無法存取該 URI (部分金鑰伺服器提供通訊埠 80 HTTP 網址)。
TXT (SPF、DKIM 及 DMARC)
以下是另外三種 TXT 記錄，可用來保護電子郵件服務，避免垃圾內容發布者和詐騙者假冒從您的網域送出電子郵件 (實際並未發生)：
SPF：指定可以傳送某網域電子郵件的 SMTP 伺服器 (透過網域名稱或 IP 位址)。
DKIM：發布一組公開金鑰，用於驗證從某網域送出的電子郵件，並避免郵件在傳輸過程中遭到修改。
DMARC：指定 SPF 和 DKIM 驗證與錯誤報告的網域政策與報告設定。
如要驗證網域是否正確設定為使用這三種記錄類型，請使用「Test your email」(測試您的電子郵件) 驗證工具。如需設定 SPF 記錄的實用建議，請參閱常見錯誤 FAQ。
透過 DNSSEC 強化的其他記錄集類型
除了 TXT 外，還有幾種記錄集類型雖然不要求使用 DNSSEC，但啟用 DNSSEC 還是能帶來好處。
CAA
憑證授權單位授權 (CAA) 記錄集可讓您控管哪些公開 CA 可以為您的網域產生 TLS 或其他憑證。這套控管機制最適合用於有效確保核發網域驗證 (DV) 憑證的公開 CA (如 LetsEncrypt.org)，「不會」為您的網域核發憑證。
一般 CAA 記錄的簡單格式為 0 issue "best-ca.example"，可指定讓 best-ca.example CA (其他 CA 皆不行) 針對 CAA 記錄集所在網域中的名稱核發憑證。如要讓多個 CA 核發憑證，請建立多個 CAA 記錄。
RFC 6844 進一步詳細說明 CAA 記錄集類型的用法，並強烈建議使用 DNSSEC。
IPSECKEY
您也可以發布 IPSECKEY 記錄，透過 IPSEC 通道啟用隨機加密功能。strongSwan IPSEC VPN 實作含有使用 IPSECKEY 記錄的外掛程式。
除了將 IPSECKEY 記錄存放在一般的正解區域 (如 service.example.com) 外，RFC 4025 1.2 節還要求安全閘道也須在反解區域 ip6.arpa 和 in-addr.arpa 中查詢 IPSECKEY 記錄。
比起正解區域，反解區域支援 DNSSEC 的情形較少見，需依靠實作 DNSSEC 的網際網路服務供應商 (ISP) 協助。不過，仍有部分 ISP 可支援為反解區域的委派作業啟用 DNSSEC。
Compute Engine VM 外部 IP 位址的反解區域尚不支援委派功能。