我也喜欢直接写 SQL 因为本质上就是和数据库打交道，SQL 才是最直观的 “官方语言”
数据库调试好，稍微修改一下到程序就能用，看代码也流畅
个人是比较反对使用程序框架包一层的，最主要的问题是会影响或者打断思路，大量的语法糖会导致开发脱离真实的世界，框架生成的代码质量也不一定可控。数据库关系都搞不清楚，后期维护越来越迷糊。

@yqdhm 这个项目凉了。。。

我是一名有着 15 年经验的业余程序员，虽未在像 V2EX 这样的专业平台与大家以代码会友，但我也认真研究了您的源代码。在此，我想先谈谈对您作品`dns-bechmark`的一些看法。

您的`dns-bechmark`作品是这样运行的：它以`dnspyre`（目前 star 数为 124 的 DNS 压力测试工具，https://github.com/Tantalor93/dnspyre ）为核心，通过 Go 语言调用外部`dnspyre`命令。这个工具会对自行收集的 DNS 服务器列表进行测试，测试时利用世界排名较靠前的 1000 个域名（ https://github.com/Tantalor93/dnspyre/blob/master/data/1000-domains ）进行并发解析。在这个过程中，`dnspyre`会输出测试的 json 结果，您的作品会解析这些结果，并结合自身的评分体系对 DNS 服务器进行评分，同时使用 GEOCODE 分类，最终生成结果 json 文件。最后通过 Web 前端读取结果，并按照评分高低进行可视化展示。

不过，这个作品存在一些问题。

首先是关于评分算法与网络性能相关的问题。作为核心的压力测试工具`dnspyre`，其本身无法规避网络性能问题。您在评分算法中设置的`LatencyRangeMax`、`LatencyRangeMin`、`LatencyFullMarkPoint`这三个算子都和网络延时密切相关。这就导致了按照您的算法，像 1.1.1.1 这样的 DNS 服务器得分远低于 223.5.5.5 ，但这与实际情况并不相符。

其次，使用`dnspyre`对公共 DNS 进行高频查询存在问题。暂且不考虑这种行为是否符合道德规范，这种高频查询会浪费公共资源。而且当单 IP 高频次查询达到一定程度时，必然会触发 DNS 服务商的防火墙，这会进一步影响评分算法的结果。

再者，您的评分算法只考虑了`errorRate`，却没有考虑解析结果的准确性，也没有考虑诸如 DNS 劫持等情况。我们都知道，在国内由于一些特殊原因，查询 Google 、Facebook 等域名时，即使局域网内配置了旁路由进行 IP 分流/cache ，RTT 几乎都是 1ms ，但这显然不符合真实的网络解析情况。

最后，在对 DNS 服务器地址使用`net.LookupIP(server)`进行解析并返回 geo code 进行分类时也有问题。因为`net.LookupIP`本身会依赖系统的 resolver 进行解析，也就是会依赖系统默认的 DNS 。然而很多公共 DNS 是在多国部署的，这样做会导致地区分类不准确。

总结来说，您的`dns-bechmark`作品有其亮点。您精心收集了全球很多 DNS 服务器，并利用`dnspyre`进行压力测试，最后将结果汇聚并进行了可视化展示，界面还算美观，这在一定程度上可以为本地优选服务器提供参考。但需要注意的是，如前文所述，影响评分结果的主要因素是网络延时，所以这个结果只能体现本地到“世界 DNS”的性能，仅对本地网络有参考价值，缺乏分享和对比价值。毕竟，通常情况下速度最快的 DNS 往往是本地宽带运营商提供的。此外，您的评分只考虑了 QPS 、延时、错误率等指标，没有对解析结果、应用层 RTT 等结果进行校验，这就可能导致得分最高的 DNS 服务器未必能提供最好的解析结果。还有一点，鉴于您的作品并非 100%原创，尤其是核心的`bechmark`程序`dnspyre`，希望您能在 README 文件中对`dnspyre`进行相关引用并致谢，这符合开源社区的礼仪规范。

--- 感谢豆包对人类回复进行了润色 ---

