在从事区块链节点运维工作的这几年时间里, dnsseed 这个看起来好像并不起眼的机制, 其实是决定了你的节点是否能够稳定地连接到全网的一个非常关键的环节, 它把域名解析的功能和节点发现的功能紧紧地绑定在了一起, 所以一旦这个环节出现了什么问题, 整个点对点网络就都得跟着发生抖动。
区块链+dnsseed到底怎么被利用的
讲得明白一点就是, dnsseed这个功能的用处在于,让节点去向一台DNS服务器发起询问, 问法大概是“当前有哪些节点处于在线状态”, 接着该DNS服务器就会返回一个包含多个IP地址的列表, 然后节点就会使用这些IP地址去建立连接并完成握手操作, 从表象上看这个事情似乎是很简单的, 然而在发生在2024年那一次关于dnsseed遭受投毒攻击的事件被披露之后, 诸多相关的技术团队才终于意识到, 整个这样的数据传输流程中实际上是几乎不存在任何有效校验机制的, 于是任意处于网络中间位置的恶意对手都可以随意注入一些假的IP地址信息, 这样一来接收方在不知情的情况下就已经连接到存在风险的恶意节点上面去了。
我之前在去年帮忙对一个矿场进行故障排查工作, 其节点是反复出现掉线情况, 整个过程折腾了两天之久。最后才发现是由于运营商对域名进行了劫持操作, DNSseed域名的返回结果是全部为内网地址类型。在之后修改配置并且换成了硬编码形式的节点列表方式以来当天就把这个问题给解决了。
区块链+dnsseed挂了有啥替代
现在大家觉得比较稳妥的做法, 是去采用混合发现这种方式。具体来说, 就是让 dnsseed 只充当一个备用的角色。而主要的工作量, 其实是交给 DHT 和那些硬编码的 bootstrap 节点去处理的。
在以太坊完成了 PoS 合并操作之后, 验证者节点基本上就不再依赖于 dnsseed 了。大家纷纷改而去使用 beacon 里面的 gossip 协议。
如果小团队所能够支配的资源并不是特别富裕的话, 将三到五个具备可信性质的节点IP地址直接写死在配置文件之中, 这种做法实际上比任何其他的方案都要来得更加稳妥一些。请千万不要仅仅是为了去追求所谓的那个“去中心化”的概念性的东西, 从而就把本应该属于自身的安全属性给放弃掉。
dnsseed这并不是说就不能够用了, 但是请千万不要把它看作是唯一的命脉所在。
