DNS 区域概览

Cloud DNS 支持不同类型的公开和专用可用区。本页详细介绍了不同的可用区类型，并提供了有关在什么情况下可以使用哪种政策的说明。

转发地区

Cloud DNS 转发地区允许您为特定专用地区配置目标域名服务器。使用转发地区是从 VPC 网络实现出站 DNS 转发的一种方法。

Cloud DNS 转发地区是一种特殊类型的 Cloud DNS 专用地区。您可以指定一组转发目标，而不是在该地区内创建记录。每个转发目标都是 DNS 服务器的一个 IP 地址，DNS 服务器要么位于您的 VPC 网络，要么在通过 Cloud VPN 或 Cloud Interconnect 连接到 VPC 网络的本地网络中。

转发目标和路由方法

Cloud DNS 支持三种类型的目标，并提供标准或专用路由方法以用于连接。

转发目标	说明	标准路由支持	专用路由支持	请求来源
类型 1	有权使用转发区域的同一 VPC 网络中的 Google Cloud 虚拟机或内部直通式网络负载均衡器的内部 IP 地址。	仅限 RFC 1918 IP 地址 - 流量始终通过获得授权的 VPC 网络进行路由。	任何内部 IP 地址，例如 RFC 1918 专用地址、非 RFC 1918 专用 IP 地址或以非公开方式重复使用的外部 IP 地址，但禁止的转发目标 IP 地址除外 - 流量始终通过已获授权的 VPC 网络路由。	`35.199.192.0/19`
类型 2	本地系统的 IP 地址，使用 Cloud VPN 或 Cloud Interconnect 连接到有权查询转发地区的 VPC 网络。	仅限 RFC 1918 IP 地址 - 流量始终通过获得授权的 VPC 网络进行路由。	任何内部 IP 地址，例如 RFC 1918 专用地址、非 RFC 1918 专用 IP 地址或以非公开方式重复使用的外部 IP 地址，但禁止的转发目标 IP 地址除外 - 流量始终通过已获授权的 VPC 网络路由。	`35.199.192.0/19`
类型 3	可供互联网或 Google Cloud 资源的外部 IP 地址访问的 DNS 域名服务器的外部 IP 地址；例如，另一个 VPC 网络中虚拟机的外部 IP 地址。	仅限通过互联网路由的外部 IP 地址 - 流量始终路由到互联网或 Google Cloud 资源的外部 IP 地址。	不支持专用路由 - 请确保未选中专用路由。	Google 公共 DNS 来源范围

向转发地区添加转发目标时，您可以在以下两种路由方法中选择一种：

标准路由：根据转发目标是否是 RFC 1918 IP 地址，通过获得授权的 VPC 网络或互联网路由流量。如果转发目标是 RFC 1918 IP 地址，则 Cloud DNS 会将该目标分类为类型 1 或类型 2 目标，并通过获得授权的 VPC 网络路由请求。如果目标不是 RFC 1918 IP 地址，则 Cloud DNS 会将目标分类为类型 3，并希望目标可从互联网访问。
专用路由：无论目标的 IP 地址是什么（无论是否 RFC 1918），始终通过获得授权的 VPC 网络路由流量。因此，仅“类型 1”和“类型 2”目标受到支持。

要访问类型 1 或类型 2 转发目标，Cloud DNS 会使用 DNS 客户端所在的获得授权的 VPC 网络中的路由。这些路由定义指向转发目标的安全路径：

为了将流量发送到类型 1 目标，Cloud DNS 使用自动创建的子网路由。为了进行回复，类型 1 目标使用 Cloud DNS 响应的特殊返回路由。
为了将流量发送到类型 2 目标，Cloud DNS 可以使用自定义动态路由或自定义静态路由（带网络标记的自定义静态路由除外）。为了进行回复，类型 2 转发目标使用本地网络中的路由。

如需有关类型 1 和类型 2 目标的网络要求的更多指导，请参阅转发目标网络要求。

禁止使用的转发目标 IP 地址

您不能将以下 IP 地址用于 Cloud DNS 转发目标：

169.254.0.0/16
192.0.0.0/24
192.0.2.0/24
192.88.99.0/24
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4
240.0.0.0/4
::1/128
::/128
2001:db8::/32
fe80::/10
fec0::/10
ff00::/8

转发目标选择顺序

Cloud DNS 允许您为转发可用区配置转发目标列表。

配置两个或更多个转发目标时，Cloud DNS 会使用内部算法选择转发目标。此算法会将每个转发目标排名。

