跳至主要內容

DNS 延迟

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

DNS 延迟

功能介绍

FortiGate 的系统 DNS 延迟以一次 DNS 查询从发送请求到收到响应的往返时间为样本，其中包含请求到达 DNS 服务器、DNS 服务器处理查询以及响应返回 FortiGate 所需的时间。dnsproxy 会对成功查询的延迟样本进行平滑计算，形成用于显示和服务器选择的加权延迟。

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）的延迟信息：

    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 显示的延迟只会是 10ms 的倍数。排障时不要直接将 CLI 原始值当作毫秒值。

  3. 执行 diagnose test application dnsproxy 3，查看系统 DNS 服务器的运行状态和请求统计信息：

    FortiGate # diagnose test application dnsproxy 3
2026-09-01 17:55:18 worker idx: 0
2026-09-01 17:55:18 VDOMS:
2026-09-01 17:55:18 vfid=0 name=root dns=1 pri=1 nat64=0 hostvis=1 vrf=0 mthd=auto intf=n/a
2026-09-01 17:55:18     10.10.12.1:53 vrf=0 tz=0 rtng=0 req=175 to=25 res=121 rt=2 rdy=1 timer=0 probe=0 fail=8 last_failed=1683
2026-09-01 17:55:18     223.5.5.5:53 vrf=0 tz=0 rtng=0 req=30 to=7 res=29 rt=35 rdy=1 timer=0 probe=0 fail=0 last_failed=0
2026-09-01 17:55:18
2026-09-01 17:55:18 DNS_CACHE: hash-size=2048, ttl=1800, min-ttl=60, max-num=5000
2026-09-01 17:55:18 FQDN: min_refresh=60 max_refresh=3600
2026-09-01 17:55:18 FORTIGUARD: vrf=0 mth=auto intf=n/a
2026-09-01 17:55:18 FGD_DNS_SERVICE_LICENSE:
2026-09-01 17:55:18 FGD_CATEGORY_VERSION: 10
2026-09-01 17:55:18 SERVER_LDB: gid=fde2 tz=480 error_allow=0
2026-09-01 17:55:18 FGT SERIAL NUMBER: FG101FTK20007637
2026-09-01 17:55:18 FGD_REDIR_V4: 2026-09-01 17:55:18
2026-09-01 17:55:18 FGD_REDIR_V6: 2026-09-01 17:55:18
2026-09-01 17:55:18 DNS FD: udp_s=8 udp_c=20:21 ha_c=25 unix_s=9, unix_nb_s=26, unix_nc_s=10
        v6_udp_s=7, v6_udp_c=23:24, snmp=27, redir=16, v6_redir=17
2026-09-01 17:55:18 DNS FD: tcp_s=12, tcp_s6=13, redir=29 v6_redir=30
2026-09-01 17:55:18 DNS UNIX FD: dnsproxy_un=31

    重点关注一下字段：

    • req：发送到该服务器的 DNS 请求次数。重传可能作为新的发送计入，因此该值不等于业务查询数量。
    • to：等待该服务器响应时发生的超时次数。一次业务查询可能包含首次发送和重传，因此不能直接用该值计算失败的业务查询数量。
    • res：从该服务器收到的 DNS 响应次数。NXDOMAIN、SERVFAIL 等响应码仍属于已经收到 DNS 响应。
    • rt：dnsproxy 保存的加权延迟值，与 diagnose test application dnsproxy 2 中的 latency 对应。CLI 数值需要乘以 10 才是 GUI 显示的毫秒值。
    • rdy 或 ready：DNS 服务器条目的就绪状态。1 表示该条目已经初始化，可以参与服务器选择或探测，不表示服务器当前一定能够正常响应 DNS 查询。
    • fail：当前服务器失败计数。DNS 查询超时并触发服务器降级时该值可能增加，后续收到成功响应后可以恢复为 0。它不是设备启动以来的累计失败次数，也不存在可以直接套用到所有查询的固定切换阈值。
    • last_failed：距离最近一次服务器失败事件经过的内部时钟节拍。该值越大表示最近一次失败发生得越久，不表示服务器失败更严重，也不能直接按毫秒读取。没有失败记录或失败状态清除后通常显示为 0。

    相关信息

    req、to、res 是累计统计值，rt 是当前加权延迟，fail 和 last_failed 是服务器失败状态。排障时应比较这些字段在多次采样之间的变化，并结合抓包确认请求、重传和响应，不能仅凭某一个字段判断 DNS 服务器是否正常。

计算机制

≥ 7.4.4/7.6.0/8.0.0

FortiGate 只在收到 DNS 响应后更新加权延迟。DNS 请求没有收到响应时，FortiGate 不会直接修改已有加权延迟，但服务器的失败次数、重传和超时计数仍会增加。

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

新加权延迟=已有加权延迟×30%+本次延迟样本×70%\text {新加权延迟} = \text {已有加权延迟} \times 30\% + \text {本次延迟样本} \times 70\%

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

重要

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

< 7.4.4

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

相关信息

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

重要

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

排查方法

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

    diagnose test application dnsproxy 2
diagnose test application dnsproxy 3

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

    execute ping 223.5.5.5
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 已刷新，重传和超时不再持续增加，延迟值随成功查询逐步下降。

最近更新: