本文主要介绍递归DNS的SRTT本身机制及如何进行更进一步的优化，来达到更好的递归效果。都是字，不想弄图、表和数字，格式也有点乱，不想整理了，凑合看吧

1. SRTT本身机制

本节仅对SRTT进行简单的介绍供了解，不进行特别深入和详细的分析。

SRTT（Smoothed Round-Trip Time，平滑往返时延）是在递归DNS系统里，用加权平均算法计算出的上游DNS服务器的“响应时延”估值，它用于优化解析性能和选择最快的上游服务器。

延伸阅读

BIND的SRTT机制总体做的还是相对比较好的，可以参考 https://developer.aliyun.com/article/622410。

而Unbound社区版的SRTT做的则不够好，基本就是可用权威IP完全随机，递归的平均延迟非常高，所以在实际业务使用前必须进行优化，具体算法优化可以参考相关论文或BIND的实现等。

虽说递归DNS选择权威服务器时都希望选择延迟更低，但在最大限度降低递归时延的前提下，也要遵循一定的规则，如

需要有一定的随机性选择非延迟最低的权威IP来自适应权威IP的RTT的波动和服务器的突然故障。
- 如某个权威IP正常RTT很低，但偶发丢包被惩罚延迟后，需要能够逐步平滑降低其RTT。
- 如果低RTT的权威IP突然故障，除了丢包惩罚延迟外，还需要随机性来选择其他权威DNS IP，防止单个IP不可用导致整个域名解析异常。
标记不可用的IP也需要定时发送DNS请求。
- 不可用的IP恢复可用后需要使用该机制探活标记为恢复可用
- BIND和UNBOUND都会在15或30分钟完全重置一次权威IP的相关状态，其中包括RTT，以及IP的EDNS支持状态等。
- 也可以低频率的对惩罚到标记不可用的IP做并发异步的DNS探活请求。
不能向单一权威IP发送过于集中的请求，降低被权威封禁递归IP的概率。
- 一个可探讨的方案介绍：如果本次不进行随机选择递归IP，选择最低RTT的IP时候再进行二次选择，1/2直接选择最低RTT的权威服务器，1/2在最低RTT差距一定范围内（如minrtt + 20ms，也认为有比较低的延迟）的其他权威服务器IP中随机选择。
- 国内的各大权威DNS服务商的服务只要不是真实的攻击，常规的SRTT优化很是很难触发递归IP被封禁的场景的，但是一些单位、机构等自建的权威DNS，如果单个IP请求量较大则比较容易触发，所以这里也是递归DNS必须要考虑的一种场景。

2. SRTT的配套机制优化

只有SRTT本身的选择机制对一个递归DNS是不够的，还必须配合多个其他配套系统来使用，而这些配套系统对递归DNS的整体递归时延也是非常重要的。

2.1 某个权威DNS IP的SRTT生效范围

在实际业务中，存在以下两种场景会使多个域名使用相同的权威DNS IP

不同的域名会使用相同的NameServer(NS)
不同的域名使用的NS不同，但NS对应的IP相同（如腾讯云解析/DNSPod提供的个性化NS功能）

在我们的常规认知中，既然权威DNS IP相同，那么统一进行SRTT的探测和选择即可，这样多个域名的平均递归延迟都可以有效降低，如在每次权威IP状态重置后快速重新探测到RTT最低的权威DNS IP，且对所有域名生效。

但现实是相反的，多数递归DNS对这种场景的权威DNS IP探测是域名相关的，不同域名的权威DNS IP即使相同，也是分别独立探测和存储状态的（如Unbound的）。

对于某些特殊场景，这种做法可能有一定用处，如同一个IP对域名A支持EDNS，对域名B不支持等，但这极大增加了递归DNS解析时延（也浪费了一些内存，虽然现代服务器不怎么在意了）。

目前腾讯云/DNSPod的递归服务器的做法是所有域名只要权威DNS IP相同即共享一份SRTT的探测和选择结果，可以大幅提高选择RTT低的权威DNS概率（尤其是请求量不大的域名），降低解析延迟，不考虑一些特别极端的场景（也可以解析，但可能不是最优的结果，且此类极端场景在国内的权威DNS服务商中基本不存在）。