@bigtear 专不专业不是您自认的，V2 都是行内人士懂的人一眼便知道你作品的问题所在。如果连数据都是错的，一切的什么可视化、评价体系就是 s 上雕花，毫无价值。

@bigtear dns-jumper 这种表格有数字还能排序的形式还不够直观 ☺️ 最关键的问题我因为说了，你的单一网络本身就是最大的瓶颈，响应速度几乎就是你的网络延迟。 加上 dns 服务器普遍都会存在防火墙，类似 223.5.5.5 还有每日，每小时限速测率，还没有考虑 isp 对 53 等端口的特殊关照，所以说您做这个小工具也就是有个图表能看看而已，意义其实并不大，放到任意用户的手里结果都会不一样的。但是作为练手的作品，我是非常肯定您的想法和动手能力的，起码东西做出来了。

@ysxb1145 哥们我那里黑了，我只是说兜底。另外，国行手机你弄两个外网的 dns 你觉得这合理呢？

小米/oppo/vivo 等国产手机无论你 dhcp 配置什么地址，都有一个 114.114.114.114 作为兜底，供参考。

首先，肯定楼主的工作和探索精神 👍，但是家庭或者非专业监控机构，去监控全世界的 dns 个人觉得意义不大，dns 服务器一般都是用运营商就近提供或者使用大厂的 DNS ，对于单一网络条件下去测试全球的 QPS 和成功率，自身网络就是瓶颈，数据没有参考价值。

如果是普通用户挑选优质 DNS ， 在 Windows 平台且只用于临时测试，希望测速后一键切换
友情推荐免费 dns-jumper : https://www.sordum.org/7952/dns-jumper-v2-3/3/#8

https://imgur.com/klvZrWV

这个问题我也疑惑过，因为 ipv6 的 nd 时间不固定，我抓鬼也抓了很长时间，终于被我抓出来了 -_-

1 、调试工具： https://www.remlab.net/ndisc6
2 、这个地址实在太熟了，最终结论就是 [ Apple TV ] 目的是要做智能中枢网关（ https://discussions.apple.com/thread/252823422 ）

刚才我看了一下 D840N 的后台管理页面，确实没有像 F7005TV3 的上行光模式 XEPON/XGPON 切换选项，这个只能查看其它类似案例自行探索了，实在不行就只能换 zte 7005 、7015 了

- https://www.chinadsl.net/thread-176170-1-1.html

已经发现 sing-box / dae 都存在这个问题，无解。已经转投 mihomo ，多种负载均衡模式、自定义健康检查、更灵活的分流特性，yaml 格式能写注释不用 json 到处找闭合括弧。跑了快一个季度，因为健康检查功能过于强大，我都忘记梯子没续费了机器都被释放掉了 -_-

推荐：创维 SK-D840N

- 和 F7005TV3 使用同款芯片（本质就是 zte 套壳产品），同样兼容 xgpon / xepon 但是温度低 10-20 度（界面显示）
- 原生固件有 telnet 不需要第三方工具破解
- 带 USB 接口可备份配置文件而无需 tftp 导出，关键时刻或许能救砖
- 已通过 sismac （等同 zte setmac ） 命令 修改 mac / gpon-sn / loid / olt password 等关键信息，在联通/移动/电信 三网测试联网通过，并已经稳定运行数月
- 价格和 F7005TV3 相当

拆机参考： https://www.acwifi.net/28378.html

23 年换了 32 部花了 15 万+ 😂 （实际使用 2 个月以上，不包括 7 天无理由）

https://i.v2ex.co/49ihP4s2.png

发布会只字没提,16 全系其实支持 Wi-Fi 7 满血的话网速能破 2Gb/s （来源：Apple Store 商品详情页 ）

https://i.v2ex.co/43SiwY6ml.jpeg （熔接式）

https://i.v2ex.co/Ldrd1Z8Cl.jpeg （冷接式）

但是需要师傅调整入户光衰（找上一级的端口），否则光猫会光不足亮红灯。

先说结论：ROS 自带 DNS 不能解决这个问题

