我们一直在与IETF中的注册商和注册商合作，让DNSSEC更容易为域所有者服务，在接下来的两周里，我们将开始为.dk域自动启用DNSSEC。DNSSEC：底漆在我们详细介绍如何改进DNSSEC体验之前，我们应该解释DNSSEC的重要性以及它在维护web安全方面的作用。DNSSEC的作用是验证DNS应答的完整性。当DNS在80年代初被写出来时，互联网上只有少数研究人员和学者。他们都互相了解，相互信任，无法想象会有一个恶意的人试图在网上操作。因此，DNS依赖信任来运行。当客户机请求主机名的地址时网站，如果没有DNSSEC，它将基本上信任任何返回响应的服务器，即使它不是它最初请求的服务器。有了DNSSEC，每个DNS答案都会被签名，这样客户端就可以验证答案没有在传输过程中被操纵。DNSSEC的麻烦如果DNSSEC如此重要，为什么只有那么少的域支持它？首先，一个域要有机会启用DNSSEC，它的DNS提供者、注册商和注册中心不仅必须支持DNSSEC，而且所有三方都必须支持相同的加密算法。对于能够启用DNSSEC的域，DNSSEC并不容易--域所有者需要首先使用其DNS提供程序启用DNSSEC，然后将一些值（称为DS记录）从其DNS提供商的仪表板复制并粘贴到注册商的仪表板，以确保在复制和粘贴时不会遗漏任何字符，因为那样会切断他们整个区域的交通。我们需要的是自动化。更改过时的模型Cloudflare长期以来的声明是，作为DNS运营商，我们希望为用户自动更新DS，但DNS是在传统模式下运行的，注册商可以直接与注册中心对话，但DNS运营商（Cloudflare）完全不在该模式中。在Cloudflare，我们决定是时候改变那个过时的系统了。我们已经发布了一个互联网草案，提出了一个新的模式，如何DNS运营商，注册商和注册商可以操作和沟通，以作出特定的用户授权的变化的领域。需要指出的是，IETF的工作原理是大致一致和运行代码。Cloudflare和.dk注册表一起生成了运行代码，我们已经非常接近于达成共识。这个互联网草案现在正在IETF的标准轨道上前进，并且正在成为一个成熟的RFC。dk和Cloudflare合作得怎么样丹麦的ccTLD运营商（即.dk域名）也意识到该模型已经过时。它们为用户（以及与.dk域关联的命名服务器的操作员）提供了一种安装和更新DS记录的编程方式。这正是像Cloudflare这样的运营商所需要的。Cloudflare已经测试了他们的API，现在已经准备好为我们的.dk客户启动一种自动化、干净、安全和可靠的更新DS记录的方法。在接下来的两周内，我们将为.dk域启用DNSSEC，这些域在过去已经开始，但是还没有完成。当然，对于Cloudflare来说，丹麦是这样的前卫思想家的故乡，这一点也不奇怪！向前！如果您在Cloudflare上有一个.dk域，那么在我们于2017年4月18日（星期二）进行迁移之前，您实际上不需要做任何事情，只需在Cloudflare登录控制台中打开启用DNSSEC的开关。我们很高兴与.dk注册表合作，这是使DNSSEC自动化的第一步，并正在寻找其他TLD，以使DNSSEC易于使用。