DNS 本意是为人类服务的——记住「wikipedia.org」比记住「185.15.59.224」容易得多。但作者 Louwrentius 认为，这套逻辑不应照搬进内部 IT 基础设施：机器之间的通信根本不需要域名，直接配 IP 更可靠。
DNS 的隐性代价
DNS 看似简单，实则是高风险单点。一旦出问题，由于几乎所有服务都依赖它做名称解析，宕机影响范围会被极度放大。Facebook 2021 年的大规模故障甚至导致员工被锁在办公楼外，正是因为物理门禁系统也依赖 DNS——这不是 DNS 本身的缺陷，而是「环形依赖」让 DNS 的爆炸半径变得难以估量。
对内部服务而言，DNS 还有个独特麻烦：客户端按 TTL 缓存记录。即使运维人员更新了 IP，不同系统的缓存失效时间不一致，可能导致部分节点访问到旧地址。想保证所有服务器实时生效？只能手动触发刷新，又走回了「控制客户端」的老路。
安全风险与泄密隐患
DNS 还有一个常被忽视的问题：数据泄露。攻击者只需注册一个域名、运行自己的权威 DNS 服务器，就能让被入侵的服务器发送类似「sensitivedata.evil.domain」的查询——查询内容就是待窃取的数据。这些 DNS 请求会经由内网 DNS 服务器转发，最终抵达攻击者的服务器。工具如 dnscat2 和 iodine 正是利用这一通道。
更棘手的是出站过滤——因为维护麻烦，许多内网环境直接放行了所有对外连接，等于给攻击者开了后门。作者建议，至少不要让服务器直接查询公共 DNS，改为通过白名单域名的代理服务器访问外部资源。
替代方案：/etc/hosts 与直连 IP
作者并不反对公网服务用 DNS，但建议重新审视内部场景：直接用 Ansible 或 pyinfra 把 IP 地址注入配置文件，省去 DNS 依赖层；想保留域名可读性的话，/etc/hosts 同样支持域名解析，查询还更快。
当然，域名在排障时更直观易读，这也是真实价值。最终还是权衡问题——但至少值得认真评估：内网基础设施能否彻底去掉 DNS，以换取更高的可靠性和更小的攻击面。
编注：信源为技术博客，材料为长文论述，系统性分析 DNS 在内网的利弊；未涉及具体故障案例细节与行业数据对比。