原因分析：当 pppoe 拨号或者通过 ipv6 dhclient ,勾选 use peer dns 会将 v4/v6 的服务全部压入 Dynamic Servers 中，根据从上到下的原则往上游发出查询，例如：移动在第一个，那么 ROS DNS Server 永远都只会返回移动的 A 或者 AAAA 记录，联通的线路很大概率用不到（只有 fallback 的时候），线路利用率低。这里还有一个问题，就是 223.5.5.5 默认走的线路是什么？当 223.5.5.5 走的是移动线路，查询出的节点都是移动的，将移动的解析结果返回给 2.x 走联通线路的机器，明显是不科学的。

解决方案：使用中立的在内网部署中立的第三方 DNS ，例如 smartdns （推荐） 、mosdns 等，通过同时配置多组运营商上游，合并记录并测速后返回多个运营商 A / AAAA 记录，做到流量负债均衡（取决于客户端实现）

以 smartdns 的配置作为示范：
```
bind :53
...
server <移动 DNS 1> - group isp -group cmc
server <移动 DNS 2> - group isp -group cmc

server <联通 DNS1> -group isp -group cuc
server <联通 DNS1> -group isp -group cuc

server 119.29.29.29 -group publicdns

server 8.8.8.8 -group free -exclude-default-group
....

max-reply-ip-num 8
speed-check-mode tcp:443,ping
....
```
因为您已经根据 IP 做了策略路由，所以 <移动 DNS> 返回的必然是移动的节点， <联通 DNS> 返回的必然是联通的节点（取决于网站 CDN 是否布点），对于“不拆分网段的机器”一下就能利用到移动和联通的全部记录，高效利用带宽资源。

根据你的需求，似乎根据根据网口/网段做了策略路由，不同网段走不同出口，这台 smartdns 完全能复用。

1 、为 smartdns 配置两个 IP 让两个网段都能访问到 类如 eth1：192.168.1.253/24 eth2: 192.168.2.253/24
2 、利用 smartdns 的 client-rule 特性做分流: https://pymumu.github.io/smartdns/config/client-rule

```
acl-enable yes
...
# 启用规则组
group-begin cmc
client-rules 192.168.1.0/24
server <移动 DNS 1> -e
server <移动 DNS 2> -e
domain-set -name gfwlist -type list -file /etc/smartdns/domain-set/gfw.list
domain-rules /domain-set:gfwlist/ -nameserver free -speed-check-mode none -address #6
group-end

group-begin cuc
client-rules 192.168.2.0/24
server <联通 DNS 1> -e
server <联通 DNS 2> -e
domain-set -name gfwlist -type list -file /etc/smartdns/domain-set/gfw.list
domain-rules /domain-set:gfwlist/ -nameserver free -speed-check-mode none -address #6
group-end
```
3 、根据不同网段配置 dhcp-server 下发 smartdns 的 IP (1.253 / 2.253) 即可，这样既可以使用独立的 dns ，也能复用 gfwlist 、adlist 等分流、屏蔽设施。

1G 的情况下其实区别不大，主要是线材长短和功耗的问题，这种场景下我认为普通网线有价格和兼容性优势。

10G 以上就有对比了，线缆方面主要分 DAC 和 AOC ，其中 DAC 还分为有源和无源。

- 延时方面：DAC < AOC < 10G BaseT
- 功耗功耗：DAC < AOC < 10G BaseT
- 通讯距离：AOC > 10G BaseT > DAC

个人结论，家庭组网，不具备恒温恒湿的场景下：

- 短距离连接 (无源 <7m ，有源 <7-15m) [DAC 电缆，无论延迟、功耗、散热、价格，有绝对的优势]
- DAC 存在设备的兼容性问题，采购时有试错成本.
- 光纤组网战未来

参考资料：
-《 Data Center Cabling Solution: DAC Cables vs AOC Cables 》 https://community.fs.com/article/guide-to-10g-dac-and-aoc-cables.html
-《 10GBASE-T vs. SFP+ vs. DAC: Which is the Best for 10GbE Data Center Cabling?
》 https://www.qsfptek.com/qt-news/10gbase-t-vs-sfp-vs-dac-which-is-the-best-for-10gbe-data-center-cabling.html