Google PCNE: Cloud DNS、服务发现和混合名称解析 — 学习指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

属于 Google Professional Cloud Network Engineer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Cloud DNS 是 Google Cloud 的可扩展、高可用的 DNS 服务，同时支持公共权威区域和 VPC 的私有 DNS。它还提供混合名称解析原语——转发、对等互连、入站服务器、响应策略和 DNS 策略——以与本地 DNS 和多云环境集成。本节涵盖权威 DNS 生命周期、私有区域的可见性与共享、混合解析、服务发现模式、安全性与完整性（包括 DNSSEC 和区域传送）、使用路由策略进行高级流量管理、用于私有服务端点的 DNS，以及第二天运维，如故障排查、缓存、日志记录和迁移/共存策略。

权威 DNS 和 DNS 生命周期

受管区域和记录
- 受管区域 (managed zone) 是单个 DNS 名称（区域顶点）的资源记录集 (RRsets) 的容器。
- 记录类型：A、AAAA、CNAME、MX、TXT、SRV、PTR、NS、SOA（及更多）。Cloud DNS 不支持在区域顶点使用 CNAME；应使用 A/AAAA 记录配合负载均衡器的 IP 进行顶点映射。
- 生命周期：创建区域、添加/修改记录（事务性变更）、传播以及运维（监控/日志/安全）。
- 从现有的 BIND 文件导入以加速迁移：
  - 示例：gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
公开区域 vs 私有区域
- 公开区域可通过 Google 公共权威域名服务器进行全球访问。通过在注册商处更新父级区域的 NS 记录来进行委派。
- 私有区域仅对其附加的 VPC 网络进行应答。它们由 Google 的 VPC 范围解析器为这些 VPC 中的实例解析，并可选择性地通过入站转发为混合客户端解析。
传播和 TTL
- 在 Google Cloud 内部，记录变更在数秒内生效；外部缓存的失效则取决于 TTL。
- TTL 权衡：短 TTL 可以提高敏捷性并使切换更安全，但会增加查询负载并可能降低缓存效率；长 TTL 可以减少负载，但会延长过期应答的持续时间。常见做法：动态服务使用 60–300 秒；稳定记录使用 600–3600 秒。在切换前，提前 24–48 小时减小 TTL。

私有区域的可见性、VPC 关联和跨项目设计

将私有区域附加到 VPC
- 私有区域与一个或多个 VPC 网络明确关联。关联可以跨项目（需要在区域上拥有适当的 IAM 权限，如 dns.admin，以及绑定网络的权限）。
- 优先级：在附加到同一 VPC 的所有私有区域中，最长后缀匹配的区域胜出；当私有区域重叠时（例如 svc.corp.internal. 和 corp.internal.），需要特别小心。
- 跨 VPC 共享模式
  - 直接附加：将同一个私有区域附加到多个 VPC。操作简单；但应避免在不需要的地方进行附加，以减小爆炸半径。
  - 共享 VPC (Shared VPC)：在宿主项目中集中管理 DNS，同时通过将子网所在的 VPC 附加到区域，来向服务项目公开 DNS。
  - DNS 对等互连区域：当网络之间使用 VPC 对等互连时，使用方 VPC 中的对等互连区域可以解析来自生产方 VPC 的私有记录，而无需复制区域。
故障模式和防护措施
- 遮蔽 (Shadowing)：与公共区域同名的私有区域会导致其所附加的 VPC 中的客户端优先选择私有应答，这可能破坏对公共端点的访问。应有目的地使用分离式水平 DNS (split-horizon)，并进行文档记录和测试。
- 过度附加：将私有区域广泛附加可能会泄露内部名称。应遵循最小权限原则，并使用独立的子域（按区域/服务划分范围）来限制范围。
- IAM 分离：将 DNS 变更权限 (dns.admin) 与网络附加权限（绑定网络的权限）分开委派，以实现独立的管理域。

简短示例：创建并附加一个私有区域

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --visibility=private \
  --description="Private corp zone" \
  --networks=prod-vpc,stg-vpc

混合名称解析：转发、对等和政策

