PCAP 中的 DNS 超时、NXDOMAIN 和 SERVFAIL:如何区分慢速 DNS 和慢速服务器

很多“应用慢”的案例实际上都是DNS案例。用户单击按钮，应用程序等待几秒钟，第一个责任归咎于服务器。数据包捕获可能显示在 DNS 解析完成或失败之前甚至没有尝试 TCP 连接。

DNS 证据紧凑，但很容易被误读。 NXDOMAIN、SERVFAIL 和超时是不同的结果。将它们视为一种通用的“DNS 错误”会导致错误的所有者。

超时意味着没有到达可用的答案

DNS 超时通常表现为重复查询而没有有用的响应。客户端可以重试相同的名称、查询多个解析器或从 IPv6 回退到 IPv4。关键标志是申请可以继续进行之前的时间流逝。

检查：

• 查询名称
• 查询类型：A、AAAA、CNAME、SRV 等。
• 解析器IP
• 重试间隔
• 是否有响应到达
• TCP 或 TLS 连接开始之前的时间
• 多个解析器的行为是否不同

如果在尝试连接之前有几秒钟的 DNS 重试，则服务器还不算慢。客户端还没有到达。

NXDOMAIN 是一个有效的否定答案

NXDOMAIN 表示该名称不存在。这可能是应用程序配置问题、拼写错误、过时的域、水平分割 DNS 问题或可选行为的预期查找。这和没有反应不一样。

有用的问题：

• 返回哪个名称 NXDOMAIN？
• 应用程序是否尝试过其他名称？
• 这是内部 DNS 还是公共 DNS？
• 搜索后缀扩展是否会产生意想不到的名称？
• 否定的答案很快就到来了吗？

快速的 NXDOMAIN 通常不是性能问题。这是一个正确性问题。

SERVFAIL 指向解析器或权限问题

SERVFAIL 意味着解析器无法完成答案。原因可能包括 DNSSEC 验证失败、无法访问权威服务器、解析器配置错误或部分中断。

客户端附近的 PCAP 可能仅显示解析器的最终“SERVFAIL”。解析器附近的捕获可能会显示上游查询及其失败的位置。占领点很重要。

为什么 PCAP 手术如此重要

PCAP 手术不是 DNS 服务器。它的作用是帮助工程师隔离数据包捕获中的证据、修剪相关窗口、保留时序并准备可防御的切换文件。 DNS 案例通常需要小型、集中的摘录：

• 应用程序连接之前的查询
• 解析器响应
• 重试时机
• 解析后相关的TCP/TLS连接
• 有足够的上下文来证明 DNS 造成了延迟

如果大型 PCAP 包含 10 秒用户可见的延迟，则提取 DNS 查询窗口加上第一次连接尝试可以使支持案例更容易审查。

DNS 故障排除捕获中应保留的内容

保存：

• timestamps
• DNS 事务 ID
• 查询和响应对
• 响应代码
• 解析器 IP
• 客户端IP
• 后续连接时序

匿名时要小心。如果查询名称被完全删除，接收者可能不知道失败是否是拼写错误、内部域、公共域或搜索后缀行为。

对于“DNS 超时 pcap”、“NXDOMAIN 与 SERVFAIL”或“慢速 DNS 数据包捕获”等搜索查询，关键是证明应用程序在到达服务器之前是否等待解析。