跳至主要內容

DNS 延迟

2026/9/1DNS7.X.X大约 7 分钟

DNS 延迟

功能介绍

FortiGate 的系统 DNS 延迟是一次 DNS 查询从发送请求到收到响应的往返时间（RTT），其中包含请求到达 DNS 服务器、DNS 服务器处理查询以及响应返回 FortiGate 所需的时间。该值用于判断 DNS 服务器的响应状态，也会影响 least-rtt 模式下的服务器选择。

DNS 延迟不是 ICMP Ping 延迟。Ping 只能验证 ICMP 可达性和 ICMP 往返时间，不能反映 UDP/TCP 53 端口的访问情况、DNS 服务器处理查询所需的时间以及 DNS 请求重传。

相关信息

系统 DNS 延迟并非由单独的固定探测计算，而是由 dnsproxy 发往相应系统 DNS 服务器的实际查询与响应持续更新。可能参与计算的请求包括：

  • 执行 execute ping <域名> 前产生的域名解析请求。
  • FortiGuard 更新服务器和其他 FortiGate 本地系统服务使用系统 DNS 产生的域名解析请求。
  • 标准的非 wildcard FQDN 地址对象在首次解析和周期性刷新时产生的查询。
  • FortiGate 作为 DNS 服务器或转发器时，经 dnsproxy 转发给系统 DNS 服务器的查询。

只有 DNS 请求与响应的往返时间会参与该延迟计算，后续的 ICMP Ping、FortiGuard 更新下载或 HTTPS 连接耗时不会计入。

Wildcard FQDN 通常不会使 FortiGate 直接查询包含通配符的域名，而是通过观察经过设备的客户端 DNS 响应学习 IP 地址。如果 FortiGate 同时将客户端 DNS 查询转发给相同的系统 DNS 服务器，这些转发查询仍可能影响对应服务器的延迟。

FortiGuard 安全 DNS 的分类查询属于 SDNS 统计，显示在 SDNS latency info 中，不应与普通系统 DNS 的 DNS latency info 混为一类。

查看方式

  1. 进入“网络 → DNS”，在 DNS 设置页面查看系统 DNS 服务器的延迟。将鼠标指针悬停在延迟值上，可以查看该值最后一次更新的时间。

    FortiGate DNS 服务器延迟信息

  2. 执行 diagnose test application dnsproxy 2，查看系统 DNS 和 FortiGuard 安全 DNS（SDNS）的延迟信息。以下为 FortiOS 8.0.0 的示例输出：

    FortiGate # diagnose test application dnsproxy 2
worker idx: 0
worker: count=1 idx=0
retry_interval=500 query_timeout=1495
DNS latency info:
vfid=0 server=223.5.5.5 latency=9 updated=1018
vfid=0 server=10.10.12.1 latency=5 updated=3320
SDNS latency info:
DNS_CACHE: alloc=16, hit=9713
RATING_CACHE: alloc=0, hit=0
FQDN: alloc=11 nl_write_cnt=16849 nl_send_cnt=19760 nl_cur_cnt=0
Botnet: searched=0 hit=0
DNS query: alloc=0
DNS UDP: req=78225 res=78225 fwd=68520 retrans=6 to=0 fail_rate=0.000%
DNS FTGD: ftg_fwd=0 ftg_res=0 ftg_retrans=0
Socket monitor: cur=65 switched=93772121 num_switched=668 v6_cur=0 v6_switched=52617175 num_v6_switched=0
Others: compressed=0
RCODES: 72740 0 1 5484 0 0 0 0 0 0 0
DNS TCP: req=0 res=0 fwd=0 retrans=0 to=0 fail_rate=0.000%

DNS TCP connections:

DNS UNIX streams: cfd=32 cfd=33 cfd=34 cfd=35 cfd=36 cfd=37 cfd=38 cfd=39
    • DNS latency info：系统 DNS 服务器的延迟记录。
    • SDNS latency info：FortiGuard 安全 DNS 服务器的延迟记录。
    • vfid：产生该记录的 VDOM ID。
    • server：DNS 服务器地址。
    • latency：dnsproxy 保存的加权延迟值。
    • updated：距离该延迟值上次更新所经过的时间，单位为毫秒，GUI 将其换算为本地日期和时间显示。
    • retrans：DNS 请求重传计数。
    • to：DNS 请求超时计数。

    相关信息

    CLI 中的 latency 值等于 GUI 毫秒值的十分之一。例如 CLI 显示 latency=13 时，GUI 显示 130ms。排障时应在同一设备上对照 GUI 和 CLI，不要直接将 CLI 原始值当作毫秒值。

计算机制

≥ 7.4.4/7.6.0/8.0.0

FortiGate 只在收到 DNS 响应后更新 RTT。DNS 请求没有收到响应时，FortiGate 不会直接修改 RTT，而是在服务器选择时将失败次数作为延迟惩罚，使连续失败的服务器降低选择优先级。