转发区域
- 将特定后缀（例如 onprem.corp.）的查询权威性地转发到指定的名称服务器（本地或其他云）。当您不在 Cloud DNS 中托管该区域，但需要从 GCP 进行无缝解析时使用。
- 避免循环：确保本地转发器不会将相同后缀的查询指回 Cloud DNS。
对等区域
- 解析托管在对等 VPC 中的私有区域。需要 VPC 对等连接；不具备传递性。用于中心辐射型设计，将私有 DNS 集中在中心 VPC 中。
DNS 政策
- 出站转发：VPC 中的实例将无法在 Cloud DNS 私有区域中解析的域名的递归查询发送到本地解析器。通过 DNS 政策进行配置，指定可通过 Cloud VPN/Interconnect 访问的目标名称服务器 IP。
- 入站服务器：本地解析器将查询转发到 Google 提供的入站转发 IP（自动分配的 35.199.192.0/20），以解析 Cloud DNS 私有区域。用于将 GCP 私有 DNS 扩展到本地和其他云。
- 查询日志记录：在政策级别启用，将解析器查询日志发送到 Cloud Logging 进行分析和故障排查。对于公共区域，为权威查询启用按区域的查询日志记录。
响应政策
- 定义规则以修改响应（例如，对已知的恶意域返回 NXDOMAIN，或合成内部 A 记录以覆盖公共应答）。请谨慎应用；验证关键的第三方域没有被无意中阻止。
连接性先决条件
- 为确保出站/入站正常工作，请确保混合连接（Cloud VPN 或 Interconnect）和防火墙规则根据需要双向允许 UDP/TCP 53 端口。EDNS0 和 UDP 分片行为在不同网络中有所不同——如果出现 MTU 问题，请允许 TCP 回退，并考虑在本地解析器上调整 EDNS(0) 缓冲区。
常见陷阱
- 非对称可达性：如果出站转发指向本地解析器，但返回流量被防火墙或路由不对称所阻止，查询将会超时。请验证 Cloud Router 已学习到的路由，并允许 DNS 响应流量。
- 重叠的后缀：重叠的企业后缀（例如 corp.local vs corp.internal）可能导致意外的解析器搜索路径匹配。请标准化搜索路径和后缀所有权。

简短示例：

# Outbound forwarding policy to on-prem resolvers
gcloud dns policies create corp-outbound \
  --networks=prod-vpc \
  --forwarding-targets=10.1.0.10,10.1.0.11 \
  --enable-logging

# Forwarding zone for partner domain
gcloud dns managed-zones create partner-fwd \
  --dns-name=partner.example. \
  --visibility=private \
  --forwarding-targets=172.16.10.53,172.16.11.53 \
  --networks=prod-vpc

服务发现、水平分割 DNS 和私有端点

水平分割 DNS
- 为同一名称在内部和外部提供不同的应答。典型模式：公共的 foo.example.com 解析为公共 Anycast IP；内部的 foo.example.com 解析为内部负载均衡器（ILB）的 RFC1918 地址。通过使用一个公共区域和一个同名的私有区域来实现，并谨慎地将私有区域的作用域限定在适当的 VPC。
内部服务命名
- 使用一致的内部后缀（例如 svc.corp.internal）和面向服务的记录（A/AAAA、SRV 或用于发现的特定 TXT）。对于动态扩展的服务，保持较低的 TTL。
- GKE 服务发现：集群内部名称保留在 CoreDNS 中（svc.cluster.local）。要跨命名空间/VPC 暴露，可将 ILB VIP 发布到 Cloud DNS 私有区域或使用 Service Directory 集成。
Service Directory 集成
- 通过 Service Directory 和 Cloud DNS 自动将服务端点发布到 DNS，为每个命名空间/服务生成 SRV 和 A 记录。这对于解耦生产者和消费者以及支持对服务实例进行健康感知发现非常有用。
私有服务端点
- 连接到 Google API 的 Private Service Connect (PSC)：使用 PSC 端点私下引导 googleapis.com 的流量，或使用受限 Google API VIP (199.36.153.8/30) 并为 googleapis.com 配置一个私有区域。PSC 提供区域性的本地私有 IP 连接和每个端点的控制；受限 VIP 更简单，但仍使用可通过默认路由访问的公共 IP 范围。
- 连接到生产者服务的 PSC：在私有区域中创建指向 PSC 端点或 ILB VIP 的 A/AAAA 记录。对于自定义内部域，在 Cloud DNS 中管理私有区域并将其附加到消费者 VPC。
权衡取舍
- PSC 与受限 VIP 的对比：PSC 提供精细的控制并避免出口检查路径；它需要在每个区域进行端点/DNS 设置。受限 VIP 部署迅速，但使用共享 VIP，并可能与出口路由策略相互作用。
- 水平分割 DNS 风险：作用域配置不当的私有区域可能会黑洞化对公共 SaaS 的访问。在广泛推广之前，通过金丝雀虚拟机和查询日志记录进行验证。

