DNS是一个重要的基础设施，用于促进跨网络的通信。它通常被描述为电话簿：在其最基本的形式中，DNS提供了一种通过一个容易记住的名字来查找主机地址的方法。例如，查找域名条纹网将把客户机定向到IP地址53.187.159.182，Stripe的一个服务器就在这里。在进行任何通信之前，主机必须做的第一件事就是查询DNS服务器以获取目标主机的地址。由于这些查找是通信的先决条件，因此维护可靠的DNS服务非常重要。DNS问题会很快导致严重的、大范围的中断，您可能会发现自己处于一个真正的困境中。为这些系统建立良好的可观测性实践是很重要的，这样当出现问题时，您可以清楚地了解它们是如何失败的，并迅速采取行动，将任何影响降到最低。设备完善的系统提供了它们如何运行的可见性；建立一个监控系统和收集可靠的指标对于有效地响应事件都是至关重要的。当您试图了解根本原因并防止将来再次发生时，这对于事后分析至关重要。在这篇文章中，我将描述我们如何监控我们的DNS系统，以及我们如何使用一系列工具来调查和修复最近遇到的DNS错误的意外峰值。条带上的DNS基础结构在Stripe，我们操作一个运行Unbound的DNS服务器集群，这是一个流行的开源DNS解析器，可以递归地解析DNS查询并缓存结果。这些解析程序配置为根据请求中的域将DNS查询转发到不同的上游目标。用于服务发现的查询被转发到我们的conver集群。对我们在53号路由中配置的域以及公共互联网上的任何其他域的查询都会转发到我们集群的VPC解析程序，这是AWS作为VPC产品的一部分提供的DNS解析程序。我们还在每个主机上本地运行解析器，这提供了额外的缓存层。取消绑定在每个主机和DNS服务器上本地运行。Unbound公开了一组广泛的统计信息，我们收集这些数据并将其输入到我们的度量管道中。这为我们提供了度量指标的可见性，比如服务的查询数量、查询类型和缓存命中率。我们最近观察到，每小时有几分钟，集群的DNS服务器为一小部分内部请求返回SERVFAIL响应。SERVFAIL是DNS服务器在错误发生时返回的一个通用响应，但它并没有告诉我们导致错误的原因。在最初没有太多内容的情况下，我们在请求列表深度度量中发现了另一条线索。（您可以将其视为未绑定的内部todo列表，其中它跟踪所有需要解析的DNS请求。）此度量值的增加表示未绑定无法及时处理消息，这可能是由于负载增加引起的。然而，这些指标并没有显示DNS查询数量的显著增加，而且资源消耗似乎没有达到任何限制。由于Unbound通过联系外部名称服务器来解决查询，另一种解释可能是这些上游服务器响应时间较长。追查源头我们通过登录到一个DNS服务器并检查Unbound的请求列表来跟踪这个线索。$unbound control dump_请求列表螺纹#0#类型cl名称秒模块状态s3中为0 A。亚马逊网站. -迭代器等待10.0.0.23.8.25.104.IN.中的1个PTR-地址：arpa. -迭代器等待10.0.0.25.101.25.104.IN.中的2个PTR-地址：arpa. -迭代器等待10.0.0.25.156.25.104.IN.中的3 PTR-地址：arpa. -迭代器等待10.0.0.24 PTR英寸123.71.25.104英寸-地址：arpa. -迭代器等待10.0.0.2212.28.24.104.IN.中的5 PTR-地址：arpa. -迭代器等待10.0.0.26 PTR英寸18.81.25.104英寸-地址：arpa. -迭代器等待10.0.0.2103.78.24.104.IN.中的7 PTR-地址：arpa. -迭代器等待10.0.0.222.43.25.104.IN.中的8 PTR-地址：arpa. -迭代器等待10.0.0.29 PTR英寸24.17.25.104-地址：arpa. -迭代器等待10.0.0.210 PTR英寸21.100.25.104英寸-地址：arpa. -迭代器等待10.0.0.2......这确认请求在请求列表中累积。我们注意到一些有趣的细节：列表中的大多数条目都对应于反向DNS查找（PTR记录），它们都在等待来自10.0.0.2的响应，这是专有网络解析程序的IP地址。然后我们使用tcpdump捕捉其中一台服务器上的DNS流量，以便更好地了解发生了什么，并尝试识别任何模式。我们希望确保在其中一个峰值期间捕获了流量，因此我们配置tcpdump在一段时间内将数据写入文件。我们将文件分为60秒的收集间隔，以保持文件大小较小，这使得处理它们更容易。#捕获端口53上的所有流量（DNS流量）#以60秒的间隔将数据写入文件，持续30分钟#并用当前时间格式化文件名$tcpdump-n-tt-i any-W 30-G 60-W"%FT%T.pcap"端口53数据包捕获显示，在每小时峰值期间，向VPC解析程序发出的请求中，有90%是针对104.16.0.0/12 CIDR范围内IP的反向DNS查询。这些查询中的绝大多数都以SERVFAIL响应失败。我们使用dig查询VPC解析程序中的几个地址，并确认接收响应需要更长的时间。通过查看进行反向DNS查询的客户机的源ip，我们发现它们都来自Hadoop集群中的主机。我们维护一个数据库，记录Hadoop作业的开始和结束时间，因此我们能够将这些时间与每小时的峰值联系起来。最后，我们将流量源缩小到一个作业，该作业分析网络活动日志，并对这些日志中找到的IP地址执行反向DNS查找。我们在tcpdump数据中发现的另一个令人惊讶的细节是，VPC解析器没有向许多查询发送响应。在60秒的收集周期中，DNS服务器向VPC解析程序发送了257430个数据包。VPC解析程序只回复了61385个包，平均每秒1023个包。我们意识到我们可能达到了AWS对VPC解析程序的流量限制，即每个接口每秒1024个数据包。我们的下一步是在我们的集群中建立更好的可见性来验证我们的假设。统计数据包AWS通过一个相对于VPC基址IP的静态IP地址，再加上两个地址（例如，如果基础IP是10.0.0.0，那么VPC解析程序将是10.0.0.2）。我们需要跟踪每秒发送到此IP地址的数据包数。iptables是一个可以帮助我们的工具，因为它可以跟踪与规则匹配的包的数量。我们创建了一个规则来匹配指向VPC解析程序IP地址的流量，并将其添加到输出链中，这是一组iptables规则，应用于从主机发送的所有数据包。#创建一个名为VPC_RESOLVER的新链$iptables-N VPC_解析程序#匹配发送到VPC解析程序的数据包并跳到新链$iptables-A输出-d 10.0.0.2-j VPC_解析器#将空规则添加到新链以帮助解析输出$iptables-专有网络解析程序我们将规则配置为跳转到一个名为VPC_RESOLVER的新链，并在该链中添加了一个空规则。因为我们的主机可以在输出链中包含其他规则，所以我们添加了这个规则来隔离匹配项，并使解析输出更容易一些。列出这些规则，我们可以在输出中看到发送到VPC解析程序的数据包数：$iptables-L-v-n-x链输出（策略接受41023个数据包，2569001字节）pkts bytes目标prot opt in out source destination41023 2569001专有网络解析程序所有--**0.0.0.0/0 10.0.0.2链VPC U解析器（1个参考）pkts bytes目标prot opt in out source destination41023 2569001全部--**0.0.0.0/0 0.0.0.0/0通过这个，我们编写了一个简单的服务，从VPC_解析器链读取统计信息，并通过我们的度量管道报告这个值。同时：做包计数=$（iptables-lpc_解析器1-x-n-v | awk'{print$1}'）报告指标$PACKET_COUNT"vpc_解析程序包计数"睡眠1完成一旦我们开始收集这个指标，我们可以看到SERVFAIL响应的每小时峰值与服务器向VPC解析程序发送过多流量的时间段一致。交通放大我们从iptables中看到的数据（每秒发送到VPC解析程序的包数）表明，在这些时间段内，到VPC解析程序的流量显著增加，我们想更好地了解发生了什么。仔细观察从Hadoop作业进入DNS服务器的流量的形状，我们注意到客户机每次失败的反向查找都会发送5次请求。由于反向查找花费了很长时间或在服务器上被丢弃，所以每个主机上的本地缓存解析程序都会超时并不断地重试请求。除此之外，DNS服务器也在重试请求，导致请求量平均放大了7倍。分散负载需要记住的一点是，VPC解析程序限制是针对每个网络接口的。我们不需要在DNS服务器上单独执行反向查找，而是可以分配负载并让每个主机独立地与VPC解析程序联系。通过在每个主机上运行Unbound，我们可以轻松地控制这种行为。未绑定允许您为每个DNS区域指定不同的转发规则。反向查询使用中的特殊域-地址：arpa，因此配置此行为只需添加一个规则，该规则将对该区域的请求转发到VPC解析程序。我们知道私人广告的反向查找