如需处理请求，Cloud DNS 首先通过联系排名最高的转发目标来尝试 DNS 查询。如果该服务器没有响应，则 Cloud DNS 会重复对排名次高的转发目标的请求。如果没有转发目标回复，则 Cloud DNS 会合成 SERVFAIL 响应。

排名算法是自动的，以下因素可提高转发目标的排名：

转发目标处理的成功 DNS 响应数量越大。成功的 DNS 响应包括 NXDOMAIN 响应。
与转发目标通信的延迟时间（往返时间）较短。

使用转发可用区

在以下情况下，VPC 网络中的虚拟机可以使用 Cloud DNS 转发地区：

VPC 网络已获得使用 Cloud DNS 转发地区的授权。您可以授权同一项目中的多个 VPC 网络使用转发地区。
VPC 网络中每个虚拟机的客机操作系统都使用该虚拟机的元数据服务器 169.254.169.254 作为域名服务器。

重叠转发地区

由于 Cloud DNS 转发地区是一种 Cloud DNS 托管专用地区，所以您可以创建多个重叠的地区。按上述方式配置的虚拟机会使用带最长后缀的可用区，根据名称解析顺序解析记录。如需了解详情，请参阅重叠地区。

缓存和转发地区

Cloud DNS 会缓存对发送到 Cloud DNS 转发地区的查询进行的响应。Cloud DNS 会在以下时间范围内（以其中较短者为准）存留可访问转发目标所做响应的缓存：

60 秒
记录的存留时间 (TTL) 的长度

当某个转发地区的所有转发目标都无法访问时，Cloud DNS 会在每个记录的 TTL 内在该地区中保留之前请求的记录的缓存。

何时改用对等互连

Cloud DNS 无法使用传递性路由来连接到转发目标。为了说明哪些配置无效，请考虑以下几种情况：

您已使用 Cloud VPN 或 Cloud Interconnect 将本地网络连接到名为 vpc-net-a 的 VPC 网络。
您已使用 VPC 网络对等互连将 VPC 网络 vpc-net-a 连接到 vpc-net-b。您已将 vpc-net-a 配置为导出自定义路由，并将 vpc-net-b 配置为导入自定义路由。
您已创建转发地区，该地区的转发目标位于 vpc-net-a 连接到的本地网络中。您已授权 vpc-net-b 使用该转发地区。

这种情况下，即使 vpc-net-b 已连接到您的本地网络，也无法解析由转发目标提供服务的地区中的记录。为了演示此失败，请从 vpc-net-b 中的虚拟机执行以下测试：

查询虚拟机的元数据服务器 169.254.169.254，获取在转发地区中定义的记录。此查询会失败（预料之中），这是因为 Cloud DNS 不支持到转发目标的传递性路由。要使用转发地区，必须将虚拟机配置为使用其元数据服务器。
直接查询该记录的转发目标。虽然 Cloud DNS 不使用此路径，但此查询表明传递性连接成功了。

您可以使用 Cloud DNS 对等互连地区来修复此无效场景：

创建一个 Cloud DNS 对等互连地区，并授权该地区使用目标为 vpc-net-a 的 vpc-net-b。
创建一个转发地区，并授权该地区使用转发目标为本地域名服务器的 vpc-net-a。

您可以按任意顺序执行上述步骤。完成上述步骤后，vpc-net-a 和 vpc-net-b 中的 Compute Engine 实例都可以查询本地转发目标。

如需了解如何创建转发可用区，请参阅创建转发可用区。

对等互连地区

借助 DNS 对等互连功能，您可以将一个地区的命名空间内记录的请求发送至另一个 VPC 网络。例如，SaaS 提供商可以授予 SaaS 客户访问其管理的 DNS 记录的权限。

如需提供 DNS 对等互连功能，您必须创建一个 Cloud DNS 对等互连地区，并将其配置为在该地区命名空间的记录所在的 VPC 网络内执行 DNS 查找。DNS 对等互连地区在其中执行查找的 VPC 网络就称为 DNS 提供方网络。

对等互连地区仅对在地区配置期间选择的 VPC 网络可见。经授权可以使用对等互连地区的 VPC 网络称为 DNS 使用方网络。

当 DNS 使用方网络中的 Google Cloud 资源获得授权后，他们可以在对等互连地区的命名空间中查找记录，就像这些资源位于 DNS 提供方网络中一样。在对等互连地区的命名空间中查找记录时，需要遵循 DNS 提供方网络的名称解析顺序。