简短示例：内部 ILB 映射

; Private zone: corp.internal.
web.svc.corp.internal.  60  IN  A 10.20.0.15

安全、流量管理、运维和迁移

DNSSEC 与完整性
- 公共区域：在 Cloud DNS 中启用 DNSSEC 签名，并在注册商处发布 DS 记录，以防止欺骗和缓存中毒。规划密钥轮替窗口，并监控验证失败情况。
- 私有区域：DNSSEC 验证/签名通常没有必要，因为解析发生在受信任的网络上；重点应放在传输安全（混合链路）和解析器加固上。
托管区域传送
- Cloud DNS 可以作为 AXFR/IXFR 的主服务器或辅助服务器。使用 TSIG 对传送进行身份验证/授权，并使用 NOTIFY 实现及时传播。区域传送模式简化了迁移期间的共存，并支持本地辅助服务器以满足法规或弹性需求。
- 失败模式：传送被防火墙阻止、TSIG 密钥不匹配、SOA 序列号未增加，或主服务器上禁用了 IXFR 导致进行完整的 AXFR。
路由政策与健康检查
- Cloud DNS 支持流量导向政策（加权、地理位置、延迟和故障切换）。将健康检查附加到端点，以自动撤销不健康的应答。
- 设计技巧：保持每个策略目标的记录集规模较小；优先选择与用户足迹一致的区域范围；将低 TTL 与故障检测间隔相结合，以限定故障切换时间。
- 陷阱：过于精细的地理位置映射可能导致运维复杂性；缺乏一致的健康信号会导致抖动——应使用稳定阈值和与应用程序行为一致的健康检查超时。
问题排查
- 工具：使用 dig/nslookup 配合 +trace、+short 和 +dnssec 来验证链；审查 Cloud Logging 中的解析器查询日志（DNS 政策）和权威查询日志（托管区域）。
- 缓存：确认您正在测试哪个解析器（虚拟机的 /etc/resolv.conf 通常指向 Google 的 VPC 解析器）。在测试 TTL 更改时，刷新本地解析器缓存。考虑否定缓存（RFC 2308）：NXDOMAIN 响应会根据 SOA MINIMUM/否定 TTL 进行缓存。
- 常见问题：出站转发与本地条件转发器之间的循环；UDP 53 端口被阻止或 MTU 问题导致响应被截断；公共区域被私有区域遮蔽。
运维模式
- 变更控制：使用事务批量处理变更，在切换前降低 TTL，并使用金丝雀 VPC 连接来验证可见性。
- 日志记录与监控：有选择地启用查询日志记录；将日志导出到 BigQuery 进行趋势分析，并针对 SERVFAIL/NXDOMAIN 峰值创建警报。
- 访问控制：将记录变更角色与网络连接角色分开；对响应策略编辑者强制执行最小权限，以避免无意的域名阻止。
迁移与共存
- 共存：通过 AXFR/IXFR 将 Cloud DNS 设置为辅助服务器，而本地 DNS 仍为主服务器；或者反向操作（Cloud DNS 为主，本地为辅）。使用 TSIG 和允许列表。
- 条件转发：对于保留在本地的域，创建转发区域或出站转发策略。确保混合链路是高可用的（使用不同对等体和 Cloud Router 的双 VPN）。
- 多组织桥接：通过 Cloud VPN/Cloud Router 连接 VPC，根据需要建立相互的条件转发或对等连接，并对正在迁移的区域使用区域传送。在更改注册商的 NS 或 DS 记录之前，提前大幅降低 TTL。

简短示例：

# Enable authoritative query logging for a public zone
gcloud dns managed-zones update prod-public --enable-logging

# Create inbound servers policy (IP allocation is automatic)
gcloud dns policies create corp-inbound --networks=prod-vpc

实际问题场景

Contoso Retail 和 Fabrikam Payments 是两个独立的 Google Cloud 组织，它们必须在一年内实现互操作，同时以最少的停机时间整合网络和 DNS。每个组织都使用不重叠的 10.0.0.0/8 地址空间。Contoso 将在 svc.contoso.internal 下托管内部服务；Fabrikam 将继续在本地托管 pay.fabrikam.internal。双方都需要解析彼此的私有名称，并逐步将一些区域迁移到 Cloud DNS。

