前言
就互联网协议而言，我认为DNS协议是一个伟大的成功案例。DNS协议是为不同于我们今天的互联网而创建的，它假设运行在更友好的、和谐的互联网上，没有放大DDoS攻击，MITM攻击和DNS欺骗。总体而言，原始形式的DNS协议存活得很好，其中也包括小众的协议比如EDNS 0和DNSSEC（几乎没有人使用）。
但最近，特别是由于更多隐私的需要以及更加大胆、不受管制的数据交易ISP的参与，我们需要更多的隐私权。此外，DNSSEC未能获得广泛的领导力，导致其他更简单的想法提供甚至替代了DNSSEC的大部分优秀特性。
在本文中，我想突出说明在DNS流量中正在出现的两个改变：
1 - DNS cookies
DNS cookies已经在RFC 7873中引入。它们试图解决DNSSEC试图解决的许多问题（比如缓存毒化问题），并且它们正在解决诸如DNSSEC无法阻止的欺骗性DNS放大攻击等问题。在某些情况下，DNSSEC可能会使这些攻击变得更糟。为了获得全面的“胜利”：DNS cookies比DNSSEC更容易实现。 DNS cookies提供的安全性应该与使用TCP替代UDP获得的安全性相似。要成功欺骗TCP，攻击者需要猜测32位序列号。 DNSSEC更难以猜测破解，所以DNS cookies安全性不如DNSSEC。但DNS cookies已经“足够”了。
那么DNS cookies是怎样工作的？
发送DNS请求的客户端将附加一个cookie选项。该cookie是客户端IP、服务器IP和一个secret的hash值。所以服务器会接收来自特定客户端的一致的cookie。 secret应该至少有64位长。只要cookie与特定的服务器/客户端一致，细节就无关紧要。
服务器cookie使用服务器IP地址、客户端cookie以及只有服务器才知道的secret。客户端IP由于NAT可能无法确定，所以使用客户端cookie代替客户端IP。这可以再一次保证服务端/客户端的一致性。
支持cookie的客户端发送的所有请求都包含cookie。这“应该”不会引起任何问题。不支持的选项将被忽略。但是，过去有些测试表明，存在不合规的DNS服务器可能会拒绝该请求。几年前的这个测试表明，10％的名称解析服务器存在问题。不知道现在是什么情况，但是比例应该已经减小很多了。
如果过去与此服务器通信过，客户端将包含服务器的cookie。
一旦服务器收到客户端cookie的请求，下面的一种情况可能发生：
1. 如果服务器不支持cookie，那么它会像普通模式一样忽略cookie。
2. 如果服务器确实支持cookie，并且客户端仅发送了一个包含客户端cookie的请求，那么服务器将响应，但它可能只包括除服务器cookie。现在，客户端可以重新发送查询并包含服务器cookie。服务器发送完整的响应，并针对无服务器cookie的请求使用不同的速率进行限制。对于不包含cookie的TCP请求，服务器也可能更加宽松。
3. 如果客户端包含服务器cookie，并且cookie是真实的，那么服务器将发送响应。
对于格式错误的cookie，会返回错误（FORMERR）。包含无效服务器cookie的请求被视为根本不包含服务器cookie的请求。此功能允许客户端在IP地址更改时或者服务器重新启动并选择新secret时DNS cookie机制自动恢复。
DNS cookies已经在BIND 9.11中实现。如果您安装了Ubuntu 18.04 LTS，您可能看到BIND使用它们。在BIND中，cookie默认是启用的，但默认情况下不会强制执行。此外，“dig”工具现在支持DNS cookie，只要使用+cookie选项即可。
这是一个示例数据包，显示DNS请求中的cookie选项。我还没有发现任何支持该选项的大型DNS提供商，但我没有对它们进行全部测试。
要过滤这些查询，可以使用Wireshark显示过滤器“dns.opt.code == 10”。它没有很好的BPF表达式，但是“tcpdump -r dns -n 'udp[18:2]>0 && udp[10]＆0x80=0'”将显示所有带有DNS选项的查询（有些可能只是EDNS选项0）。
捕获的数据包：使用Ubuntu 18.04，带有cookie的DNS数据包。
2 - TLS上的DNS
我看到越来越多的DNS创新是基于TLS的DNS。与DNS cookie不同，TLS上的DNS尝试解决DNS中的隐私问题。在Cloudflare的“1.1.1.1”DNS服务开始支持它之后，它出现了更多的追随者。我在PFSense防火墙中设置它，并在下面包含一些示例数据包。
该协议非常“直接”：设置TCP TLS连接，然后通过此TLS隧道发送DNS查询。问题在于TLS连接需要相当多的开销来建立。但它可以重复使用多个查询来减小总开销。在现实生活中，我发现TLS连接只能持续很短的时间，因此只要交换的数据包数量很大，开销就会很大。另外请注意，TLS端点将能够查看您的所有查询。Cloudflare表示它们不会使用这些数据。
使用TLS实现DNS的棘手部分是，它使许多企业系统无法获取和监控DNS流量。最好的办法是阻止TLS上的DNS（它使用端口853/TCP）并要求用户使用内部递归DNS服务器。然后，您可以在该DNS服务器上分析所有的日志记录。相比您的ISP，如果您更信任CloudFlare的TLS DNS服务器，您甚至可以让内部递归DNS服务查询Cloudflare的DNS服务器，。根据我的观察，基于TLS的DNS也不使用TLS中的ALPN或SNI选项，这些选项由更多“常规”的TLS连接（比如HTTPS）使用。
第三十四届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训
责编：pingxiaoli
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
抢沙发