收到 DNS 响应后，FortiGate 以请求发送到响应返回的时间作为本次 RTT 样本。已有加权 RTT 占 30%，本次 RTT 样本占 70%，计算公式如下：

$$ \text {新加权 RTT}

\text {已有加权 RTT} \times 30% + \text {本次 RTT 样本} \times 70% $$

例如，已有 latency 为 10，本次收到响应时的 RTT 样本为 20，新的加权值为 10 × 30% + 20 × 70% = 17。如果下一次查询超时，且此前已有有效的加权 RTT，本次超时不会直接修改该值。在此例中，latency 保持为 17，但服务器的失败次数会增加，并在后续服务器选择时受到惩罚。如果再下一次查询成功且 RTT 样本为 5，公式计算结果为 17 × 30% + 5 × 70% = 8.6。实际 CLI 字段通常使用整数表示。

重要

  • 采用新方式后，RTT 没有明显升高不表示 DNS 服务器没有发生超时。排障时需要同时检查 latency、failure、last_failed、重传和超时计数，并结合抓包确认 DNS 请求与响应。
  • 服务器尚无有效 RTT 样本时，CLI 也可能显示 latency=-1 或 rt=0。

< 7.4.4

当 DNS 请求发生重传时，FortiGate 会使用 1495 jiffies 作为接近超时的 RTT 惩罚样本，再按 3:7 权重更新平均值。例如，已有 latency 为 10，新的加权值为 10 × 30% + 1495 × 70% = 1049.5，CLI 取整后显示为约 1049。后续请求继续失败时，该值会逐步接近 1495。

相关信息

jiffy 是操作系统内部使用的时钟节拍，不等同于 1ms。在采用该惩罚机制的 FortiOS 版本中，CLI 的一个 latency 单位对应 GUI 中的 10ms，因此 1495 jiffies 对应约 14950ms，也就是约 15 秒。这个值用于模拟接近超时的最差 RTT 样本，不是抓包测得的真实网络延迟。

重要

旧版本中的高延迟值可能包含重传惩罚，不一定表示网络链路本身存在同等时长的延迟。无论使用哪种计算方式，如果 FortiGate 没有向该服务器发起新的 DNS 查询，延迟值都不会更新，GUI 可能继续显示之前的状态。

排查方法

  1. 同时记录 DNS 延迟和服务器统计信息，确认问题影响的服务器、VDOM、重传、超时及最近失败情况。

    diagnose test application dnsproxy 2
diagnose test application dnsproxy 3
    FortiGate # diagnose test application dnsproxy 3
DNS servers:
10.10.12.1 vrf=0 tz=0 encrypt=none req=16462790 to=10917569 res=0 rt=1494 ready=1 timer=0 probe=0 failure=2 last_failed=300
223.5.5.5 vrf=0 tz=0 encrypt=none req=2050940 to=1424553 res=0 rt=1494 ready=1 timer=0 probe=0 failure=7 last_failed=235

    相关信息

    diagnose test application dnsproxy 3 的输出中，req、to、failure 和 last_failed 分别用于观察请求、超时、失败次数和最近失败情况。单独看到高 latency 只能确认加权延迟值较高，不能直接确定故障发生在网络链路或 DNS 服务器。

  2. 分别验证 IP 可达性和 DNS 协议路径。Ping 正常后仍需在 DNS 查询期间抓取 53 端口报文，检查请求是否发出、响应是否返回以及是否存在重传。

    execute ping 192.0.2.53
diagnose sniffer packet any 'host 192.0.2.53 and port 53' 4 0 l

    提示

    如果系统 DNS 使用 DoT 或 DoH，应根据实际协议抓取 TCP 853 或 TCP 443 流量，不能只检查 UDP 53。

  3. 分析 DNS 响应码和查询名称。大量 Server failure、No such name、无响应或重传表明需要继续检查 DNS 服务器处理能力、域名有效性和查询来源。

    34  0.036068 192.0.2.53 198.51.100.10 DNS 103 Standard query response 0xb020 Server failure A legacy-service.example.net
904 0.001793 192.0.2.53 198.51.100.10 DNS 121 Standard query response 0x7e53 No such name A removed-host.example.net

  4. 检查 FQDN 地址对象中的域名是否仍然有效，以及对象是否仍被策略或其他配置引用。FortiOS 仍可能解析未被引用的 FQDN 地址对象，失效或无用对象过多会增加 dnsproxy 的查询负载。

    重要

    删除对象前应确认引用关系和业务用途。可以参照故障排查 → 查找对象引用检查对象引用，不要仅因当前未命中策略就直接删除。

  5. 如果异常查询来自内网主机，继续定位发起大量无效域名查询的客户端和进程。除配置错误外，持续查询不存在或可疑域名也可能是终端异常或安全事件的迹象。

  6. 修正 DNS 可达性、服务器性能、失效 FQDN 对象或异常客户端问题后，重新发起 DNS 查询，并再次执行 diagnose test application dnsproxy 2。确认 updated 已刷新，重传和超时不再持续增加，延迟值随成功查询逐步下降。

最近更新: