您的位置: 首页  >  文章  >  论文阅读2017:A Longitudinal, End-to-End View of the DNSSEC Ecosystem

论文阅读2017:A Longitudinal, End-to-End View of the DNSSEC Ecosystem

分类: 文章 • 2024-05-03 20:28:52

A Longitudinal, End-to-End View of the DNSSEC Ecosystem

This paper is included in the Proceedings of the 26th USENIX Security Symposium
2017USENIX
Crypto Deployment

作者

论文阅读2017:A Longitudinal, End-to-End View of the DNSSEC Ecosystem

知识点

DNSSEC

DNS 查询是明文传输的，也就是说中间人可以在传输的过程中对其更改，甚至是去自动判断不同的域名然后去做特殊处理。即使是使用其他的 DNS 缓存服务器，如 Google 的 8.8.8.8，中间人也可以直接截获 IP 包去伪造响应内容。DNSSEC 这一个扩展可以为 DNS 记录添加验证信息，于是缓存服务器和客户端上的软件能够验证所获得的数据，可以得到 DNS 结果是真是假的结论。

  1. DNS服务器收到DNS查询请求后，用散列函数将要回复DNS文的内容进行散列运算，得到“内容摘要”，使用私匙加密后再附加到DNS报文中；

  2. DNS查询请求者接收到报文后，利用公匙解密收到的“内容摘要”，再利用散列函数计算一次DNS查询请求报文中的“内容摘要”，两者对比；

  3. 若相同，就可以确认接收到的DNS信息是正确的DNS响应；若验证失败，则表明这一报文可能是假冒的，或者在传输过程、缓存过程中被篡改了。

摘要

DNSSEC功能；DNSSEC只有在其PKI中的每个主体正确执行其管理任务时才能运行：权威名称服务器必须正确生成和发布其**和签名，支持DNSSEC的子区域必须使用其父**正确签名，解析器必须实际验证签名链。

本文对DNSSEC PKI执行一次大规模的水平测量。.com、.org、.net 21个月的按域的部署和管理；主动探测了超过59K的DNS解析器验证其功能。

结果：31％支持DNSSEC的域无法发布验证所需的所有相关记录; 39％的域使用不太强大的**签名**;虽然我们研究中82％的解析器请求DNSSEC记录，但只有12％的人真正尝试验证它们。

研究点的提出

DNSSEC提出为了防止DNS的一系列攻击。DNS PKI：在服务器端，诸如弱**，过期签名或破坏的签名链之类的单个错误可能削弱或完全损害大量域的完整性。在客户端，错误的或错误的DNS解析器可以通过简单地捕获无效或丢失的签名来避免所有服务器端的工作。

先前研究对DNSSEC PKI管理的生态系统的测量极少；尽管近些年对DNSSEC展开一系列研究，但是大规模水平测量其行为的研究先前没有。

eg:服务器端研究已经显示了管理不善的实例，但仅限于主要名称的样本。同样，DNS解析器的先前研究使用了广告活动，这些广告活动不会随着时间推移重复控制解析器的测量。使DNSSEC的大规模，纵向研究如此具有挑战性的原因是DNSSEC记录数据集的缺乏以及缺乏有利于重复测量解析器行为的有利位置。

本文对整个DNSSEC生态系统进行测量：签名者，权威名称服务器和验证DNS解析器 - 以了解如何（错误）管理DNSSEC

工作依赖于所有签名的.com，.net和.org二级域名的DNSSEC记录的21个月每日快照和三个月的每小时快照。为了研究客户端行为，我们利用Luminati HTTP / S代理服务，它允许我们从403,355个终端主机执行重复的，受控的测试 - 从而在全球范围内研究59,513个不同的DNS解析器。

贡献

  1. 发现将近三分之一的启用DNSSEC的域生成由于缺少或不正确的记录而无法进行验证的记录；
  2. 我们确定了四个使用相同**签署所有托管域的大型提供商；
  3. 观察到1024位RSA**的广泛使用，现在被认为是“弱”（小于NIST建议的最小大小2048位
  4. 尽管83％的观察解析器在查询期间请求DNSSEC记录，但只有12％的解析器实际验证了记录

论文阅读2017:A Longitudinal, End-to-End View of the DNSSEC Ecosystem

实验

  1. 我们检查三个最大TLD中的所有启用DNSSEC的域，而不是样本；
  2. 研究了21个月的DNSSEC行为，使我们能够研究时间趋势；
  3. 研究了更多类型的错误配置，包括那些需要纵向数据研究的错误配置

了解析器是否请求并验证DNSSEC记录？如何得知？

  1. **被动技术：**依赖于权威DNS服务器的日志
  2. **主动技术：**从部署在大量网络中的客户端发出DNS查询
  3. 嵌入在网页中的广告可以实现大规模的DNS解析器测量：此方法会放置广告，使客户端向用于测试目的的域发出HTTP请求

数据集

目标是对权威DNS服务器上的DNSSEC采用和部署进行大规模，纵向和详细的研究

  • 大约150M域名覆盖了Alexa Top-1M的64％和Alexa Top-1K网站的75％
  • 近两年的DNSSEC记录快照
  • 每个域子集进行每小时快照
  • 每日扫描：包括来自OpenINTEL的测量数据，跨越21个月
  • 每小时扫描：只关注在TLD区域中具有DS记录的域，在2016年9月29日至12月31日期间收集.com和.org TLD中所有二级域名（平均708K域名）的RRSIG记录

从时间角度部署DNSSEC研究

发布DNSKE记录不意味着正确的部署；

使用数据集：Daily

  • 少数权威名称服务器负责DNSSEC部署的大部分增长
  • 热门网站更有可能签署其域，但整体部署即使在最受欢迎的域中也是一般般

检查域是否发布所有必要的DNSSEC记录

使用数据集：Hourly

  • DS records：检查使用Daily数据集无法上传DS记录的已签名域的百分比，观察到28％-32％的签名域没有DS记录，这意味着它们无法验证
  • RRSIG records：Daily：发现缺少SOA RRSIG的比例非常高。这些是由同一个托管服务提供商Domain Monster引起的，它不仅为超过37,000个域提供DNSKEY而没有相应的DS记录，但也没有签署SOA，表明彻底的错误管理

错误的记录

记录中的签名（和时间戳）必须正确（并且不会过期）

  • RRSIG signatures ：首先检查SAS和DNSKEY记录的RRSIGs记录的正确性和新鲜度，仅使用提供RRSIG记录的Daily数据集中的域。由于除DNSKEY记录之外的所有RRSets都由相同的ZSK签名，因此我们使用ZSK验证SOA记录，并使用KSK验证DNSKEY记录。
  • DS records：Daily

**管理

  • shared keys：从最新的快照（2016年12月31日）中提取每个域的DNSKEY记录，并分别按其KSK和ZSK分组域
    • 调查**共享是否主要由来自受影响域的一小部分托管提供商的策略来解释。我们首先按权威名称服务器对域进行分组，然后在我们最新的快照中通过DNSKEY再次对它们进行分组
  • Weak keys：每日使用每日数据集的弱ZSK和KSK的百分比

Key Rollover

DNSSEC为实体提供了一种更改其公钥/私钥对的方法

相关推荐