因此，DNS 使用方网络中的 Google Cloud 资源可以在地区命名空间内查找来自 DNS 提供方网络中如下来源的记录：

由 DNS 提供方网络授权使用的 Cloud DNS 代管专用地区。
由 DNS 提供方网络授权使用的 Cloud DNS 代管转发地区。
DNS 提供方网络中的 Compute Engine 内部 DNS 名称。
备用域名服务器（如果已在 DNS 提供方网络中配置出站服务器政策）。

DNS 对等互连限制和要点

配置 DNS 对等互连时请注意以下几点：

DNS 对等互连是一种单向关系。它允许 DNS 使用方网络中的 Google Cloud 资源在对等互连地区的命名空间内查找记录，就像这些 Google Cloud 资源位于 DNS 提供方网络中一样。
DNS 提供方网络与 DNS 使用方网络必须均为 VPC 网络。
虽然 DNS 提供方网络与使用方网络通常属于同一组织，但跨组织 DNS 对等互连也受支持。
DNS 对等互连和 VPC 网络对等互连是不同的服务。DNS 对等互连可与 VPC 网络对等互连结合使用，但 VPC 网络对等互连并非使用 DNS 对等互连的前提条件。
支持传递性 DNS 对等互连，但只能通过一个传递跃点。换句话说，不能牵涉到三个以上 VPC 网络（中间的网络是传递跃点）。例如，您可以在 vpc-net-a 中创建目标为 vpc-net-b 的对等互连地区，然后在 vpc-net-b 中创建目标为 vpc-net-c 的对等互连地区。
如果您使用 DNS 对等互连来定位转发可用区，则具有转发可用区的目标 VPC 网络必须包含位于使用 DNS 对等互连可用区的来源虚拟机所在区域中的虚拟机、VLAN 连接或 Cloud VPN 隧道。如需详细了解此限制，请参阅将查询从使用方 VPC 网络中的虚拟机转发至提供方 VPC 网络不起作用。

如需了解如何创建对等互连区域，请参阅创建对等互连区域。

代管式反向查找可用区

代管式反向查找可用区是具有特殊属性的专用可用区，它指示 Cloud DNS 对 Compute Engine DNS 数据执行 PTR 查找。

专用地区中 RFC 1918 地址的 PTR 记录

如需对 RFC 1918 地址的自定义 PTR 记录执行反向查找，您必须创建一个 Cloud DNS 专用地区，该专用地区至少与以下某个示例地区一样具体。这是名称解析顺序中描述的最长后缀匹配造成的。

示例地区包括：

10.in-addr.arpa.
168.192.in-addr.arpa.
16.172.in-addr.arpa.、17.172.in-addr.arpa.、......一直到 31.172.in-addr.arpa.

如果您为 RFC 1918 地址创建了 Cloud DNS 专用地区，则您为该地区中的虚拟机创建的自定义 PTR 记录会被内部 DNS 自动创建的 PTR 记录覆盖。这是因为内部 DNS PTR 记录是在之前的、更具体的地区列表中创建的。

举例来说，假设您为 in-addr.arpa. 创建了托管专用地区，其 IP 地址为 10.1.1.1 的虚拟机具有以下 PTR 记录：

1.1.1.10.in-addr.arpa. -> test.example.domain

PTR 对 1.1.1.10.in-addr.arpa. 的查询将由更加具体的 10.in-addr.arpa. 内部 DNS 地区应答。系统将忽略您的 Cloud DNS 专用地区中针对 test.example.domain 的 PTR 记录。

如需替换自动创建的虚拟机的内部 DNS PTR 记录，请务必在一个专用地区中创建您的自定义 PTR 记录，该专用地区至少与本部分中显示的某个示例地区一样具体。例如，如果您在某个专用地区中为 10.in-addr.arpa. 创建以下 PTR 记录，则您的记录会替换自动生成的记录：1.1.1.10.in-addr.arpa. -> test.example.domain。

如果只需要替换一部分网络块，您可以创建更加具体的反向 Cloud DNS 专用地区。例如，5.10.in-addr.arpa. 的专用地区可用于保留 PTR 记录，以替换自动创建的 IP 地址在 10.5.0.0/16 地址范围内的虚拟机的任何内部 DNS PTR 记录。

有关如何创建代管式反向查找可用区的说明，请参阅创建代管式反向查找可用区。

重叠地区

如果一个地区的来源域名与另一个地区的来源相同，或者前者是后者的子网域，那么这两个地区彼此重叠。例如：

