高级 DNSSEC

如果您为托管地区启用了 DNSSEC,则可以使用多种高级 DNSSEC 配置选项,其中包括各种签名算法和否认存在类型,以及使用各种需要或推荐结合 DNSSEC 一起使用的记录类型的能力;下文为您介绍这些选项。

委派带有 DNSSEC 签名的子网域

为主域名启用 DNSSEC 后,可以为委派子网域启用 DNSSEC。要为委派子网域启用 DNSSEC,请先在 Cloud DNS 地区中创建 DS 记录。您还必须创建一条或多条 NS 记录。如需了解如何创建 NS 记录,请参阅添加或移除记录

控制台

要为委派子网域创建 DS 记录,您必须获取该地区的 DS 记录。如果委派地区也托管在 Cloud DNS 中,您可以从 Cloud Console 获取 DS 记录。

  1. 导航到托管地区。
  2. 要查看该地区的 DS 记录,请点击 Zone details 页面右上角的 Registrar Setup 链接。
  3. 记下 DS 记录信息后,继续执行 gcloud 命令标签页第 2 步中的过程。

“注册商设置”弹出窗口

gcloud

  1. 要获取委派子网域的 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
    

  2. 要获取完整的 DS 记录和密钥的所有详细信息,您需要 KEY_SIGNING 密钥 (KSK) 的 ID,通常为零 (0)。使用以下命令:

    $ gcloud dns dns-keys describe --zone example_zone ksk_id \
     --format "value(ds_record())"
    

    替换以下命令选项:

    • example_zone:项目中的 DNS 地区的名称
    • ksk_id:ID 编号,通常为 0

    输出如下所示:

    1234 7 1 2FD4E1C67A2D28FCED849EE1BB76E7391B93EB12
    
  3. 要为安全子委派创建 DS 记录,请使用以下命令启动事务:

    $ gcloud dns record-sets transaction start -z example_zone
    

    替换以下命令选项:

    • example_zone:项目中的 DNS 地区的名称
    • subdomain.example.com:地区的 DNS 名称的子网域

    输出如下所示:

    Transaction started [transaction.yaml].
    

  4. 接下来,使用以下命令添加记录集:

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type DS --name subdomain.example.com \
    

    替换以下命令选项:

    • example_zone:项目中的 DNS 地区的名称
    • subdomain.example.com:地区的 DNS 名称的子网域

    输出如下所示:

    36283 5 1 0173d13977ffdf12716E3A1225B1B0B639B8CB46
    Record addition appended to transaction at [transaction.yaml].
    

  5. 要添加 NS 记录,请使用以下命令:

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type NS --name subdomain.example.com \
    

    替换以下命令选项:

    • example_zone:项目中的 DNS 地区的名称
    • subdomain.example.com:地区的 DNS 名称的子网域
  6. 输入以下 RData:

    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].
    

  7. 要执行事务,请使用以下命令:

    $ gcloud dns record-sets transaction execute -z 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(将 example_zone 替换为项目中某个 DNS 地区的名称):

gcloud dns managed-zones update example_zone --dnssec-state on

如需了解详情,请参阅为托管地区启用 DNSSEC

以下命令为使用 Cloud DNS 的可能最小 DNSSEC 签名响应数据包启用具有 256 位 ECDSA 和 NSEC 的 DNSSEC。将 example_zone 替换为项目中某个 DNS 地区的名称:

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

如果您提供任何 KSK 或 ZSK 算法或密钥长度,则必须在命令中提供所有四个选项 (--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length) 及其参数。您可以将“否认存在”指定为 NSEC 或 NSEC3,而无需依靠算法。

下表列出了支持的算法选项和参数,并显示了默认值,以及安全系数较低的值(这些值仅根据请求提供)

算法 KSK 长度 ZSK 长度 备注
RSASHA1 1024、2048 1024、2048 SHA-1 的安全系数较低
RSASHA256 1024、2048 1024、2048
RSASHA512 1024、2048 1024、2048 未得到广泛支持
ECDSAP256SHA256 256 256 可能不受支持
ECDSAP384SHA384 384 384 未得到广泛支持

除非是出于兼容性要求,否则不要使用 RSASHA1;与较长的密钥一起使用时,它没有任何安全优势。

