This paper is included in the Proceedings of the 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’17).
问题是什么？为什么重要？问题由那些因素导致？ 已有工作如何解决？为什么已有工作解决不了 本论文是怎么解决？总体思想是什么？各个模块是怎么设计的？为什么？ 实验评估：实验环境？性能指标？效果？ 读后感：妙处是什么？哪些不足？ 作者背景介绍
第一次对互联网上DNSSEC-signed 域名进行测量； 收集了2.1M DNSSEC key,其中1.9M是RSA keys 35％使用RSA密钥签名，这些密钥与其他域共享其模数，66％使用太短的密钥（1024bit甚至更小）或模数GCD> 1的密钥与其他域的模数
DNSSEC keys Validation Engine
用户在用域名（www.example.com）访问某一个网站时，用户的计算机一般会通过一个域名解析服务器（Resolver Server，也称递归服务器（Recursive Server））把域名转换成IP地址。解析服务器一般需要通过查询根域名服务器（root）、顶级域名服务器（TLD）、 权威域名服务器（Authoritative Name Server），通过递归查询的方式最终获得目标服务器的IP地址，然后交给用户的计算机。在此过程中，攻击者都可以假冒应答方（根、顶级域、权威域、或解析服务器）给请求方发送一个伪造的响应，其中包含一个错误的IP地址。发送请求的用户计算机或者解析服务器很傻、很天真地接受了伪造的应答，导致用户无法访问正常网站，甚至可以把重定向到一个伪造的网站上去。由于正常的DNS解析使用UDP协议而不是TCP协议，伪造DNS的响应报文比较容易；如果攻击者可以监听上述过程中的任何一个通信链路，这种攻击就易如反掌。
更加糟糕的是，由于DNS缓存（Cache）的作用，这种错误的记录可以存在相当一段时间（比如几个小时甚至几天），所有使用该域名解析服务器的用户都无法访问真正的服务器。攻击者可能是黑客、网络管理者等等（比如利用用户的拼写错误，把对不存在域名NXDOMAIN的访问重定向到一个广告页面）。
Domain Name System Security Extensions (DNSSEC)DNS安全扩展 DNSSEC是为解决DNS欺骗和缓存污染而设计的一种安全机制 起因： DNS 解析的请求者无法验证它所收到的应答信息的真实性，而DNSSEC给解析服务器提供了防止上当受骗的武器，即一种可以验证应答信息真实性和完整性的机制。利用密码技术，域名解析服务器可以验证它所收到的应答（包括域名不存在的应答）是否来自于真实的服务器，或者是否在传输过程中被篡改过。
DNSSEC依靠数字签名保证DNS应答报文的真实性和完整性。权威域名服务器用自己的私有密钥对资源记录（Resource Record, RR）进行签名，解析服务器用权威服务器的公开密钥对收到的应答信息进行验证。如果验证失败，表明这一报文可能是假冒的，或者在传输过程、缓存过程中被篡改了。
DNSSEC增加了四种类型的资源记录： RRSIG（Resource Record Signature）、DNSKEY(DNS Public Key)、DS(Delegation Signer)、NSEC(Next Secure)。
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmy…… aNvv4w== )
256:它是一个16比特的数，如果第7位（左起为第0位。这一位是区密钥（Zone Key）标志, 记为ZK）为1，则表明它是一个区密钥，该密钥可以用于签名数据的验证，而且资源记录的所有者（example.com.）必须是区的名字 3:DNSKEY 5:算法（Algorithm）字段，标识签名所使用的算法的种类 最后括号中的是公开密钥（Public Key）字段，它的格式依赖于算法字段
权威域的管理员通常用两个密钥配合完成对区数据的签名。一个是Zone-Signing Key(ZSK)，另一个是Key-Signing Key(KSK)。ZSK用于签名区数据，而KSK用于对ZSK进行签名。这样做的好处有二：
（1）用KSK密钥签名的数据量很少，被破解（即找出对应的私钥）概率很小，因此可以设置很长的生存期。这个密钥的散列值作为DS记录存储在上一级域名服务器中而且需要上级的数字签名，较长的生命周期可以减少密钥更新的工作量。
（2）ZSK签名的数据量比较大，因而破解的概率较大，生存期应该小一些。因为有了KSK的存在，ZSK可以不必放到上一级的域名服务中，更新ZSK不会带来太大的管理开销（不涉及和上级域名服务器打交道）
RRSIG资源记录存储的是对资源记录集合（RRSets）的数字签名
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 20030220173103 2642 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr … J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
类型覆盖（The Type Covered Field）：表示这个签名覆盖什么类型的资源记录，本例中是A；
算法：数字签名算法，同DNSKEY记录的算法字段；本例中5表示RSA/SHA-1。
标签数量（The Labels Field）：被签名的资源域名记录所有者（host.example.com.）中的标签数量，如本例中为3，*.example.com.为2，“.”的标签数量为0。
接下来的几个字段分别是被签名记录的TTL、有效期结束时间、开始时间。
然后（2642）是密钥标签（Key Tag），它是用对应公钥数据简单叠加得到的一个16比特整数。如果一个域有多个密钥时（如一个KSK、一个ZSK），Key Tag可以和后面的签名者字段（example.com.）共同确定究竟使用哪个公钥来验证签名。
DS（Delegation Signer）记录存储DNSKEY的散列值，用于验证DNSKEY的真实性，从而建立一个信任链。不过，不像DNSKEY存储在资源记录所有者所在的权威域的区文件中，DS记录存储在上级域名服务器（Delegation）中，比如example.com的DS RR存储在.com的区中。
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A98631FAD1A292118 )
DS 之后的字段依次是密钥标签（Key Tag）、算法、和散列算法（1代表 SHA-1）。后面括号内的内容是dskey.example.com.密钥SHA-1计算结果的16进制表示。Example.com必须为这个记录数字签名，以证实这个DNSKEY的真实性。
NSEC记录是为了应答那些不存在的资源记录而设计的。为了保证私有密钥的安全性和服务器的性能，所有的签名记录都是事先（甚至离线）生成的。服务器显然不能为所有不存在的记录事先生成一个公共的“不存在”的签名记录，因为这一记录可以被重放（Replay）；更不可能为每一个不存在的记录生成独立的签名，因为它不知道用户将会请求怎样的记录。
针对于DNS攻击：DNS 缓存中毒、DNS劫持 DNSSEC提出 对DNSSEC keys在signed domins 产生的漏洞进行研究
在密钥生成期间节省随机性或故障缺乏使用的key的验证系统一系列针对于如何抵抗dns缓存中毒的技术研究
IETF设计DNSSEC来捡起DNS缓存中毒攻击，但是由于DNSSEC步数需要DNS设施的改变，DNSSEC部署情况十分缓慢。尽管DNSSEC在1997年被提出，但是目前测量显示部署不超过25%；
本文对signed 域名 产生的DNSSEC密钥安全性进行研究；漏洞的研究没有依赖在线DNSSEC检查器
本文工作类似于TLS/SSH key 漏洞测量工作，这项工作指出问题的关键性在于在必要产生的过程中没有充分加密，
加密系统的安全性依赖于密钥产生过程。攻击者可以利用随机数产生器无效的随机性进行攻击。
Debian OpenSSL产生的“随机数”可被预测 SSL/TLS：不同的产生故障Heninger等人对TLS证书扫描发现由于随机性产生器RNGs的有1%的漏洞关于SSH 主机与其证书我们表明具有随机性的问题并非局限于嵌入式设备，但更重要的是，即使是大型和流行的DNS主机提供商和注册商，也会在多个签名域中引入漏洞。DNS response返回的记录可使用户与仿冒的IP地址进行通讯，DNSSEC基于数据的完整性和源验证，对DNS resource 记录进行签名。
New Resource Records（RRs）:该记录用于存放我们当前域名每一条记录的 DNSSEC 签名DNSKEY:该记录用于存放我们用于检查 DNSSEC 签名的公钥DS:该记录用于存放 DNSSEC 公钥的散列值NSEC:用于验证不存在的资源记录Trust Anchor and Chain of TrustDNSSEC Cryptographic Building Blocks参考资料
公钥：n、e 私钥：n、d 参考资料
如果n可以被因数分解，d就可以算出，也就意味着私钥被破解存在一个有效的算法，它接收e和因子p和q，并计算d。若许多参与者共享 ( e i , N ) ， 公 钥 ( d i , N ) (e_i, N)，公钥(d_i, N) (ei,N)，公钥(di,N)存在一个算法可以从 e i , / f i n a ( N ) e_i, /fina (N) ei,/fina(N) 计算出 d i d_i diGCDchallenges：
支持动态，简单生成新数据源；每天从数据源执行高效和快速的数据收集；到期时更新密钥；允许对密钥域和注册表进行在线验证爬取种子
从ICANN中获取root和TLD域文件（1301个不同的TLDs）扫描Alexa top 1M的域名（依赖Alexa domains 作为SLD）sonar DNS project：每天扫描IPv4地址空间发现DNS resource records如何获取所有的DNSSEC-signed 域名？ DKrawler：每天扫描一次
共收集到 900K 个signed domains，共有2.1M DNSKEY records，其中1.9M使用了RSA；
收集瓶颈：发送requests后等待时间；异步爬取DNS 服务器
report：共享模块密钥，共享密钥、弱密钥、DNSSEC适用性
www.dnssec.sit.fraunhofer.de
扫描时间表、种子、DNS 记录值、种子列表、DNS keys、协议、TTL、算法、扫描历史、key长度
主要关注：TLD、Alexa流行域名
87.6% TLD 是signed， 1.6% Alexa