gcp.example.com 的地区与 gcp.example.com 的另一个地区重叠，因为域名相同。
dev.gcp.example.com 的地区和 gcp.example.com 的地区重叠，因为 dev.gcp.example.com 是 gcp.example.com 的子网域。

重叠地区的规则

Cloud DNS 针对重叠地区强制执行以下规则：

同一 Cloud DNS 域名服务器上不得存在重叠的公开地区。创建重叠地区时，Cloud DNS 会尝试将这些地区放在不同的域名服务器上。如果无法这样操作，则 Cloud DNS 无法创建重叠地区。
专用地区可以与任何公开地区重叠。
位于不同 VPC 网络范围内的专用地区可以彼此重叠。例如，两个 VPC 网络在地区 gcp.example.com 中可以分别包含一个名为 database.gcp.example.com 的数据库虚拟机。根据授权使用各个 VPC 网络的地区中定义的地区记录，对 database.gcp.example.com 的查询将会收到不同的响应。
有权通过同一 VPC 网络访问的两个专用地区不能具有相同的来源，除非一个地区是另一个地区的子网域。元数据服务器利用最长后缀匹配原则来决定从哪个来源查询给定地区中的记录。

查询解析示例

Google Cloud 按照名称解析顺序中所述解析 Cloud DNS 地区。在确定要查询给定记录的地区时，Cloud DNS 会尝试查找尽可能与所请求的记录相匹配（最长后缀匹配）的专用地区。

除非您在出站服务器政策中指定了备用域名服务器，否则 Google Cloud 会先尝试在获得 VPC 网络使用授权的专用地区（或转发地区或对等互连地区）中查找记录，然后再在公开地区中查找记录。

以下示例说明了查询 DNS 记录时元数据服务器使用的顺序。对于每个示例，假设您已创建两个专用地区（gcp.example.com 和 dev.gcp.example.com），并且已授权通过同一 VPC 网络访问它们。Google Cloud 按以下方式处理从 VPC 网络中的虚拟机进行的 DNS 查询：

元数据服务器使用公开域名服务器来解析 myapp.example.com. 的记录（注意尾随点），因为没有已针对 VPC 网络授权的 example.com 的专用地区。通过 Compute Engine 虚拟机使用 dig 来查询虚拟机的默认域名服务器：
```
dig myapp.example.com.
```
如需了解详情，请参阅使用元数据服务器查询 DNS 名称。
元数据服务器使用获得授权的专用地区 gcp.example.com 解析记录 myapp.gcp.example.com，因为 gcp.example.com 是所请求的记录名称与可用的已授权专用地区之间的最长公共后缀。如果 gcp.example.com 专用地区中没有定义 myapp.gcp.example.com 的记录，则返回 NXDOMAIN，即使在公共地区中定义了 myapp.gcp.example.com 的记录也是如此。
同样，对 myapp.dev.gcp.example.com 的查询将根据已获授权的专用地区 dev.gcp.example.com 中的记录进行解析。如果 dev.gcp.example.com 地区中没有 myapp.dev.gcp.example.com 的记录，则返回 NXDOMAIN，即使另一个专用或公开地区中存在 myapp.dev.gcp.example.com 的记录也是如此。
对 myapp.prod.gcp.example.com 的查询会根据专用地区 gcp.example.com 中的记录进行解析，因为 gcp.example.com 是所请求的 DNS 记录和可用专用地区之间的最长公共后缀。

水平分割 DNS 示例

您可以在水平分割 DNS 配置中使用公开地区和专用地区的组合。在专用地区中，当查询来自获得授权的 VPC 网络中的虚拟机时，您可以为对同一记录的查询定义不同响应。如果您需要根据来源 VPC 网络为同一 DNS 查询提供不同的记录，水平分割 DNS 会非常有用。

请考虑以下水平分割示例：

您已创建公开地区 gcp.example.com，并且您已将其注册商配置为使用 Cloud DNS 域名服务器。
您已创建专用地区 gcp.example.com，并且已授权您的 VPC 网络访问此地区。

在该专用地区中，您已创建了一条记录，如下表所示。

Record	类型	TTL（秒）	数据
myrecord1.gcp.example.com	A	5	10.128.1.35

在公开地区中，您创建了两条记录。

Record	类型	TTL（秒）	数据
myrecord1.gcp.example.com	A	5	104.198.6.142
myrecord2.gcp.example.com	A	50	104.198.7.145

以下查询按照说明进行解析：

