大约一年前，我们意识到CloudFlare当前的DNS基础设施存在一些挑战。我们使用的是PowerDNS，这是一个很受托管提供商欢迎的开源DNS服务器。四年前我们选择PowerDNS有几个原因：1）它作为一个权威的DNS服务器速度相当快；2）它无缝地允许我们添加新的记录，而不需要重新启动；3）它允许我们编写绑定到系统其余部分的自定义后端，并允许我们快速更新DNS记录。虽然PowerDNS让我们走了很长一段路，但随着我们的扩展和处理越来越多的大规模拒绝服务攻击，它开始遇到问题。主要有三个挑战。首先，PowerDNS在大的内部DDoS负载下会消耗过多的资源，偶尔会崩溃。第二，更阴险的是，由于我们使用的PowerDNS版本没有滥用检测和速率限制，我们越来越多地看到有人试图使用CloudFlare权威DNS网络对其他人发起反射攻击。第三，扩展PowerDNS和添加任何类型的应用程序逻辑都是非常困难的，这使我们无法做有趣的事情。。。比如加复活节彩蛋。输入RRDNS值得称道的是，PowerDNS社区对前两个问题作出了一些努力，限制了速率和其他滥用检测。然而，由于CloudFlare的独特需求，我们意识到我们所需要的唯一真正的解决方案是定制构建权威名称服务器。大约九个月前，我们开始创建我们亲切地称之为rrdn的东西。今天，对CloudFlare的每个DNS查询都通过RRDNS运行，我们已经从堆栈中删除了PowerDNS。我们正在计划一篇更重要的博客文章，介绍RRDNS的技术细节以及如何构建其攻击检测和预防。然而，这只是一个简单的故事，它告诉我们，将应用程序逻辑添加到rrdn中的容易程度，使我们能够创建一对有趣的复活节彩蛋。复活节彩蛋RRDNS在模块化框架中是完全可扩展的。这使我们能够轻松地将应用程序逻辑添加到我们的名称服务器中，使它们能够根据收到的请求进行更动态的响应。随着时间的推移，我们计划使用这种扩展性来添加DNSSEC等特性。与此同时，我们的一位工程师伊恩写了一个快速扩展来演示这个功能。DNS有许多常见的记录，如A、AAAA、CNAME、TXT、MX等。其中一个被大量弃用的记录是CH（混沌）协议。Ian决定允许您通过DNS请求查询CloudFlare的当前工作列表。他写了15行代码作为RRDNS的扩展。他从我们的工作列表的RSS提要中动态地提取列表，如果您对CH记录运行一个特定的查询，则返回这些列表jobs.cloudflare直接攻击我们的一个DNS服务器。输出如下：$dig ch公司jobs.cloudflare@emma.ns.cloudflare公司.com文本；；已截断，正在TCP模式下重试。；挖9.8.3-P1chjobs.cloudflare@emma.ns.cloudflare公司.com网站；；全局选项：+cmd；；得到答案：；；->>页眉A；；答案部分：jobs.cloudflare. >86400>CH>TXT>"内容营销人员，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"客户支持主管，加利福尼亚州旧金山"jobs.cloudflare. >加利福尼亚州旧金山市>市场营销人员86400jobs.cloudflare. >86400>CH>TXT>"营销分析工程师，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"人才，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"建筑工程师，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"DDoS工程师，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"数据库工程师，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"前端开发人员，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"集成开发人员，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"JavaScript性能工程师，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"PHP开发者，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"产品经理，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"SDK工程师，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"系统工程师，英国伦敦"jobs.cloudflare. >86400>CH>TXT>"系统工程师，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"网络工程师，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"技术操作工程师，加利福尼亚州旧金山"jobs.cloudflare. >86400>CH>TXT>"技术操作工程师，英国伦敦"jobs.cloudflare. >86400>CH>TXT>"技术支持工程师，英国伦敦"jobs.cloudflare. >86400>CH>TXT>"技术支持工程师，加利福尼亚州旧金山"；；查询时间：16毫秒；；服务器：2400:cb00:2049:1:：adf5:3a70#53（2400:cb00:2049:1:：adf5:3a70）；时间：2013年8月26日星期一19:42:26；接收邮件大小：1122这并不是一种新的方式来告诉你我们有哪些工作。相反，我们可以很容易地将动态应用程序逻辑嵌入到我们的DNS系统中。对于一个更无用，尽管有趣的复活节彩蛋，尝试查询CH记录云闪针对我们的一个名字服务器。您可能需要扩大终端窗口的大小以获得完全的效果。所有的乐趣和游戏直到有人受伤当我看到这些复活节彩蛋时，我的第一个问题是：现在是否有人可以利用这些彩蛋来利用CloudFlare的网络放大DNS反射攻击。谢天谢地，伊恩已经想到了这一点，并建立了一个安全措施。DNS反射攻击依赖于攻击者在查询DNS服务器时欺骗受害者的源IP。由于大多数DNS请求是通过UDP发送的，UDP没有握手，因此可能导致DNS服务器响应欺骗的源。如果您查看对上述查询的响应，则响应的第一行为：；；已截断，正在TCP模式下重试。由于RRDNS具有高度的灵活性，所以在获得生成复活节彩蛋的查询时，Ian能够强制它使用0字节的UDP响应和DNS消息截断标志进行响应。这会导致发出DNS请求的客户端通过TCP重试。由于TCP协议中有一个握手，它可以防止源IP被伪造。由于UDP响应比原始查询小，而且TCP响应只会发送到经过完全握手验证的源IP，所以复活节彩蛋被用来放大DNS反射攻击的风险被消除了。我们不需要花太多心思就可以知道如何利用这种可扩展性来更好地防御我们看到的一些DNS攻击，这些攻击既针对我们，也包括利用我们来攻击其他人。在接下来的几周里，我们将深入研究rrdn背后的更多技术细节。在那之前，享受复活节彩蛋吧。