2.2 权威DNS IP的GEO优化

大家都知道普通域名的DNS解析可以做智能解析(分线路、GEO、基于延迟等)，来给不同地域不同运营商的客户端分配不同的解析结果，达到降低延迟或节省成本的目的。那么对于给递归DNS使用的NameServer(NS)域名是否可以使用智能解析，来达到同样的目的呢？毕竟因为各种原因，国内大部分权威DNS服务商很难完全使用完全相同的Anycast IP在全球同时提供很高的高可用和很低的延迟，如果该方案可行，则权威DNS服务商有了一个变通的方式来同时满足高可用和低延迟的需求，如除了Anycast IP外还可以在不通地区提供一些本地的Unicast IP来降低本地递归DNS的访问延迟，比如目前腾讯解析/DNSPod和阿里云解析都做了该操作，那么效果如何呢。

答案是一半一半。

递归获取一个域名的权威DNS的NS IP有两个渠道，胶水记录和权威服务器的记录，其中NS域名在注册商/局设置胶水记录不支持智能解析，而在其本身权威DNS设置的解析记录则是可以支持设置智能解析线路的，下面分别进行介绍。

2.2.1 注册局的TLD服务器返回的glue record

胶水记录（Glue Record）是一种特殊的DNS记录，用于解决域名解析过程中的循环依赖问题。当域名的权威DNS服务器（NS记录）是当前域名的子域名时，胶水记录是必须存在的（如后续示例所示），由域名所有者直接在注册商/局（父域DNS，如.com的TLD服务器）中提供子域名服务器的IP地址，确保递归DNS能够正确找到目标的权威DNS服务器。

dig @a.gtld-servers.net ns3.dnsv5.com

; <<>> DiG 9.11.26-RedHat-9.11.26-6.tl3 <<>> @a.gtld-servers.net ns3.dnsv5.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45009
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 11
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns3.dnsv5.com.                 IN      A

;; AUTHORITY SECTION:
dnsv5.com.              172800  IN      NS      ns3.dnsv5.com.
dnsv5.com.              172800  IN      NS      ns4.dnsv5.net.

# 因为NS域名ns3.dnsv5.com是请求域名dnsv5.com的子域名，此时胶水几率是必须返回的，否则后续继续向TLD服务器请求ns3.dnsv5.com还是返回上面两条NS记录,造成死循环
# 只返回tld相同的ns3.dnsv5.com的胶水记录，而不返回ns4.dnsv5.net的胶水记录
;; ADDITIONAL SECTION:
ns3.dnsv5.com.          172800  IN      A       1.12.0.17
ns3.dnsv5.com.          172800  IN      A       1.12.0.18
ns3.dnsv5.com.          172800  IN      A       1.12.14.17
ns3.dnsv5.com.          172800  IN      A       1.12.14.18
ns3.dnsv5.com.          172800  IN      A       101.227.168.52
ns3.dnsv5.com.          172800  IN      A       108.136.87.44
ns3.dnsv5.com.          172800  IN      A       163.177.5.75
ns3.dnsv5.com.          172800  IN      A       220.196.136.52
ns3.dnsv5.com.          172800  IN      AAAA    2402:4e00:1470:2::f
ns3.dnsv5.com.          172800  IN      A       35.165.107.227

;; Query time: 217 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Fri Aug 15 15:59:20 CST 2025
;; MSG SIZE  rcvd: 255

TLD服务器一般只有请求的域名的TLD和本域名设置的NS的TLD一致，会返回胶水记录的（这里大部分其实是非必须的，但是同时返回了胶水记录可以减少一次额外的请求，降低延迟），否则一般不返回胶水记录。如example.com设置NS为ns1.example.com, ns2.example.net, 那么这时候向TLD服务器请求example.com的时候，TLD服务器就会返回example.com的NS记录ns1.example.com和ns2.example.net，且同时返回ns1.example.com的A和AAAA记录（TLD相同，都是.com)，但并不会返回ns2.example.net的胶水记录（TLD不同, .com vs .net)，如上述和下述请求所示

dig @a.gtld-servers.net dnsov.net

