本文简要介绍两种类型的加密DNS协议：基于HTTPS的DNS和基于TLS的DNS。这两个协议主要是解决DNS带来的隐私和中介篡改问题。 0×01 DNS安全和隐私 DNS设计在开始时没有考虑安全问题，因此大多数DNS查询都使用UDP传输，当然也可以使用TCP。这两种方法既不加密也不签名。这意味着中间人可以收听用户访问的域名，从而导致隐私泄露。另外，由于没有签名验证，中间人还可以篡改DNS返回的IP地址，导致用户访问钓鱼网站。后来，通过DNSSEC，引入了一种签名机制，以确保权威DNS服务器，DNS递归服务器和客户端不被篡改。但这仍然无法解决隐私问题。 事实上，没有认真对待隐私问题的原因有几个要点：首先，中间人肯定知道你想要访问的服务器的IP地址。在大多数情况下，我知道IP并知道网站是什么。其次，一些上层协议也将披露域名。不会提到纯文本HTTP。 TLS协议还具有服务器名称指示（SNI），其公开明文域名。 （注意：IETF TLS工作组目前正在探索草案《SNI Encryption in TLS Through Tunneling》，计划加密SNI）。第三，一些上层协议（例如TLS）可以识别DNS是否已被篡改，这使得签名DNS本身不那么重要。 [1] 但即使有上述三点，加密DNS数据也有明显的好处。首先，减少攻击面。其次，在用户请求DNS之后，没有必要访问它。例如，下面描述的子域名爆破，我们只对DNS数据本身感兴趣，而不访问其域名，因此加密DNS具有实际意义。 因此，本文将探讨基于HTTPS的TLS和DNS上的DNS。这两个协议目前仅限于用户客户端和DNS递归服务器之间的通信。截至2018年4月，递归服务器和权威服务器之间的通信超出了这两个协议的范围。也许递归服务器和权威服务器将包含在DNS over TLS协议中，但我没有听说有人实现它。 0×01两个协议 DNS over TLS的标准文档是RFC7858。文档简短易懂。客户端首先与递归服务器执行TLS握手，并且使用的TCP端口号是853.握手之后，DNS数据包作为TLS有效负载发送到DNS递归服务器。请求和已回答的消息的格式与普通的TCP over TCP消息格式相同。 基于HTTPS的DNS目前没有RFC文档。只有草案《DNS Queries over HTTPS》。该草案规定可以使用GET和POST方法。如果使用POST，则通常的UDP over UDP消息将作为HTTP正文发送，Content-Type将在HTTP标头中设置为application/dns-message。如果使用GET，则普通DNS over UDP消息在base64中编码，编码的字符串作为URL的dns参数发送。 一些供应商还支持JSON格式的DNS over HTTPS协议，例如Google和CloudFlare的DNS服务器。出于兼容性原因，CloudFlare选择在格式方面与Google保持一致。有关确切格式，请参阅Google文档或CloudFlare文档。 为了让用户记住，Google的DNS服务器是8.8.8.8和8.8.4.4，而CloudFlare的DNS服务器是1.1.1.1和1.0.0.1。 CloudFlare的DNS服务于2018年4月1日推出。他们声称因为我们的IP有4个1，所以它是4月1日。[2] 0×02子域爆破 我在C＃中编写了一个非常简单的子域爆破工具来演示基于HTTPS的DNS。 （仅用于技术讨论，请不要将其用于非法目的！）使用JSON格式的HTTPS over HTTPS，您可以从UI中选择服务器。纯字典搜索，字典是从dnsrecon项目复制而来的。 这个工具我只测试了Windows 10 + Visual Studio 2017 + .NET Framework 4.6.1。特别是，Windows 10之前的操作系统可能无法连接到https://1.1.1.1 我记得旧版本的Windows不支持IP地址作为证书的主题Alt Name，因此证书验证可能会失败。 该工具的地址：https://github.com/xiaoyinl/securedns 欢迎大家提交问题和公关。 0×03参考 [1]  RFC7626 - DNS隐私注意事项 [2] 宣布1.1.1.1:是最快，隐私优先的消费者DNS服务 [3]  DNS over TLS - Cloudflare Resolver [4]  DNS over HTTPS - Cloudflare Resolver *作者：tocttou