我已阅读并理解您能帮助我进行容量规划吗？，但我不确定我是否了解 DNS 服务器场景中的下一步是什么。我思考我的 CPU 负载很高，或者我可能会开始丢弃查询，但我想在采取行动之前更好地了解我的服务器的负载。这对我来说尤其令人担忧，因为众所周知，将基础设施扩展到 DDoS 负载是失败的。
为了了解我的环境我应该分析什么？
答案1
在 Serverfault 上，我们通常会告诉您我们无法帮助您进行容量规划。这是有充分理由的：我们不知道您的环境的具体情况，而且关于如何测量它的答案几乎相同。不幸的是，DNS 容量测量是一个鲜为人知的话题，大多数管理员会认为高 CPU 使用率意味着是时候考虑增加容量了。这是一个非常非常糟糕的想法，扩展到 DNS DDoS 将不可避免地导致您的网络设备堵塞。（或者更糟的是，人们会联系您的法律部门）
大多数管理员首先会尝试利用服务器日志和数据包捕获，但简单的事实是，SNMP 可以告诉你有关环境的信息远比日志多得多。不要忽略日志和数据包捕获，但 SNMP 通常可以帮助您更快地发现问题的存在。
除了跟踪 SNMP 监控工具提供的默认系统统计信息（应包括 CPU 负载、每个接口的吞吐量和数据包计数器、磁盘 I/O 等）之外，我建议添加以下 OID：
- UDP管理信息库
- 接收队列错误：
udpInErrors（愤怒的红色强烈推荐） - UDP 数据报计数器：
udpInDatagrams，udpOutDatagrams - （选修的）意外的数据报：
udpNoPorts
- 接收队列错误：
- TCP管理信息库
- TCP 段计数器：
tcpInSegs，tcpOutSegs
- TCP 段计数器：
解释图表
这些图表可以分为两类：指示问题的指标和帮助您诊断问题的指标。
指标
- 高 CPU 利用率是不好的。这是必然的，但当它发生时，您需要寻找其他指标来与之关联。如果高 CPU 利用率与出站网络利用率（吞吐量或数据包数量）的激增相对应，则很有可能您受到了 DDoS 攻击。有关如何解释攻击性质的具体内容请参阅下一节。
udpInErrors是容量问题的主要迹象。每次内核因为应用程序处理流量不够快而丢弃 UDP 数据报时，此计数器都会递增。这意味着您的 DNS 服务超载，无法跟上传入流量。- 大多数网络性能指南都会告诉你，增加接收队列的大小不是正确的解决方案：它们通常是正确的。尝试找到一个解释为什么服务器已超载，无论是通过查看其他图表还是分析日志。
- 如果您的公司运营使用 DNSBL 表的邮件服务器，请记住雪鞋袭击可以创造短暂的峰值合法的DNS 流量可能会耗尽接收队列中的空间。在这种情况下，可能需要增加套接字接收队列的大小（因为这是已知的临时情况），但通常最好投入更多硬件来解决问题，以降低延迟。
如果您无法将这些指标的增加与系统上的其他性能问题联系起来，那么恭喜您：您确实接近/超出了容量，是时候添加服务器了。我对此印象深刻。:)
诊断
这仅涵盖 DNS 特定项目。请动动脑筋，不要指望它能包罗万象。（例如：磁盘 I/O 饱和不是 DNS 特有的问题）
- 在繁忙的递归服务器上，出站吞吐量应保持在输入的 2 倍左右。这是因为回复通常比相关查询大得多。持续的峰值明显高于此水平表明您的服务器正在参与放大攻击。您很可能正在运营开放式解析器。
- 即使在递归 DNS 服务器上，传入的数据包也应大致等于传出的数据包。虽然偶尔会因为超时而需要重新传输查询，但这种情况不会经常发生，因此不会导致严重的图表偏差。传出数据包的显著增加表示网络问题，或者您的集群正被用于针对权威名称服务器的攻击。这并不一定表明您正在运行开放解析器：其他 DNS 服务器可能会将无法缓存的查询转发给您。
- 我建议除了每个接口的图表之外还绘制 UDP+TCP I/O 图表，这看起来似乎是多余的，但这些图表与接口无关，而且当您对名称服务器软件有足够的经验时，它们还可以让您深入了解正在进行的攻击的性质。
附注：udpNoPorts不是真的容量指标，但它对于识别缓存中毒尝试很有用。每次在意外端口上看到 UDP 数据包时，此计数器都会递增，正常运行期间持续出现这些数据包可能表明有人试图伪造回复。（要么是您的某个侦听器没有运行：将其重新打开 foo'！）
答案2
对于 DNS 服务器（实际上任何类型的服务器），有时你需要查看并分析对其发出的请求，以防配置错误（可能在其他地方）导致请求量增加（例如，请参阅Windows DNS 服务器在收到 SERVFAIL 响应时反复请求区域中的记录）。查看查询和响应的比例，然后尝试找到比较器来检查其是否正常。