方法：

建立弹性的混合连接
- 在 Contoso 的中心 VPC 和 Fabrikam 的本地路由器之间创建两个 Cloud VPN 隧道，每个隧道连接到一个不同的 Fabrikam 公共 IP，并在两个隧道上都使用 Cloud Router BGP。
- 理由：双隧道加动态路由提供路径冗余，并自动传播 DNS 目标的路由，从而降低了 UDP/TCP 53 的非对称路由风险。
在两个方向上实现条件名称解析
- 在 Contoso，创建一个名为 fabrikam.internal 的转发区域，将其转发到 Fabrikam 的本地 DNS 服务器（例如 172.20.10.53 和 172.20.11.53），并将其附加到应用 VPC。
- 在 Fabrikam，在其本地 DNS 上配置条件转发器，将 svc.contoso.internal 转发到由 Cloud DNS 入站策略提供的 Contoso Cloud DNS 入站转发 IP。
- 理由：转发区域避免了重复的授权，并允许每一方将其 DNS 保留在当前位置。入站服务器将 Cloud DNS 私有解析扩展到 Fabrikam，而无需广泛更改其解析器。
防止转发循环并强制执行可见性边界
- 确保 Fabrikam 的条件转发器不会将 Fabrikam 仍然拥有的 contoso.internal 名称转发回 Contoso；同样，Contoso 只应转发 fabrikam.internal。
- 仅将 Contoso 的私有区域附加到需要它们的 VPC；不要进行全局附加，以减小爆炸半径。
- 理由：消除 DNS 递归循环，并防止私有区域遮蔽公共域。
使用托管区域传送迁移共享区域
- 对于当前托管在 Fabrikam 的 BIND 主服务器上的旧共享区域 legacy.shared.internal，将 Cloud DNS 配置为使用 TSIG 的辅助服务器，并将 Fabrikam 的主服务器列入 AXFR/IXFR 的允许列表。在共存期间，保持 Fabrikam 为主服务器。
- 理由：辅助模式无需更改客户端即可提供实时同步。它使得在 Contoso 中进行安全验证成为可能，同时保持单一事实来源。
为外部暴露的服务引入水平分割 DNS
- 创建一个公共区域 contoso.example，其记录指向一个面向客户的全局 HTTPS 负载均衡器 IP。创建一个同名的私有区域，附加到内部 VPC，将相同的名称映射到内部 ILB 地址。
- 理由：外部用户继续访问边缘负载均衡器；内部服务通过 RFC1918 地址访问私有 ILB，从而优化延迟和成本，同时保持一致的主机名。
无需通过防火墙出口即可私密访问 Google API
- 对于没有外部 IP 的 Contoso 虚拟机，为 Google API 启用 Private Service Connect，并为 googleapis.com 创建托管的私有 DNS 区域，该区域映射到 PSC 端点。
- 理由：确保对 BigQuery 和 Pub/Sub 的访问保持在 VPC 内部的私有和本地状态，避免了第三方出口设备，并维护了安全态势。
启用可观测性与控制
- 在 Contoso 的 DNS 策略上为相关 VPC 开启 Cloud DNS 查询日志记录，并在公共区域上开启权威查询日志记录。创建响应策略规则，以在整个组织范围内阻止已知的恶意域。
- 理由：查询遥测数据支持问题排查和容量规划；响应策略为安全提供了集中控制，而无需触及每个解析器。
使用安全的 TTL 执行变更管理
- 在变更前一周，将被迁移记录的 TTL 降低到 60 秒。在验证和切换（例如，将服务从本地切换到 GCP ILB）之后，逐渐将 TTL 提高到 300-600 秒。
- 理由：短 TTL 可以在转换期间控制风险；恢复较高的 TTL 可以在稳定后提高缓存效率。
测试、验证和加固
- 从双方的金丝雀虚拟机上，使用 dig 和 +trace 运行命令，验证权威路径，确认日志中没有 SERVFAIL/NXDOMAIN 峰值，并模拟链路故障以观察 VPN 冗余下的 DNS 行为。
- 理由：主动验证可以及早发现循环/可见性问题；故障模拟可以验证混合解析在传输事件中能否幸免，而不会影响用户。