可以说，CloudFlare是世界上最大的第三方DNS权威运营商。我们管理着超过100万个域名，几乎每个TLD都有注册。我们作为DNS运营商的角色是维护客户信息并在全球DNS中发布他们的记录。在本博客中，我们将介绍像CloudFlare这样的DNS运营商在试图为客户提供最佳体验时所面临的一个重大问题。如果您是CloudFlare的客户，您会记得在注册过程中，为了更改您的nameservers（NS），您需要登录您的注册帐户。缺少更改NS记录的自动化过程不仅使我们的注册过程比我们希望的长了一步，而且还阻止了CloudFlare和其他第三方DNS运营商做一系列其他有利于客户和整个互联网的事情。注意：在本博客中，我们将主要在提供权威DNS服务的运营商的上下文中使用术语DNS Operator。这有时称为托管DNS服务。手动更新对于尚未成为CloudFlare客户的客户，让我们完成注册过程：当CloudFlare客户为他们的域启用DNS服务时，我们为他们分配并提供名称服务器。客户在CloudFlare系统上配置其域内的各种记录（例如A、AAAA、MX、CNAME等记录）后，客户需要返回其域注册器并手动更新其NS记录，以使其与CloudFlare提供的NS信息相匹配。一旦NS记录被更改，CloudFlare将成为该区域的权威DNS操作员。这个手动过程已经过时了，只有一件事阻碍了自动化进程，即当前的域名行业注册模型。领域行业标准注册模型的问题域名注册系统包括注册人（转销商和注册商）、注册中心和ICANN，对于信息如何在其中流动有严格的规则：注：本文件中使用的术语的完整词汇表可从ICANN网站获得。请注意，上述ICANN图中没有包括DNS运营商。当这个模型被创建时，没有人认为DNS服务可能是由注册者和注册者以外的其他人提供的。事情发生了变化，但不幸的是，制度及其规则并没有改变。在几乎所有情况下，CloudFlare客户都在使用注册器，其中CloudFlare与客户的关系没有明确表达。只能通过指向CloudFlare的NS记录或CloudFlare地址空间中的名称服务器地址来推断这种关系。在ICANN模型中，第三方DNS运营商的遗漏导致了运营困难。CloudFlare与注册机构和注册机构的关系操作上的困难目前出现，因为寻找域名注册商的唯一方法是查询"whois"信息。下面是从成功的whois查询中选择的输出：域名：CLOUDFLARE.COM网站... 注册服务器：whois.networksolutions.com网站注册网址：。。。注册人：网络解决方案有限责任公司。注册人IANA ID:2。。。注册人名称：CloudFlare，Inc。所有域更新（如邮政地址或名称服务器更改）在发送到注册中心之前，都要从客户（或注册人）转到注册中心。作为一个DNS运营商，CloudFlare与这些R命名的实体是分开的，因此我们不会出现在whois查询中。困难在于，whois信息可能包含邮政地址、电话号码和/或电子邮件地址，是为人类消费和人类行为而设计的。因为这个信息在历史上是由人改变的，所以没有一个协议来规定DNS运营商的系统如何以一种经过身份验证的自动化方式请求注册商更改委派信息。一种新的模式：DNS运营商与注册商和注册商进行通信在目前的ICANN系统中，大约有三类DNS运营商。这些类基于DNS操作员在委派父区域中进行更改的能力：注册商/经销商与注册数据库有直接的接口，可以随意和即时地更改信息。注册者有一个用户界面（通常是web）来更新信息第三方DNS运营商需要注册者代表其更新信息，或者可以访问注册者的注册帐户（这是一种糟糕的安全做法）。实际上，DNS运营商只能期望注册者在两种情况下登录到该帐户：a.当服务被移动到运营商时，或者b.当服务从运营商处被拿走时。CloudFlare提倡获得为我们的客户更新NS记录的能力，并使用自动通道处理与其相关的记录。我们的目标是能够在不涉及客户的情况下从客户域中添加和删除名称服务器。创建一个自动更新NS（和DS）记录的过程将有助于解决提供DNS服务的操作困难，并将为整个因特网开辟新的可能性。如果DNS运营商能够控制NS和DS记录，他们可以重新平衡名称服务器以保持稳定性，快速更换坏掉的名称服务器，甚至更好地保护客户免受DDoS攻击。大多数人不知道，当某些NS记录受到严重的DDoS攻击时，共享该名称服务器的所有客户都可能会遇到服务降级的问题。如果这些NS记录可以快速更改，我们就可以减少对非目标域的影响。使DNS操作员的访问客户NS和DS记录（委托签名者记录）自动化的最重要原因可能是，这种更改将为DNSSEC的实现铺平道路。DNSSEC需要维护DS记录，因为它们必须插入到父域中并可能定期更新。如果未正确维护此记录，则DNSSEC验证将失败，使域无法访问。目前，这是通过注册人在注册处的一个web界面来完成的。实现DNSSEC的普遍性理论上，注册者可以指定DNS操作员作为技术联系人，但是除非技术联系人被授予对注册者帐户的完全访问权限，否则这没有帮助，因为大多数注册者不提供基于角色的帐户访问权限。无论如何，要求我们的客户更新他们的委托信息以反映DNSSEC的信任链是有问题的。这种方法的一个问题是，如果CloudFlare要求拥有数百万个域的数十万客户对其记录进行手动更新，那么发生错误的可能性非常大。如果记录更新不正确，不仅会导致挫败感，还可能由于DNSSEC错误导致站点关闭。CloudFlare可以通过在每个区域发布cd和/或CDNSKEY记录来尽量减少这些错误，注册商可以通过DNS查询来获取这些记录并应用这些记录。但长期的解决方案是完全自动化，授权更新授权信息。有人会说，如果DNS运营商被指定为技术联系人（ICANN模型中定义的角色之一），那么目前的系统就可以工作，但是几乎没有注册商为客户提供基于角色的帐户。所有这些都是为了降低技术联系人的电话或电子邮件被认为是社会工程攻击的可能性。加入我们吧CloudFlare希望与注册商、注册中心和其他DNS运营商合作，为更新NS和DS记录定义和部署更可靠的方法。我们认为这对我们的客户来说是一个巨大的胜利，最终对整个互联网也是如此。如果您有兴趣参与此过程，您可以注册此邮件列表：dnssec-auto-ds@elists.isoc.org