最系统的答案是在您的基础设施中实施水平分割 DNS，这样只有内部地址才能解析；然后客户端必须使用代理服务器连接到互联网，代理服务器为他们解析外部 DNS。如果您的核心网络没有默认路由，这将特别有效，以便丢弃发往您网络之外的数据包。

显然，不利的一面是，将这些控件改装到运行环境中可能是一项昂贵且复杂的提议……

不记得名字了，但我知道至少有一种商业产品使用端口 53 给家里打电话（虽然不是完整的 TCP/IP 隧道）。

我会认真质疑通过尝试阻止特定的出站流量来阻止这种事情的（f）效用。防火墙从未打算以这种方式过滤出站流量、隧道、隐蔽通道等。只要允许通信，人们就会找到一种方法——HTTP(s) 是显而易见的手段，但人们甚至使用电子邮件作为传输构建了概念验证的完整 TCP/IP 堆栈。

也许你可以通过监控异常流量来检测这种事情，但这对我来说似乎是次要的问题。直接解决引发关注的主要问题可能是更好地利用资源 - 例如恶意软件或数据泄漏。

我意识到这是一个老问题，但我只是遇到了它，并认为我会为了下一个人而发表我的观点。

最佳答案是caelyx 的回应：构建网络，以便只有代理可以解析外部 DNS 主机名。正如他所指出的，将其改装到生产环境中是很困难的。

一个折衷方案是阻止所有 udp/53 出站，除非它源自您的内部 DNS 服务器和/或只允许您的外部 DNS 服务器。这减轻了简单地将数据通过 udp/53 扔到任意外部服务器的应用程序。它不会降低 DNS 隧道的风险，因为您的内部和外部 DNS 服务器会很高兴地转发任何符合 RFC 的流量。

我在 2009 年对此进行了研究，并将我的发现发布在armatum.com 上。第一篇文章是描述“常规”DNS 流量并与典型的 DNS 隧道实现进行比较。第二阶段是建立一个算法来检测异常行为；它最初是一种聚类算法，最终是关键特征的简单可视化：

（点击观看视频，查看应用程序实时运行）这些关键特征最终集中在查询的主机名长度、请求类型和请求的主机名中的唯一字符数。大多数符合 RFC 的 DNS 隧道实现最大化这些值以最大化上行带宽，从而显着增加典型 DNS 流量的值。

正如我在第二篇文章的更新中所指出的，如果我今天要重新做这项工作，我会包括自那以后发表的研究，并且还会使用每个域的子域计数作为关键特征。这是一个聪明的技术。

基于我担任该角色的多年，我将其构建为我想要在企业网络外围使用的工具。据我所知，没有企业级的行业应用程序/硬件可以提供这种深度的洞察力。最常见的是确保 RFC 合规性的“应用程序级防火墙”——您可以（通常）使用上述更简单的拆分 DNS 网络架构强制执行。

值得注意的是，我已经看到 TXT 响应记录在大型（450k 主机）企业范围内被彻底禁止，但效用没有显着降低。您的邮件网关需要 SPF 的 TXT 记录，但其他常见用途在企业中很少占有一席之地。我不提倡这种方法，因为它“破坏了互联网”——但在可怕的情况下，我无法反驳它的实用性。

最后，是的——我见过这种技术在现场使用，尽管它很不寻常。（指企业，不是按使用付费的公共接入点）

我已经看到了这种情况。

它主要由廉价的极客使用，以避免为公共无线付费。他们所做的是在家里设置一个服务器，一个假的 DNS，或者只是一个随机的 VPN。当他们外出时，他们可能必须连接到互联网，所以他们寻找任何开放的无线并连接，如果它想要你付费，那么你尝试连接到你的假 DNS 服务器和 tada，免费互联网 :)。我已经在“现实世界”中看到了这一点。

这也适用于 ICMP 或更称为 PING，您可以在客户端和家庭服务器之间创建一个 ping 隧道并以这种方式发送数据。

但是，如果您在办公室 LAN 之类的“开放”网络上看到此内容，则可能存在某种类型的恶意软件或类似的恶意软件，它们不想让您弄乱它。如果是这种情况，那么我建议你看看它。