RSASHA256RSASHA512 在安全和性能方面的差异极小,并且签名响应大小也相同。密钥长度十分重要:密钥越长,速度越慢,响应也越大(请参阅根地区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 记录合成否定响应。

在受 DNSSEC 保护的地区中使用全新的 DNS 记录类型

在您的网域获得 DNSSEC 全面保护后,您可以开始使用多种全新的 DNS 记录类型,这些记录类型利用带有 DNSSEC 签名的地区的真实性和完整性保证来增强其他服务的安全。

SSHFP

SSHFP 记录包含 SSH 服务器公钥的指纹,可供 SSH 客户端应用用来验证 SSH 服务器。SSH 客户端在第一次建立连接时通常需要用户互动才能确认服务器的公钥,并会在此公钥更改时生成警告。配置为使用 SSHFP 的 SSH 客户端始终使用服务器的 SSHFP 记录中的密钥来验证该服务器;只有没有 SSHFP 记录的服务器的密钥才会保存下来,以供重复使用。

SSHFP 记录格式如下:算法编号、指纹类型编号和服务器密钥指纹。SSH 的算法编号如下

  1. RSA
  2. DSA
  3. ECDSA
  4. ED25519

指纹类型如下

  1. SHA-1(已弃用,仅限出于兼容性要求使用)
  2. SHA-256

StackExchange 提供了一些有关创建 SSHFP 的建议以及一些工具,借助这些工具,您可以通过扫描服务器、使用现有的已知托管文件配置管理来生成 SSHFP 记录。 这些说明包含更多的示例和链接。

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,您可以使用通过您自己的证书授权机构基础架构(基于 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://dane.sys4.de/common_mistakes 上也提供了一些很好的建议(以及一个适用于 HTTPS 和 SMTP 的 DANE 网域验证器)。“测试您的电子邮件”(Test your email) 验证器也会执行 DANE 检查。

XMPP(Jabber 聊天)TLS 证书验证

XMPP(以及使用 SRV 记录的其他服务)也可以利用 DANE。XMPP 示例使用了 RFC 7673 中指定的 DANE-SRV 配置。

TXT (OpenPGP/GnuPG) 公钥关联

TXT 记录可以在没有 DNSSEC 的情况下使用,而带有 DNSSEC 签名的 TXT 记录可以为其真实性提供更高的置信度。对于基于 DNS 发布的 OpenPGP (GnuPG) 公钥来说,这一点很重要,因为此类公钥不会经 X.509 等知名证书授权机构签名。如果 Alice(在带有 DNSSEC 签名的 an.example 地区中)发布了一条如下所示的 TXT 记录:

alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"

并在给定的 URI 上托管了一个经 ASCII 封装的公钥副本,那么 Bob 可通过合理的安全机制来查找 alice@an.example 的 OpenPGP 密钥(这并非替代信任网络验证,而是让之前未知的机构能够执行 OpenPGP 加密)。

您可以依照这里的说明生成这些“PKA 第 1 版”TXT 记录(这是此 DNS 密钥概览中采用的命名)。另一个方法指南也介绍了如何创建 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.nethkp://pgp.mit.edu,但位于阻止了端口 11371 的防火墙后面的用户可能无法访问该服务器(某些密钥服务器会提供端口 80 HTTP 网址)。

TXT(SPF、DKIM 和 DMARC)

还有另外三种可用来保护电子邮件服务安全的 TXT 记录,这些记录可防止垃圾内容发布者和网络诈骗分子发送貌似(但并非)来自您的网域的电子邮件。

SPF
指定可以代表网域发送电子邮件的 SMTP 服务器(按域名或 IP 地址)。
DKIM
发布一组公钥,用于验证电子邮件是否来自某一网域,并保护邮件在传输过程中不被篡改。
DMARC
指定有关 SPF 和 DKIM 验证与错误报告的网域政策及报告。

您可以使用“测试您的电子邮件”(Test your email) 验证器来验证您的网域是否已正确配置为使用所有这三种记录类型。在常见问题解答中,您可以找到有关配置 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.arpain-addr.arpa. 中的 IPSECKEY 记录。

对反向地区的 DNSSEC 支持不如正向地区那么普遍,并且需要互联网服务提供商自身也部署 DNSSEC,但有些可以在委派反向地区时提供 DNSSEC 支持。

请注意,Google Compute Engine 虚拟机外部 IP 的反向地区尚不支持委派。请参阅 Google Compute Engine 功能请求

后续步骤