域名系统存在的原因是人们很难记住IP地址（185.15.59.224），而记住域名（wikipedia.org）要容易得多。对于可通过互联网访问的服务，使用DNS发布网站、API端点或类似服务是有意义的，因为人们必须与这些服务进行交互。域名的额外好处是，相关的IP地址可以更改而不影响客户。本文不是反对公共服务的DNS，而是质疑我们是否应该将DNS用于内部IT基础设施（无论是云还是本地）。 虽然DNS可以是一个非常有用的服务，但它也可能成为一个负担。如果你想要一个可靠的系统，你希望尽可能减少组件。每增加一个组件就会增加潜在故障的风险。此外，更多的组件可能会导致不可预见的行为和交互，这可能导致停机（循环依赖等）。如果可以避免增加组件，你将更有机会建立一个可靠的系统。 在IT运营领域，DNS已经有了一定的名声。许多人可能还记得这首小俳句。 它不是DNS 绝对不是DNS 是DNS 有多个高调事件与DNS有关。在这些相关案例中，事件的根本原因并不是DNS系统本身。然而，由于根本原因影响了DNS服务——这是几乎所有服务的关键路径——事件的影响非常巨大。Facebook/Meta的故障之所以如此显著，是因为它由于依赖DNS而锁住了人们进入建筑物（物理访问）。再次可以说，循环依赖是根本原因，但在许多情况下，DNS的爆炸半径是如此之大，以至于很难对潜在风险有清晰的端到端图景。 反对在内部IT基础设施中使用DNS 从IT运营的角度来看，DNS有一个缺点：DNS客户端根据TTL缓存DNS记录。不同的DNS客户端实现可以表现不同，但即使你有一个相对同质的环境，确保客户端（在这个时候是其他服务器）使用更新的IP地址的唯一方法就是控制它们并强制DNS刷新。这让我思考，为什么我们要在基础设施服务中使用DNS？这对于机器之间的通信并非必需。我们可以直接将适当的IP地址注入配置文件，而不是配置可能无法解析的域名。使用像Ansible或pyinfra这样的工具大规模配置系统是非常简单的。 反方的论点可以是DevOPS/平台工程师也是人，配置域名比配置IP地址更容易发现错误配置或排除故障。幸运的是，我们仍然可以轻松配置/etc/hosts。这样就不需要DNS服务了！通过这种方式，我们可以配置域名并假装使用DNS。我也怀疑对/etc/hosts的DNS查询反应相当迅速。 作为一般安全风险的DNS 截至目前，大多数网络流量默认是加密的，或通过加密通道进行隧道传输。DNS - 默认情况下 - 是例外。关于内部IT基础设施（云或'本地'），网络可能被视为安全环境。然而，对DNS服务的攻击、伪造数据包等可能非常具有破坏性。设置DNSSEC可能会缓解这个问题，但这也引入了另一个管理负担，增加了自身错误配置的风险。这又是一个复杂性层次。而我们假设内部基础设施支持DNSSEC。 作为出口渗透风险的DNS 由于出口过滤（过滤出站连接）可能麻烦，它通常会被省略，因为相关系统是“受信任的”。这很不幸，因为这使攻击者更容易下手。攻击所需的任何资源都可以通过向互联网发送一个简单的出站查询来在脆弱的系统上获得。适当的网络流量出口过滤可以是成功和不成功的黑客攻击尝试之间的区别。缺乏出口过滤也使攻击者更容易渗透数据。问题是：任何IP协议都可以用来提取数据，包括DNS。这就是方式：攻击者获取一个域名，为此域名运行其互联网可访问的权威名称服务器。现在，攻击者可以从被黑系统向该域名发送DNS请求，例如：sensitivedata.evil.domain，并且你可以从流氓DNS服务器日志中提取所有数据。虽然被黑的服务器可能无法与攻击者控制的DNS服务器直接交互，但通过发起对攻击者控制的域名的DNS请求，这些请求将通过本地转发DNS服务器并被转发到攻击者控制的权威DNS服务器。参见dnscat2或iodine等工具。