Cloudflare在2014年首次开始谈论DNSSEC，当时，Nick Sullivan写道："DNSSEC是提高DNS信任和完整性的宝贵工具，DNSSEC是现代互联网的支柱。"在过去的四年中，DNSSEC已经成为保护互联网的一个更为关键的部分。虽然HTTPS在防止用户会话被劫持和恶意（或无害）重定向方面做了很大的努力，但并非所有的互联网流量都是HTTPS。一个更安全的互联网应该保护用户和他们想要的来源之间的每一个可能的层访问。作为DNSSEC是一种快速刷新工具，它允许用户、应用程序或递归解析程序相信其DNS查询的答案是域所有者想要的结果。换句话说，DNSSEC证明了来自权威名称服务器的响应的真实性和完整性（尽管不是机密性）。这样做会使坏角色更难通过BGP泄漏和缓存中毒将恶意DNS记录注入解析路径。当一个域正在发布用于声明其他系统信任的记录类型时，DNS中的信任更为重要。作为一个具体的例子，DNSSEC有助于防止恶意参与者获取域的欺诈证书。研究表明了域名的DNS响应是如何被欺骗的验证。这个本周，我们将宣布我们对CDS和CDNSKEY的全面支持来自rfc8078。简单地说：这将允许建立DNSSEC，而不需要用户登录到他们的注册器来上传DS记录。支持注册中心上的Cloudflare客户只需单击Cloudflare中的一个按钮即可启用DNSSEC仪表板。验证解决方案DNSSEC最大的问题是采用。DNSSEC递归解析程序验证的DNS查询数保持不变。据我们在APNIC的朋友说，在全球范围内，只有不到14%的DNS请求通过解析程序验证了DNSSEC。这里的责任落在默认DNS提供商的肩上，大多数设备和用户通过ISP或网络提供商从DHCP接收。数据显示，有些国家做得更好：例如瑞典，其80%以上的请求都经过了验证，这表明这些国家的默认DNS解析程序会按照其应有的方式验证响应。APNIC也有一个有趣的互动地图，所以你可以看到你的国家有多好是的。所以我们能做什么？要确保解析程序支持DNSSEC，请访问brokendnssec.net在您的浏览器中。如果页面加载，则不受DNSSEC验证解析程序的保护，应切换解析程序。然而，为了在互联网上真正发挥作用，Cloudflare鼓励网络提供商在其软件中启用DNSSEC的验证，或者切换到公共可用的解析器，默认情况下验证DNSSEC。当然我们有最喜欢的，但也有其他的好选择。区域签名validation处理用户端，但另一个问题是区域本身的签名。最初，考虑到TLD支持是DNSSEC工作的一项要求，因此有人担心TLD级别的采用。到2018年8月27日，超过90%的TLD在根区域与DS记录签署，这在很大程度上是没有问题的。当涉及到各个域本身时，情况就不同了。根据NIST的数据，财富1000强中只有3%的人签署了他们的主要域名。部分原因是域名所有者的冷漠。然而，一些大型DNS运营商根本不支持该选项，要求想要保护其用户的域所有者完全迁移到另一个提供商。如果您使用的服务不支持DNSSEC，我们鼓励您切换到支持DNSSEC的服务，并让他们知道这是切换的原因。其他大型运营商，如GoDaddy，负责DNSSEC。我们在这里的立场是明确的：DNSSEC应该是可用的，并包括在所有DNS运营商免费的DS母公司问题2017年12月，APNIC撰文解释了为什么DNSSEC部署仍然如此之低，而这在今天基本上仍然是事实。一个关键点是，尝试DNSSEC激活但没有完成DNSSEC激活的域所有者的数量非常多。以Cloudflare为例，APNIC测量到，在Cloudflare Dash中启用DNSSEC的人中，有40%的人实际上成功地从注册表中提供了DS键。最近90天内的当前数据稍微好一点：我们看到所有试图启用DNSSEC的区域中，有超过50%的区域能够使用注册表完成该过程（注意：这些域仍在解析，只是仍然不安全）。在我们最流行的TLD中，.be和.nl的成功率超过70%，但这些数字仍然没有达到我们所希望的理想水平。下面的图表显示了最流行的TLD（从左到右最受欢迎）的具体费率。这个最终结果对于试图将DS记录添加到其注册器的人来说可能并不奇怪。定位存放DNSSEC的注册器UI的部分可能会有问题，添加记录的UI本身也是如此。其他因素，如用户之间不同程度的技术知识，以及仅仅需要管理多个登录和角色，也可以解释流程中缺少完成的原因。最后，注册器之间不同级别的DNSSEC兼容性可能会阻止知识渊博的用户在父级。As例如，在Cloudflare，我们采用了一种最简单的UX方法为委派的子域添加DS记录。新手用户可能不了解DS的字段和要求录制：CD和CDNSKEY正如前面提到的APNIC博客中提到的，Cloudflare支持rfc8078以及CDS和CDNSKEY记录。考虑到我们自己的Olafur Gudmundsson是RFC的合著者，这一点也不奇怪。CDS和CDNSKEY是反映DS和DNSKEY记录类型的记录，但它们被指定为向父/注册器发出信号，表示子域希望启用DNSSEC，并由注册表提供DS记录。多年来，我们一直在推动这一领域的自动化解决方案，并鼓励业界与我们一起行动。今天，我们宣布对所有支持Cloudflare中DNSSEC的Cloudflare管理域的CDS和CDNSKEY记录提供全面可用性和全面支持破折号。怎么了It workcloudflare将为所有启用DNSSEC的域发布cd和CDNSKEY记录。父注册中心应该扫描其权限下域的名称服务器，并检查这些rrset。如果存在委派给Cloudflare的域的CDS键，则表示经过验证的Cloudflare用户已在其仪表板中启用DNSSEC，并且父操作员（注册器或注册表本身）应获取CDS记录内容并创建必要的DS记录，以开始对域进行签名。ch和.cz已经通过Cloudflare和选择支持RFC8078的任何其他DNS运营商支持这种自动化方法。注册官甘地和一些TLD已经表示支持未来。Cloudflare还支持CDS0删除DS记录，以防用户将其域从Cloudflare转移或禁用DNSSEC贝斯特下面针对父运算符的实践是一些建议的过程，父注册中心可以为我们的用户提供最佳体验：扫描选择-父运营商只应扫描其名称服务器指向Cloudflare（或采用RFC8078的其他DNS运营商）的子域。指示Cloudflare名称服务器*。ns.cloudflare.com网站。定期扫描-父操作员应定期扫描CD记录的存在和更改。每12小时扫描一次就足够了，不过越快越好。通知域联系人-当检测到新的CDS记录和DS记录即将发生更改时，父运营商应通过已知的渠道（如电子邮件和/或SMS）通知其指定的联系人。父操作员也可能希望在更改DS记录之前提供标准延迟（24小时），以允许域联系人取消或以其他方式更改操作。验证成功-父运算符必须确保域在被签名后继续解析。如果域在更改DS记录后无法立即解析，则父运算符必须返回到以前的功能状态，并应通知指定的联系人。什么这是不是意味着下一步呢？对于Cloudflare客户来说，这意味着一旦您的注册中心/注册商支持CDS和CDNSKEY，DNSSEC的实现就更容易了。客户还可以在Cloudflare上免费启用DNSSEC，并手动将DS输入到父级。要检查域的DNSSEC状态，DNSViz（示例cloudflare.com网站)拥有最符合标准的工具之一在线。为了登记处和登记员，我们正在采取这一步骤，希望更多的提供商支持RFC8078，并帮助增加全球采用的技术，帮助最终用户不易受DNS攻击互联网。为了其他DNS运营商，作为发布CDS和CDNSKEY的主要DNS运营商，我们鼓励您加入我们的行列，支持这种方法，注册中心开始寻找和使用的可能性就越大他们。云闪将继续沿着这条道路前进，并计划创建和开放源代码附加工具，以帮助注册中心和操作员推送和使用记录。如果你觉得有趣的话，我们是招聘。订阅更新我们的公告。