本页面提供了几种高级域名系统安全扩展 (DNSSEC) 配置选项，供您在为托管地区启用 DNSSEC 时使用。这些选项包括不同的签名算法和否认存在类型，以及使用各种需要或推荐结合 DNSSEC 一起使用的记录类型的能力。
如需 DNSSEC 的概念性概览，请参阅 DNSSEC 概览。
委派带有 DNSSEC 签名的子网域
为主域名启用 DNSSEC 后，可以为委派子网域启用 DNSSEC。要为委派子网域启用 DNSSEC，请先在 Cloud DNS 地区中创建 DS 记录。您还必须创建一个或多个 NS 记录。
要为委派子网域创建 DS 记录，您必须获取该区域的 DS 记录。如果委派可用区也托管在 Cloud DNS 中，您可以从 Google Cloud Console 或 Google Cloud CLI 获取 DS 记录。
控制台
在 Google Cloud Console 中，转到 Cloud DNS 页面。
转到您要查看 DS 记录的代管可用区。
如需查看可用区的 DS 记录，请在可用区详细信息页面的右上角，点击注册商设置。
DS 记录会显示在注册商设置页面上。
如需创建 NS 记录，请按照添加记录中的说明进行操作。
gcloud
如需获取委派子网域的 DS 记录信息，请运行以下命令：
gcloud dns dns-keys list --zone EXAMPLE_ZONE
将
EXAMPLE_ZONE替换为项目中委派的子网域 DNS 可用区的名称。输出如下所示：
ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
如需获取完整的 DS 记录和密钥的所有详细信息，您需要 KEY_SIGNING 密钥 (KSK) 的 ID，该 ID 通常为零 (0)。运行以下命令：
gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \ --format "value(ds_record())"
替换以下内容：
EXAMPLE_ZONE：您项目中委派子网域 DNS 可用区的名称KSK_ID：KSK ID 编号，通常为 0
输出类似于以下内容：
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
复制上一个命令的输出，以便在后续步骤中使用。
如需为安全标示创建 DS 记录，请运行以下命令启动事务：
gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
将
EXAMPLE_ZONE替换为您要为委派的子网域创建记录的项目中的父 DNS 可用区的名称。输出如下所示：
Transaction started [transaction.yaml].
接下来，运行以下命令以添加记录集：
gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \ --ttl TIME_TO_LIVE \ --type DS \ --name subdomain.example.com \ "DS_RECORD_AND_KEY"
替换以下内容：
EXAMPLE_ZONE：项目中父 DNS 可用区的名称TIME_TO_LIVE：该可用区的生存时间，以秒为单位，例如 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 EXAMPLE_ZONE \ --ttl TIME_TO_LIVE \ --type NS \ --name subdomain.example.com \
替换以下内容：
EXAMPLE_ZONE：项目中父 DNS 可用区的名称TIME_TO_LIVE：该可用区的生存时间，以秒为单位，例如 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。
以下命令为使用 Cloud DNS 的可能最小 DNSSEC 签名响应数据包启用具有 256 位 ECDSA 和 NSEC 的 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 算法，否则会导致兼容性降低并可能危及安全。 某些 DNSSEC 验证解析器可能无法验证 DNSKEY 算法未用于为可用区中的所有记录进行签名的可用区即使 RFC 6840 说明“they must not insist that all algorithms ... in the DNSKEY RRset work.”也是如此。如果您不在意此问题（大多数验证解析器遵循 RFC 6840），那么当您的域名注册商或 TLD 注册系统不支持 ECDSA 并且您需要缩小响应时，您可以对 KSK 和 ZSK 分别使用 RSASHA256 和 ECDSA。
NSEC3 是默认的“否认存在”类型；它会为防范地区遍历程序尝试发现您地区中的所有记录提供有限的保护。NSEC3PARAM 设置是固定的：出于安全考虑，NSEC3 opt-out 处于停用状态，并且还会使用 64 位盐额外进行一次哈希迭代（总共执行两次迭代）。
NSEC 的响应略小一些，但无法防范地区遍历。使用 NSEC 还可以减少对不存在网域的查询。Google 公共 DNS 以及其他一些 DNSSEC 验证解析器可以在不查询您的 Cloud DNS 可用区的情况下从已缓存的 NSEC 记录合成否定响应。
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 生成证书。还可为那些通常对预配的可信 CA 没有应用支持的协议（例如 SMTP）执行证书验证。
根据 RFC 6698 和相关 RFC，您可以借助 DANE（命名实体网域认证）以特定方式使用 TLSA 记录来保护众多协议和应用的安全。IETF 期刊和互联网协会 (IETF Journal and Internet Society) 编制并发布了实用的介绍性文章和 DANE 概览。
HTTPS
借助 DANE，您可以使用通过您自己的 CA 基础架构（基于 OpenSSL 或 Cloudflare 的 CFSSL）生成的证书来妥善配置 HTTPS 服务器。
SIDNLabs 的适用于 HTTPS 服务器的 DANE 验证器有助于测试 HTTPS 的 DANE 部署。
SMTP（电子邮件）TLS 证书验证
SMTP 电子邮件协议容易受到会导致加密失效的降级攻击，而 DANE 可以防范这些攻击。
互联网协会 (Internet Society) 针对如何将 DANE for SMTP 与 Let's Encrypt 提供的免费自动证书（包括建议）结合使用，以免将某些 TLSA 记录格式与 Let's Encrypt 证书结合使用：
您可以在常见错误中找到卓越建议（以及适用于 HTTPS 和 SMTP 的 DANE 网域验证器）。此外，测试您的电子邮件验证器还会检查 DANE。
XMPP（Jabber 聊天）TLS 证书验证
XMPP（以及其他使用 SRV 记录的服务）也可以利用 DANE。 XMPP 示例使用 RFC 7673 中指定的 DANE-SRV 配置。
TXT (OpenPGP/GnuPG) 公钥关联
TXT 记录可以在没有 DNSSEC 的情况下使用，而带有 DNSSEC 签名的 TXT 记录可以为其真实性提供更高的置信度。对于基于 DNS 发布的 OpenPGP (GnuPG) 公钥来说，这一点很重要，因为此类公钥不会经 X.509 等知名 CA 签名。
例如，如果 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"
您可以依照这里的instructions生成这些版本 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 的防火墙后面的用户可能无法访问该服务器（某些密钥服务器会提供端口 80 HTTP 网址）。
TXT（SPF、DKIM 和 DMARC）
以下是另外三种可用来保护电子邮件服务安全的 TXT 记录，这些记录可防止垃圾内容发布者和网络诈骗分子发送貌似（但并非）来自您的网域的电子邮件：
SPF：指定可以代表网域发送电子邮件的 SMTP 服务器（按域名或 IP 地址）。
DKIM：发布一组公钥，用于验证电子邮件是否来自某一网域，并保护邮件在传输过程中不被篡改。
DMARC：指定有关 SPF 和 DKIM 验证与错误报告的网域政策及报告。
如需验证您的网域是否已正确配置为使用所有这三种记录类型，您可以使用测试您的电子邮件验证器。如需查找有关如何配置 SPF 记录的实用建议，请参阅常见错误常见问题解答。
使用由 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 记录的插件。
根据 RFC 4025 第 1.2 节，除了将 IPSECKEY 记录放在常用的正向地区（例如 service.example.com）以外，您的安全网关还必须查找反向地区 ip6.arpa 和 in-addr.arpa. 中的 IPSECKEY 记录。
对反向可用区的 DNSSEC 支持不如正向可用区那么普遍，并且需要一个实现 DNSSEC 的互联网服务提供商 (ISP)。但是，有些 ISP 可以支持将 DNSSEC 用于反向可用区委派。
Compute Engine 虚拟机外部 IP 地址的反向可用区尚不支持委派。
后续步骤
- 如需创建、更新、列出和删除代管区域，请参阅管理区域。
- 如需了解您在使用 Cloud DNS 时可能会遇到的常见问题的解决方案，请参阅问题排查。
- 如需大致了解 Cloud DNS，请参阅 Cloud DNS 概览。