DNS 被视为商品基础设施：您指出名称服务器、配置 A 记录和 MX 记录，然后就不用管它了。 Cloudflare 对代理记录所做的事情打破了这个前提 - 协议仍然存在，但是当您打开代理模式时会发生什么，会改变 DNS 在您的架构中的含义。
代理记录时会发生什么变化
当您在 Cloudflare 中创建 A 记录并启用代理（橙色云图标）时，您的客户端在 DNS 响应中收到的 IP 地址不是您的源 IP。 Cloudflare 返回自己的 IP 之一，该地址属于该公司的选播网络，分布在全球 300 多个接入点。
到达该域的每个 HTTP 和 HTTPS 请求在到达您的服务器之前都会进入 Cloudflare 网络。 TLS 在距离客户端最近的 PoP 处终止。 WAF 检查请求。应用速率限制规则。查阅缓存。 DDoS 缓解在边缘发挥作用。只有这样，如果请求已通过所有这些层，它才会通过 Cloudflare 的内部网络以单独的连接转发到其源。您的服务器的真实 IP 地址对任何外部客户端都是隐藏的。
在此模型中，DNS 是整个安全和性能链的入口点，而不是其之前的服务。
任播：为什么 300 个 PoP 对延迟很重要
大多数网络都采用单播路由运行——每个 IP 都是从一个位置发布的，数据包会全程传输到该数据中心，无论客户身在何处。
Cloudflare 网络与选播配合使用：通过 BGP 从 300 多个存在点中的每一个同时宣布相同的 IP 地址块。当客户在 DNS 响应中收到 Cloudflare IP 时，互联网的 BGP 基础设施会将数据包路由到地理位置最近的 PoP。 TLS 在那里终止，距客户端仅几毫秒。到达其源头（可能位于世界另一个地区）的路线通过 Cloudflare 的专用网络进行，PoP 之间具有优化的路线，最终用户不可见。
传播、TTL 以及权威与递归的分离
Cloudflare 的 DNS 产品中同时存在两个不同的角色，混淆它们会导致在发生事件时产生不正确的期望。权威服务 - 当您将您的域名委托给 Cloudflare 的域名服务器时 - 将对您的记录进行权威响应。 1.1.1.1 是一个公共递归解析器，是代表客户端查询权威服务器的独立服务。您可以在您的域中使用 Cloudflare 域名服务器，而无需使用 1.1.1.1，反之亦然。
当您更改 Cloudflare 仪表板中的记录时，更改会在大约 30 秒内通过权威网络传播 - 对于那些来自需要数小时才能更新区域的提供商的人来说，这个数字令人印象深刻。问题在于，影响真实用户的“传播”取决于另一层：递归解析器。
Google 的 8.8.8.8 等解析器和 ISP 解析器通过注册表的 TTL 缓存响应。如果解析器发出查询时 TTL 为 3600 秒，它将继续使用旧值响应长达一个小时 — 即使 Cloudflare 已经提供新记录 30 秒。向所有客户端的“完全传播”恰好采用更改时有效的最大 TTL。
Cloudflare 上非代理注册的默认 TTL 为 300 秒。无论内部值如何，代理记录始终向外部公开 300 秒的 TTL — Cloudflare 需要这种灵活性来管理自己的任播 IP。在任何计划的更改（源迁移、故障转移、IP 轮换）之前，正确的程序是提前将 TTL 减少到 60 或 300 秒，等待解析器更新缓存，执行更改，然后提高 TTL。以相反的顺序进行意味着在成本较高时要缓慢传播。
CNAME 扁平化和顶点问题
最初的 DNS 规范禁止在域顶端使用 CNAME（0 本身没有子域），因为它与所需的 SOA 和 NS 记录冲突。多年来，这迫使团队在根域的 A 记录中固定 IP，从而与不保证静态 IP 的服务产生摩擦：AWS 中的负载均衡器仅公开 DNS 名称，而不公开 IP。
Cloudflare 通过 CNAME 扁平化解决了这个问题。当您为 apex 配置 CNAME 时，Cloudflare 会实时解析目标（在请求时查询目标的 A 和 AAAA）并将这些 IP 直接返回给客户端。从外部解析器的角度来看，这是一条普通的A记录。
这对生产管理人员有何要求
将 DNS 视为静态配置的团队在 Cloudflare 上操作时会遇到特定问题。每个注册表的代理模式（打开或关闭）决定了边缘安全和性能系统是否妨碍。禁用代理的 A 记录会暴露源的真实 IP，使 DDoS 防护失效，并从流中删除 WAF。审核哪些记录被代理，哪些未被代理，不是初始实施任务；需要成为变更审核流程的一部分。
TTL 值得持续关注。高 TTL 可减少权威负载并改善解析器中的缓存，但会增加路由更改的恢复时间。 MX 等关键记录和内部服务子域之间的传播时间容差通常有所不同，并且这种差异应该在区域设置中明确显示。
在注册表更改期间主动监控传播可以防止出现意外。像 1 这样的工具显示了世界各地不同解析器此时返回的内容。当更改已完成但用户仍然报告访问失败时，可能的原因是长期缓存的解析器 - 答案是等待 TTL 过期，而不是在顶部堆叠另一个记录更改。
另请阅读
- [Cloudflare 负载均衡和地理转向：当 DNS 成为智能流量层2
- [DNSSEC 与 Cloudflare：它保护什么、不保护什么以及如何顺利激活3
- [Cloudflare 电子邮件路由：在您的域上接收电子邮件 - 以及不包括的内容44
- [DNS 迁移到 Cloudflare：避免三小时停电的清单5
- [DNS 代理与仅 DNS：有何变化以及每种模式何时有意义6?
- [Cloudflare Durable Objects：边缘的一致状态 - 真正改变的是什么77