DNS Is for People – Not for IT Infrastructure：内部基础设施为何应摒弃 DNS？

背景

域名系统（DNS）诞生的初衷非常朴素：人类难以记忆由数字组成的 IP 地址（如 185.15.59.224），却很容易记住人类可读的域名（如 wikipedia.org）。对于面向公众的互联网服务，使用 DNS 发布网站、API 端点或其他服务是合乎逻辑的。这不仅方便用户交互，还允许后端 IP 地址在客户端无感知的情况下进行变更。

然而，这篇文章并非反对在公共服务中使用 DNS，而是对一种普遍做法提出了质疑：我们是否应该将 DNS 用于内部 IT 基础设施？ 无论基础设施是部署在云端还是本地（on-prem），这一质疑都适用。作者认为，虽然 DNS 对公众有益，但在机器对机器（M2M）的内部通信场景中，它可能引入不必要的复杂性和风险。

核心内容

1. 可靠性悖论：组件越多，风险越大

从 IT 运维的角度来看，构建可靠系统的核心原则是尽量减少组件数量。每一个新增的组件都增加了潜在的单点故障风险，并可能引发不可预见的行为交互（如循环依赖），从而导致系统中断。

DNS 在 IT 运维领域有着“背锅”的恶名，正如网络社区流传的一首俳句所言：

不是 DNS
肯定不是 DNS
最后发现是 DNS

历史上多次高知名度故障事件（如 Facebook/Meta 的大规模宕机）表明，虽然根因往往不是 DNS 系统本身的代码错误，但由于 DNS 处于几乎所有服务的“关键路径”上，任何影响 DNS 的根因（如配置错误、缓存污染或物理访问控制依赖）都会导致巨大的爆炸半径（blast radius）。例如，Meta 的宕机部分原因就在于其对 DNS 的“循环依赖”导致员工无法物理进入数据中心。这种巨大的爆炸半径使得全面评估潜在风险变得极其困难。

2. 内部通信：DNS 并非必要

对于内部 IT 基础设施中的服务间通信，DNS 的优势并不明显，反而带来了维护痛点：

• 缓存与刷新问题：DNS 客户端通常基于 TTL（生存时间）缓存记录。不同客户端的实现行为各异，即使环境高度同质化，要确保所有服务器（客户端）立即使用更新后的 IP 地址，唯一的办法是强制刷新 DNS 缓存。
• 机器不需要域名：机器对机器的通信不需要人类可读的名称。相反，通过 Ansible 或 pyinfra 等配置管理工具，直接将正确的 IP 地址注入配置文件是更直接、更可控的方式。
• 替代方案 /etc/hosts：针对“运维人员也是人，使用域名便于排错”的反驳，作者指出 /etc/hosts 文件可以轻松通过配置工具进行大规模分发。这种方式既保留了域名的可读性，又无需运行 DNS 服务，且查询响应通常非常迅速。

3. 安全风险：DNS 作为攻击面

在内部基础设施中，DNS 引入了额外的安全维度：

• 缺乏加密：如今大多数网络流量默认加密或通过加密通道隧道传输，而 DNS 默认是不加密的。虽然内部网络常被视为“安全环境”，但 DNS 服务遭受攻击、数据包欺骗等仍具有破坏性。
• DNSSEC 的复杂性：虽然部署 DNSSEC 可以缓解部分安全问题，但这引入了新的管理负担和配置错误风险，增加了系统的复杂性层级。
• 出口数据外泄（Egress Exfiltration）：
  • 由于出口过滤（Egress Filtering）配置繁琐，许多组织省略了对“可信”系统的出站连接过滤。这为攻击者提供了便利。
  • 攻击者可以利用 DNS 协议进行数据外泄。任何 IP 协议都可以用于传输数据，包括 DNS。攻击者可以控制一个域名及其权威名称服务器，受害主机通过发起类似 sensitive_data.evil.domain 的 DNS 查询，将数据编码在子域名中发送到攻击者的服务器。
  • 即使受害主机无法直接连接攻击者的服务器，DNS 请求也会经过本地的转发 DNS 服务器并被转发出去。工具如 dnscat2 或 iodine 便利用了这一机制。
  • 建议：至少应禁止内部系统直接查询公共 DNS 记录。对于需要访问互联网服务（如更新服务器、API）的需求，应通过代理服务器并使用白名单域名来管理访问。

关键要点

• 减少组件以提升可靠性：内部基础设施应遵循“少即是多”的原则，避免引入 DNS 这样的额外组件，以减少故障点和不可预见的交互风险。
• 机器通信无需 DNS：内部服务间的通信可以直接使用 IP 地址，通过配置管理工具（如 Ansible）进行分发，无需依赖域名解析。
• /etc/hosts 是轻量级替代方案：通过集中管理 /etc/hosts 文件，可以在保留域名可读性的同时，消除对 DNS 服务的依赖。
• DNS 是内部安全盲区：默认不加密的 DNS 协议可能成为内部网络的安全短板，增加配置错误和管理负担。
• 防范 DNS 数据外泄：攻击者可利用 DNS 查询将敏感数据外传。建议实施严格的出口流量过滤，并通过代理服务器管理内部系统对互联网的访问，禁止直接查询公共 DNS。
• 权衡利弊：最终决策取决于组织的基础设施上下文、风险偏好以及组织结构。但在内部环境中，探索完全避免使用 DNS 以提高系统的稳健性是合理的。

意义与影响

这篇文章挑战了 IT 基础设施设计中根深蒂固的“一切皆 DNS”的思维定式。它提醒架构师和运维工程师，DNS 主要是为“人”设计的，而非为“机器”设计。

在云原生和微服务架构日益复杂的今天，内部服务间的通信量呈指数级增长。盲目依赖 DNS 可能导致：

1. 运维复杂度激增：处理 DNS 缓存一致性、刷新策略和故障排查消耗大量精力。
2. 安全面扩大：DNS 成为内部网络中一个未被充分监控和保护的协议层，可能被用于隐蔽的数据窃取。
3. 单点故障风险：内部 DNS 服务的故障可能导致整个内部服务网格的瘫痪，且排查难度极大。

实践建议：

• 在内部服务发现机制中，优先考虑基于 IP 的直接连接或轻量级的本地主机映射。
• 实施严格的网络出口策略，限制内部主机直接进行 DNS 查询，转而使用经过审计的代理或网关。
• 重新评估内部 DNS 服务的必要性，仅在确实需要动态域名解析或外部集成时才保留，否则应考虑移除以简化架构。

这一观点呼吁 IT 基础设施回归本质：为机器提供简单、直接、可控的连接方式，而非强加人类友好的抽象层。