来自您的 VPC 网络中虚拟机的 myrecord1.gcp.example.com 查询返回 10.128.1.35。
来自互联网的 myrecord1.gcp.example.com 查询返回 104.198.6.142。
来自您的 VPC 网络中虚拟机的 myrecord2.gcp.example.com 查询返回 NXDOMAIN 错误，因为专用可用区 gcp.example.com 中没有 myrecord2.gcp.example.com 的记录。
来自互联网的 myrecord2.gcp.example.com 查询返回 104.198.7.145。

跨项目绑定

跨项目绑定允许您保留服务项目的 DNS 命名空间的所有权，而不是整个 VPC 网络的 DNS 命名空间的所有权。

典型的共享 VPC 设置具有能够获得虚拟机 (VM) 应用或服务所有权的服务项目，而宿主项目则获得 VPC 网络和网络基础架构的所有权。通常，DNS 命名空间是根据 VPC 网络的命名空间创建，以匹配服务项目的资源。对于此类设置，可以更轻松地将每个服务项目 DNS 命名空间的管理委派给每个服务项目（通常是不同的部门或业务）的管理员。通过跨项目绑定，您可以将服务项目的 DNS 命名空间的所有权与整个 VPC 网络的 DNS 命名空间的所有权分开。

下图展示了具有 DNS 对等互连的典型共享 VPC 设置。

使用 DNS 对等互连的共享 VPC 设置。 — 使用 DNS 对等互连的共享 VPC 设置（点击可放大）

下图展示了使用跨项目绑定的设置。Cloud DNS 允许每个服务项目创建并拥有其 DNS 区域，但仍将其绑定到宿主项目拥有的共享网络。这样可以实现更好的自主性，并让 DNS 区域管理具备更精确的权限边界。

跨项目绑定提供以下功能：

服务项目管理员和用户可以创建和管理自己的 DNS 区域。
您无需创建占位符 VPC 网络。
宿主项目管理员无需管理服务项目。
IAM 角色在项目级层仍然适用。
所有 DNS 区域都与共享 VPC 网络直接关联。
任何 DNS 解析都随时可用。共享 VPC 网络中的任何虚拟机都可以解析关联的可用区。
没有传递性跃点限制。您可以采用中心辐射式设计对其进行管理。

如需了解如何创建启用了跨项目绑定的可用区，请参阅创建跨项目绑定可用区。

可用区级 Cloud DNS 区域

可用区级 Cloud DNS 可让您创建范围限定为仅 Google Cloud 可用区的专用 DNS 区域。当您选择集群范围时，系统会为 GKE 创建可用区级 Cloud DNS 区域。

默认的 Cloud DNS 服务本质上是全球性的，并且 DNS 名称在 VPC 网络中全局可见。此配置会使您的服务受到全球服务中断的影响。可用区级 Cloud DNS 是存在于每个 Google Cloud 可用区中的新专用 Cloud DNS 服务。故障域包含在该 Google Cloud 可用区中。发生全球中断时，可用区级 Cloud DNS 专用可用区不受影响。任何 Google Cloud 可用区级服务中断仅影响该特定 Google Cloud 可用区及该 Google Cloud 可用区内的 Cloud DNS 区域。请注意，在可用区级服务中创建的任何资源都仅对该 Google Cloud 可用区可见。

如需了解如何配置区域级 Cloud DNS 集群级区域，请参阅配置区域级 GKE 集群级区域。

可用区级 Cloud DNS 支持

下表列出了可用区级 Cloud DNS 服务支持的 Cloud DNS 资源和功能。

资源或功能	适用于全球 Cloud DNS	适用于可用区级 Cloud DNS
代管式公开可用区
代管式专用可用区（网络或 VPC 范围）
代管式专用可用区（GKE 范围）
转发可用区¹
对等互连可用区
代管式反向查找可用区
创建更改或管理记录²
Service Directory 可用区
政策
响应政策（网络范围）
响应政策（GKE 集群范围）
响应政策规则

¹可用区级 Cloud DNS 仅支持范围限定为 GKE 集群的转发可用区。

²GKE 控制器在重启时会覆盖记录的所有更改。

可用区级 Cloud DNS 区域结算

可用区级 Cloud DNS 区域和响应政策的结算方式与其对应的全球 DNS 方案相同。

后续步骤

如需使用代管式区域，请参阅创建、修改和删除区域。
如需了解您在使用 Cloud DNS 时可能会遇到的常见问题的解决方案，请参阅问题排查。
如需大致了解 Cloud DNS，请参阅 Cloud DNS 概览。