使用高级 DNSSEC

本页面提供了几种高级域名系统安全扩展 (DNSSEC) 配置选项,供您为代管可用区启用 DNSSEC。这些选项包括不同的签名算法和存在性,以及缺少需要使用或推荐 DNSSEC 使用的记录类型的能力。

如需简要了解 DNSSEC,请参阅 DNSSEC 概览

委派带有 DNSSEC 签名的子网域

为主域名启用 DNSSEC 后,可以为委派子网域启用 DNSSEC。要为委派子网域启用 DNSSEC,请先在 Cloud DNS 地区中创建 DS 记录。您还必须创建一条或多条 NS 记录。

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

控制台

  1. 在 Google Cloud Console 中,转到 Cloud DNS 页面。

    转到 Cloud DNS

  2. 转到您要查看 DS 记录的代管可用区。

  3. 如需查看可用区的 DS 记录,请在可用区详细信息页面的右上角,点击注册商设置

  4. DS 记录会显示在注册商设置页面上。

  5. 如需创建 NS 记录,请按照添加记录中的说明进行操作。

“注册商设置”页面

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,该 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
    
  3. 复制上一个命令的输出,以便在后续步骤中使用。

  4. 如需为安全标示创建 DS 记录,请运行以下命令启动事务:

    gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
    

    EXAMPLE_ZONE 替换为您要为委派的子网域创建记录的项目中的父 DNS 可用区的名称。

    输出如下所示:

    Transaction started [transaction.yaml].
    

  5. 接下来,运行以下命令添加记录集:

    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:该可用区的生存时间,以秒为单位,例如 3600
    • subdomain.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].
    

  6. 要添加 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:该可用区的生存时间,以秒为单位,例如 3600
    • subdomain.example.com:可用区的 DNS 名称的子网域
  7. 输入以下 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].
    

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

    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,而无需依靠算法。

下表列出了支持的算法选项和参数。该表格显示了仅可用于请求的默认值和弱值

算法 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

指纹类型如下:

  • 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 期刊和互联网协会 (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"

您可以依照这里的说明生成这些版本 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.nethkp://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.arpain-addr.arpa. 中的 IPSECKEY 记录。

对反向可用区的 DNSSEC 支持不如正向可用区那么普遍,并且需要一个实现 DNSSEC 的互联网服务提供商 (ISP)。但是,有些 ISP 可以支持将 DNSSEC 用于反向可用区委派。

Compute Engine 虚拟机外部 IP 地址的反向可用区尚不支持委派。

后续步骤

  • 如需创建、更新、列出和删除代管区域,请参阅管理区域
  • 如需了解您在使用 Cloud DNS 时可能会遇到的常见问题的解决方案,请参阅问题排查
  • 如需大致了解 Cloud DNS,请参阅 Cloud DNS 概览