; <<>> DiG 9.11.26-RedHat-9.11.26-6.tl3 <<>> @a.gtld-servers.net dnsov.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8363
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 11
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dnsov.net.                     IN      A

;; AUTHORITY SECTION:
dnsov.net.              172800  IN      NS      ns3.dnsv5.com.
dnsov.net.              172800  IN      NS      ns4.dnsv5.net.

# 只返回tld相同的ns4.dnsv5.net的胶水记录，而不返回ns3.dnsv5.com的胶水记录,但其实这里的胶水记录并不是必须要返回的，因为dnsov.net和dnsv5.net是两个不同的域名，再次请求并不会造成死循环，但是同时返回了胶水记录可以减少一次额外的请求，降低延迟
;; ADDITIONAL SECTION:
ns4.dnsv5.net.          172800  IN      A       1.12.0.16
ns4.dnsv5.net.          172800  IN      A       1.12.0.19
ns4.dnsv5.net.          172800  IN      A       1.12.14.16
ns4.dnsv5.net.          172800  IN      A       1.12.14.19
ns4.dnsv5.net.          172800  IN      A       112.80.181.106
ns4.dnsv5.net.          172800  IN      A       117.135.128.152
ns4.dnsv5.net.          172800  IN      A       124.64.205.152
ns4.dnsv5.net.          172800  IN      A       13.37.58.163
ns4.dnsv5.net.          172800  IN      AAAA    2402:4e00:111:fff::8
ns4.dnsv5.net.          172800  IN      A       49.7.107.152

;; Query time: 192 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Fri Aug 15 16:00:30 CST 2025
;; MSG SIZE  rcvd: 261

这里未介绍子域名授权场景的胶水记录，总体原则是一致的。

2.2.2 NS域名本身权威服务器返回的IP记录

NS域名（如ns3.dnsv5.com）在其权威DNS（如腾讯云解析/DNSPod）设置解析记录的时候，和普通域名可以一样设置智能解析(如境内设置一批IP，境外设置另一批IP等)，和普通域名的使用没有区别。

2.2.3 递归DNS的行为及优化

递归DNS在进行迭代查询时，有可能从TLD服务器直接获取到NS域名的胶水记录，也可能从权威DNS获取，且两处获取的记录可能不同（部分检测系统会告警，但忽略即可），而权威DNS设置的IP支持智能解析，提供了更大的优化空间，一般相比胶水记录是更好的选择（且非专业技术人员常常忽视对胶水记录的维护），那递归DNS如何使用和优化呢。

常规的递归DNS（如BIND和UNBOUND）一般是这种行为（会略有不同，总体行为类似）

如果向TLD服务器请求某个域名时，TLD服务器同时返回了NS的胶水记录，那么直接使用胶水记录作为NS的IP，不会再去向NS的权威请求记录
如果向TLD服务器请求某个域名时，TLD服务器没有返回NS的胶水记录，则再去正常查询NS域名的记录时，可能回会权威请求NS记录，获取到权威可能设置的分线路智能解析结果，从而后续优先使用权威返回的解析记录
有用户向递归DNS显示请求NS域名的A/AAAA记录，那么递归DNS必然会向NS域名的权威请求一次NS的A/AAAA记录（胶水记录不是其域名权威返回的，用户显式的请求去需要去获取权威设置的记录，而不能直接返回缓存的胶水记录），获取到权威可能设置的分线路智能解析结果，从而后续优先使用权威返回的解析记录
如果权威返回的解析记录全部不可用，则重新回退到使用胶水记录提升可用性

可以看出来，常规的递归DNS不会主动去获取权威DNS的分线路智能解析结果，只会在被动获取到权威返回结果的时候，代替胶水记录进行优先使用，从腾讯云解析/DNSPod使用的实际效果看，权威解析才会设置的解析IP的流量比例总体并不低，这样设置还是有比较好的效果的（具体数据就不提供了）。

那对递归DNS能不能更进一步的进行优化呢，当然可以

即使递归DNS从TLD服务器获取到了NS域名的胶水记录，在正常向胶水记录IP发起查询请求的同时，也自动异步去解析NS域名在权威的A/AAAA记录, 使用NS权威解析记录的比例可以大幅提高。
- 根域名、TLD域名以及海外大厂的NS等域名不必做这个操作，因为记录一般都是一致的Anycast IP
- 腾讯云/DNSPod所有对外提供服务的公共DNS、HTTPDNS、DoH、DoT、云内网DNS等的后端递归DNS都支持该项优化

