今天，基于 TLS/HTTPS 的 DNS 的主要目的可能是绕过基于 DNS 的对被认为有害的网站的阻止，这些网站可能包括 Google、Youtube、Facebook ……取决于您所在的位置。基于 DNS 的阻止既简单又便宜，因为大多数用户使用 ISP 提供的 DNS 服务器，它可以简单地为被阻止的域返回不同的响应。即使用户明确配置了不同的公共 DNS 服务器，ISP 也可以创建廉价的数据包过滤规则，以便任何到端口 53 (DNS) 的流量都由 ISP 的 DNS 服务器透明地处理，即使用户尝试使用不同的服务器也是如此。虽然理论上 DNSSec 允许授权的 DNS 回答，但它并未用于大部分域，这也意味着客户端通常不会强制执行它。

如果用户改为使用基于 TLS 或 HTTPS 的 DNS，则端口 53 的简单重定向将不再起作用，因为 ISP 没有这些 TLS 连接的匹配证书。虽然 ISP 可以简单地阻止端口 853（基于 TLS 的 DNS）上的任何流量，希望客户端回退到正常的 DNS，但是阻止基于 HTTPS 的 DNS 不能没有严重的副作用，因为它使用相同的端口（443）和甚至可能与正常的 HTTPS 网络流量相同的目的地（内容交付网络）。

这意味着为了阻止站点，ISP 必须依靠 DPI（深度数据包检测）从Host标头（纯 HTTP）或 TLS 握手 (HTTPS) 中的 SNI 中提取目标，然后阻止流量。这比简单的第 4 层（基于端口）重定向要昂贵得多，并且还会影响流量的性能。这使得 ISP 游说团体更有可能反对封锁，尤其是在 ISP 必须自己承担所有额外费用的情况下。

此外，提议的加密 SNI意味着即使 DPI 也无法可靠地帮助找出访问过的站点，因此基于域名阻止站点将无法可靠地工作。

老实说，如果您不使用代理直接连接到站点（例如，TOR 或 VPN 都是代理，但具有不同的安全隐私级别），那么您在 ISP 级别的隐私就会受到威胁，并且每个代理也应该使用安全 DNS。

使用安全 DNS 隐含的威胁是什么？
答案是：同样会影响 TLS/SSL 或任何其他分层服务中的 Web 浏览。
威胁存在于与使用的服务相关的加密流量中（实际上，您应该在入站和出站连接中接受流量之前解密和验证流量），但主要是在所有传输会话期间以安全的方式建立和维护加密级别：
一旦验证和执行身份验证和加密过程，TLS/SSL 应该防止流量注入，这是安全层最终提供的最有用的功能。