Cloudflare 内部 DNS 现在正式上线
今天起，Cloudflare 内部 DNS 正式上线。Cloudflare 内部 DNS 为同一全球网络上的私有网络提供权威和递归 DNS，与用户已经使用的公共 DNS、零信任、网络和应用服务的控制平面相同。
内部 DNS，有时也称为私有 DNS，是企业基础设施中最后几个仍然与网络其他部分分开管理的部分之一。许多组织为公共 DNS 操作一个平台，为内部 DNS 操作另一个平台，并在每个云环境中使用支持云的 DNS 服务，且在这些服务上层叠加不同的安全策略。这些系统之间没有共享的控制平面。拆分视图 DNS 增加了复杂性，通常要求多个 DNS 环境保持同步，以便内部用户和外部用户在相同的主机名下接收不同的回答。当这些系统偏离时，就会出现故障。
使用 Cloudflare 内部 DNS，您可以获得一个单一的平台来管理公共和私有 DNS 资源，强制执行 [DNS 策略](https://developers.cloudflare.com/cloudflare-one/traffic-policies/dns-policies/) 并获得对整个 DNS 堆栈的可见性。对于企业客户，该服务包含在 [Cloudflare Gateway](https://www.cloudflare.com/products/gateway/) 中，无需额外收费。
## 客户为何选择内部 DNS
**整合 DNS 操作**。公共和私有 DNS 在一个平台上运行，使用一个 API、一个审计跟踪，以及一个设置策略的地方。传统 DNS 的设备更新周期和扩展瓶颈将不再存在。
**简化拆分视图 DNS**。内部和外部解析被定义为共享区域上的独立视图，从单一控制平面管理。没有并行系统需要同步，因此不会出现偏差。
**将零信任扩展到 DNS**。解析器策略决定哪些用户和设备将使用哪个视图，这一点由同一的 Cloudflare Gateway 强制执行，它已经管理您其余的流量。私有名称解析不再成为整体零信任架构中的漏洞。
**现代化传统基础设施**。淘汰硬件设备、传统 DNS 服务器和云锁定解析器。Cloudflare 内部 DNS 运行在 1.1.1.1 背后的基础设施上，无需机架硬件，也无需准备容量。
## 我们构建了什么
Cloudflare 内部 DNS 包含两个组件：**网关解析器**和 **内部权威 DNS**。权威管理区域的工作与强制执行 DNS 安全和路由策略是不同的。
网关解析器处理递归解析和策略评估。[2020年上线](https://blog.cloudflare.com/introducing-cloudflare-for-teams/) 的它由 1.1.1.1 提供公共解析支持，并配备内置的策略引擎，能够过滤 DNS 查询并根据 [灵活表达式](https://developers.cloudflare.com/cloudflare-one/traffic-policies/expression-syntax/) 将查询重定向到不同的上游来源，所有这些都配备全面的日志记录和审计，形成一个统一的视图。
内部权威 DNS 为在 Cloudflare 运营十多年的相同权威平台上构建的内部区域提供记录，该平台的 [域名数量](https://w3techs.com/technologies/overview/dns_server) 超过任何其他提供者。
客户主要处理三种对象：
- **内部区域**：保存私有资源的权威记录：特定环境的应用、服务端点、数据库。
- **DNS 视图**：将区域分组以供特定用户或设备看到的解析上下文。这使得拆分视图无需并行系统。
- **解析器策略**：在网关中，路由匹配查询到特定的视图。
区域引用使管理员能够在多个视图中重用共享区域，而不必在每个视图中复制记录。像 intranet.local 这样的公共区域只需定义一次，并在需要的地方引用，这与通常强制的拆分视图配置的重复、容易漂移的设置形成鲜明对比。
### 查询如何解析
来自客户端的 DNS 查询首先到达网关解析器，进行策略评估。此后，会发生三种情况中的一种。如果解析器策略匹配并指向内部视图，查询将被路由到内部权威 DNS，并从匹配视图的区域中回答。如果政策阻止查询，则在解析器处被丢弃。否则，查询将遵循公共路径，由 1.1.1.1 根据公共 DNS 层次结构解析。视图还可以在未找到内部名称时退回到公共解析，因此一个解析器可以同时服务于私有和公共名称，而客户端不需要知道是哪一个。
### 更改如何传播
记录更改遵循可预测的高速路径，从输入到边缘。
每次更改都通过相同的 DNS 记录 API 进入，无论是来源于仪表板、Terraform 还是直接的 API 调用。这种统一的入口意味着无论如何更改，总有一条可审核的写入路径可供考量。更改在 Cloudflare 核心数据中心持久化以保证持久性，并在传播之前进行验证。
随后，变更在 Cloudflare 的全球网络上同步，受影响的缓存条目在更新到达时被失效，因此编辑过的记录在数秒内生效，而不是等待 TTL 过期。
### 开始使用
如果您是使用 Cloudflare Gateway 的企业客户，今天即可访问内部 DNS。打开 Cloudflare 仪表板，导航到网络，然后进入 [内部 DNS](https://dash.cloudflare.com/?to=/:account/internal-dns)。
设置内部 DNS 通常需要三个步骤：创建区域、创建视图和定义解析器政策，以决定哪些用户和设备应根据该视图解析。
创建一个内部区域及您的第一个内部记录：
然后创建一个 DNS 视图并将您的区域链接到它：
最后，在 [零信任仪表板](https://dash.cloudflare.com/?to=/:account/one/traffic-policies/resolver-policies) 中 [创建一个网关解析器策略](https://developers.cloudflare.com/cloudflare-one/traffic-policies/resolver-policies/#create-a-resolver-policy)，路由匹配流量到您的视图。创建一个网关位置，设定条件，选择内部 DNS 视图作为解析方法，并选择您的视图。就这样。匹配您的政策的查询现在将针对您的内部区域解析。
Terraform 支持可用，因为 Terraform 通过与其他所有内容相同的 DNS 记录 API 写入，基础设施即代码的更改遵循相同的摄取和传播路径。完整文档和端到端配置示例可在 [我们的开发者文档](https://developers.cloudflare.com/dns/internal-dns/get-started/#manage-with-terraform) 中找到。
### 内部 DNS 作为连接云的一部分
内部 DNS 适用于任何通过网关解析器路由 DNS 流量的 Cloudflare 连接方法，包括 Cloudflare One 客户端（前身为 WARP）、HTTPS 上的 DNS（DoH）、TLS 上的 DNS（DoT）、标准 DNS（端口 53）、PAC 文件部署，以及 Cloudflare WAN。
对于运行 Cloudflare WAN 的组织，连接网络上的每个设备都可以通过 Cloudflare 解析内部主机名，而无需在各个设备上要求 Cloudflare One 客户端。结果是，使用单一控制平面，远程用户、分支机构、数据中心和云环境之间提供一致的 DNS 体验。
更重要的是，内部 DNS 不是一个独立的 DNS 服务。它扩展了组织已经在使用的相同连接云平台，以确保用户安全，通过 Cloudflare WAN 连接网络，加速应用程序，并保护面向互联网的服务。
将私有 DNS 引入与其他内容相同的全球网络仅仅是起点。DNS、网络和零信任政策之间的更紧密集成是未来的发展方向——因此，解析内部主机名、到达其背后的服务以及强制执行谁可以访问这些服务的决策，都将通过一个单一平台做出，而不是多个不相连的系统。
准备好整合您的 DNS 了吗？打开仪表板，前往网络，然后创建您的第一个区域 [内部 DNS](https://dash.cloudflare.com/?to=/:account/internal-dns)。有问题或者想和其他运营者交流经验吗？加入 [Cloudflare 社区](https://community.cloudflare.com)。
---
原文链接：[点击查看](https://blog.cloudflare.com/internal-dns/)
内部 DNS，有时也称为私有 DNS，是企业基础设施中最后几个仍然与网络其他部分分开管理的部分之一。许多组织为公共 DNS 操作一个平台，为内部 DNS 操作另一个平台，并在每个云环境中使用支持云的 DNS 服务，且在这些服务上层叠加不同的安全策略。这些系统之间没有共享的控制平面。拆分视图 DNS 增加了复杂性，通常要求多个 DNS 环境保持同步，以便内部用户和外部用户在相同的主机名下接收不同的回答。当这些系统偏离时，就会出现故障。
使用 Cloudflare 内部 DNS，您可以获得一个单一的平台来管理公共和私有 DNS 资源，强制执行 [DNS 策略](https://developers.cloudflare.com/cloudflare-one/traffic-policies/dns-policies/) 并获得对整个 DNS 堆栈的可见性。对于企业客户，该服务包含在 [Cloudflare Gateway](https://www.cloudflare.com/products/gateway/) 中，无需额外收费。
## 客户为何选择内部 DNS
**整合 DNS 操作**。公共和私有 DNS 在一个平台上运行，使用一个 API、一个审计跟踪，以及一个设置策略的地方。传统 DNS 的设备更新周期和扩展瓶颈将不再存在。
**简化拆分视图 DNS**。内部和外部解析被定义为共享区域上的独立视图，从单一控制平面管理。没有并行系统需要同步，因此不会出现偏差。
**将零信任扩展到 DNS**。解析器策略决定哪些用户和设备将使用哪个视图，这一点由同一的 Cloudflare Gateway 强制执行，它已经管理您其余的流量。私有名称解析不再成为整体零信任架构中的漏洞。
**现代化传统基础设施**。淘汰硬件设备、传统 DNS 服务器和云锁定解析器。Cloudflare 内部 DNS 运行在 1.1.1.1 背后的基础设施上，无需机架硬件，也无需准备容量。
## 我们构建了什么
Cloudflare 内部 DNS 包含两个组件：**网关解析器**和 **内部权威 DNS**。权威管理区域的工作与强制执行 DNS 安全和路由策略是不同的。
网关解析器处理递归解析和策略评估。[2020年上线](https://blog.cloudflare.com/introducing-cloudflare-for-teams/) 的它由 1.1.1.1 提供公共解析支持，并配备内置的策略引擎，能够过滤 DNS 查询并根据 [灵活表达式](https://developers.cloudflare.com/cloudflare-one/traffic-policies/expression-syntax/) 将查询重定向到不同的上游来源，所有这些都配备全面的日志记录和审计，形成一个统一的视图。
内部权威 DNS 为在 Cloudflare 运营十多年的相同权威平台上构建的内部区域提供记录，该平台的 [域名数量](https://w3techs.com/technologies/overview/dns_server) 超过任何其他提供者。
客户主要处理三种对象：
- **内部区域**：保存私有资源的权威记录：特定环境的应用、服务端点、数据库。
- **DNS 视图**：将区域分组以供特定用户或设备看到的解析上下文。这使得拆分视图无需并行系统。
- **解析器策略**：在网关中，路由匹配查询到特定的视图。
区域引用使管理员能够在多个视图中重用共享区域，而不必在每个视图中复制记录。像 intranet.local 这样的公共区域只需定义一次，并在需要的地方引用，这与通常强制的拆分视图配置的重复、容易漂移的设置形成鲜明对比。
### 查询如何解析
来自客户端的 DNS 查询首先到达网关解析器，进行策略评估。此后，会发生三种情况中的一种。如果解析器策略匹配并指向内部视图，查询将被路由到内部权威 DNS，并从匹配视图的区域中回答。如果政策阻止查询，则在解析器处被丢弃。否则，查询将遵循公共路径，由 1.1.1.1 根据公共 DNS 层次结构解析。视图还可以在未找到内部名称时退回到公共解析，因此一个解析器可以同时服务于私有和公共名称，而客户端不需要知道是哪一个。
### 更改如何传播
记录更改遵循可预测的高速路径，从输入到边缘。
每次更改都通过相同的 DNS 记录 API 进入，无论是来源于仪表板、Terraform 还是直接的 API 调用。这种统一的入口意味着无论如何更改，总有一条可审核的写入路径可供考量。更改在 Cloudflare 核心数据中心持久化以保证持久性，并在传播之前进行验证。
随后，变更在 Cloudflare 的全球网络上同步，受影响的缓存条目在更新到达时被失效，因此编辑过的记录在数秒内生效，而不是等待 TTL 过期。
### 开始使用
如果您是使用 Cloudflare Gateway 的企业客户，今天即可访问内部 DNS。打开 Cloudflare 仪表板，导航到网络，然后进入 [内部 DNS](https://dash.cloudflare.com/?to=/:account/internal-dns)。
设置内部 DNS 通常需要三个步骤：创建区域、创建视图和定义解析器政策，以决定哪些用户和设备应根据该视图解析。
创建一个内部区域及您的第一个内部记录：
然后创建一个 DNS 视图并将您的区域链接到它：
最后，在 [零信任仪表板](https://dash.cloudflare.com/?to=/:account/one/traffic-policies/resolver-policies) 中 [创建一个网关解析器策略](https://developers.cloudflare.com/cloudflare-one/traffic-policies/resolver-policies/#create-a-resolver-policy)，路由匹配流量到您的视图。创建一个网关位置，设定条件，选择内部 DNS 视图作为解析方法，并选择您的视图。就这样。匹配您的政策的查询现在将针对您的内部区域解析。
Terraform 支持可用，因为 Terraform 通过与其他所有内容相同的 DNS 记录 API 写入，基础设施即代码的更改遵循相同的摄取和传播路径。完整文档和端到端配置示例可在 [我们的开发者文档](https://developers.cloudflare.com/dns/internal-dns/get-started/#manage-with-terraform) 中找到。
### 内部 DNS 作为连接云的一部分
内部 DNS 适用于任何通过网关解析器路由 DNS 流量的 Cloudflare 连接方法，包括 Cloudflare One 客户端（前身为 WARP）、HTTPS 上的 DNS（DoH）、TLS 上的 DNS（DoT）、标准 DNS（端口 53）、PAC 文件部署，以及 Cloudflare WAN。
对于运行 Cloudflare WAN 的组织，连接网络上的每个设备都可以通过 Cloudflare 解析内部主机名，而无需在各个设备上要求 Cloudflare One 客户端。结果是，使用单一控制平面，远程用户、分支机构、数据中心和云环境之间提供一致的 DNS 体验。
更重要的是，内部 DNS 不是一个独立的 DNS 服务。它扩展了组织已经在使用的相同连接云平台，以确保用户安全，通过 Cloudflare WAN 连接网络，加速应用程序，并保护面向互联网的服务。
将私有 DNS 引入与其他内容相同的全球网络仅仅是起点。DNS、网络和零信任政策之间的更紧密集成是未来的发展方向——因此，解析内部主机名、到达其背后的服务以及强制执行谁可以访问这些服务的决策，都将通过一个单一平台做出，而不是多个不相连的系统。
准备好整合您的 DNS 了吗？打开仪表板，前往网络，然后创建您的第一个区域 [内部 DNS](https://dash.cloudflare.com/?to=/:account/internal-dns)。有问题或者想和其他运营者交流经验吗？加入 [Cloudflare 社区](https://community.cloudflare.com)。
---
原文链接：[点击查看](https://blog.cloudflare.com/internal-dns/)
评论
暂无评论。