本文就不写运营商递归DNS和相对比较知名一些的公共DNS了，通过几个case聊聊2024年当前可以应答DNS请求、在国内用户量不小，但是又搜索不到什么公开信息的一些”小众“递归DNS的那些事儿，部分已经无法访问的递归DNS就不再包含进来了。这些递归DNS的用户体量并不比不少知名公共DNS小，只是基本不为人知，关注该领域的可以大概了解下。

使用这些DNS比较容易出现解析线路不准确（如国内用户解析到国外IP）、域名被劫持等场景，因为让所有用户修改DNS并不现实，一般还是更建议有端的客户端（如APP等）尽量使用HttpDNS或其他技术手段规避类似场景。

【注1】本文部分线索来自其他伙伴。

【注2】本文所有数据为简单测试，仅供参考。

case 1：183.2.x.x

该DNS疑似某供应商为园区、公司等场景提供的递归DNS，在本省的使用率不低。在24年5月的时候测试，使用该DNS会大概率将域名解析到国外的IP，会导致终端用户访问延迟升高，也造成该省份域名解析到国外IP的概率略微高于其他省份。但是在24年下半年测试没什么大的问题了，可以正常解析为本省份结果，只是解析结果没有区分运营商，基本不影响正常使用。

下图分别为24年5月和12月的测试递归DNS出口IP的结果对比

case 2：45.14.x.x、45.128.x.x

该组递归DNS分布于多个C段，多个海外其他国家，目前看国内各省份运营商皆有固网/wifi用户访问，设置比例大约在小万分之x，使用移动网络则不会访问该组递归DNS，疑似从2024.12.04 16:00+开始对外提供DNS解析服务。

该组递归DNS后端在进行递归请求时固定携带127.0.0.1作为ECS IP，大部分域名可以解析到默认线路，无省份运营商区分，解析到国外IP的概率倒是不高。

该组DNS貌似会随机劫持某些域名到其他IP，并302跳转到其他违规网站。历史测试截图如下。

【注3】截止本文时间（2024.12.18），之前历史被劫持域名已经没有被劫持，且之前被劫持到的相关IP也已经无法访问，疑似已经被处理。

case 3：154.86.x.x

该组递归DNS分布于多个C段，部署于中国香港，目前看国内各省份运营商皆有固网/wifi用户访问，设置比例大约在小千分之x，使用移动网络则不会访问该组递归DNS，具体对外提供服务时间则不确定。

该组递归DNS后端在进行递归请求时会随机转发给国内外多个其他公共DNS,且并未携带ecs，大部分域名的解析结果IP为国外IP，会导致终端用户访问延迟升高，递归DNS后端出口IP测试结果如下所示，其中包括Google、UltraDNS等其他的公共DNS的递归出口IP

该组DNS因为是纯转发，所以部分特征会测试到转发目标公共DNS的特征，如NeuStar家的UltraDNS，但实际并非该集群本身的版本特征，也并非转发目标公共DNS部署的DNS缓存转发服务，部分特征测试结果如下所示：

dig version.bind chaos txt @154.86.x.x +short
“1733297354.ultradns”
dig hostname.bind chaos txt @154.86.x.x +short
“rcrsv2.jptyo1.ultradns”

dig version.bind chaos txt @154.86.x.x
version.bind. 86400 CH TXT “PowerDNS Recursor 5.1.1 (built Jul 22 2024 13:49:14 by root@localhost)”

dig version.bind chaos txt @154.86.x.x +short
version.bind. 75428 CH TXT “Q9-P-7.6”

该组DNS貌似会随机劫持某些过期域名到其他IP，并302跳转到其他网站（有点类似纠错页），当前（2024.12.18）跳转的目标网站实测无法访问，也未找到历史网页内容，且很多安全情报都会报告风险并进行访问拦截，没有什么实质性的影响。

标签：递归DNS

递归DNS如何选择权威DNS的IP-SRTT优化及实践