DNS信鸽协议：我研究过的最离谱网络标准

先说个丢人的事：我花了大量时间研读IETF的一篇草案，内容是关于"DNS over Avian Carriers（DoAC）"的——就是用信鸽传DNS数据包。我一点都不后悔花这个时间。

可能有人不了解，IETF就是制定互联网技术标准的那帮机构。他们的文档一般都很严谨、很正式。所以当你在里面看到一份正经提案，说要用信鸽来解析域名，你会忍不住多看两眼——不是因为这玩意儿实用，而是因为它揭示了一些关于网络协议本质的有意思的东西。

被时间遗忘的协议栈

故事要从1990年说起。那年IETF发布了RFC 1149，引入了"IP over Avian Carriers"——用信鸽传输IP数据包。是的，你没看错，IETF正式发布了一份用信鸽传数据的规范文档。文档里甚至还有丢包率估算（"大约55%非加权丢包"）、延迟计算和吞吐量对比。2001年又更新了RFC 2549（信鸽服务质量支持），2011年再来个RFC 6214（IPv6兼容性）。

这些可不是闹着玩的——是正经的实验性协议，有实际实现，也做过真机测试。大学和黑客社区还真有人部署过基于信鸽的网络，就为了玩和教学。

但问题来了：三十年来，这个协议栈有个巨大的缺口。你可以用意念传IP数据包，但没法解析域名。没有DNS，每个目的地都得直接刻在信鸽身上，写成IP地址。想象一下跟网络运维说，新增一台服务器需要重新训练信鸽，那场面得多魔幻。

DoAC：为鸟类量身打造的DNS

DoAC草案就是来填这个坑的。它定义了：

• DNS查询和响应的消息格式，可以绑在信鸽腿上
• AA（Avian Authority）资源记录，用来发布鸽舍地址
• 重传行为规范，考虑到了鸟类快递的不确定性
• 引导程序，包括"最后的信鸽"用于初始解析器发现

细节处理得相当到位。第5.2节讨论"无状态解析器发现"，承认了你的第一只信鸽不知道去哪找DNS服务器——因为它没法用DNS来查DNS。解决方案呢？一只预装好的紧急备用信鸽。

听起来像动物世界的安全分析

DoAC最精彩的部分是它的安全分析。草案识别出了以下威胁：

• 中间鹞攻击（Hawk-in-the-Middle）——猛禽在半路截胡你的查询
• 信鸽欺骗——解决方案是"羽毛认证"
• 鸽舍劫持——攻击者控制你的目的地
• 飞行拒绝攻击（DoF）——相当于DDoS，但攻击对象是鸟
• 饥饿猫咪作为物理层威胁——这个不用多解释
• 用标本信鸽重放攻击——有人把一只死信鸽绑上旧的缓存响应再发出去

我真愿意花钱看红队试试这些攻击手法。

这玩意儿到底告诉我们什么

关于这种离谱的技术文档，有件事很有意思：它们往往比正经文档更有启发性。DoAC逼着你面对那些你根本没意识到的默认假设。

你用DNS的时候，其实隐含信任了这些：

• 运营商的解析器不会骗你
• 数据包不会被拦截或篡改
• 服务器在你需要的时候在线
• 物理基础设施不会突然挂掉

DoAC把这些隐含信任全部摆到台面上——然后让你看到这有多荒谬。信鸽网络对生产系统来说毫无意义，但设计它这个过程本身，揭示了我们有多依赖那些被视为理所当然的基础设施。

真正的收获

对于做现代系统的开发者来说，尤其是那些搞边缘计算、网状网络或间歇性连接的，这里有个教训：

每个协议都依赖某种底层传输，它有自己特定的属性。当这些属性变了，你就需要新的协议。

DNS over TCP/IP假设的是可靠、快速的数据包传输。DNS over Avian Carriers假设的是……你的数据包最终能到，可能吧，也许。对于初创公司来说，如果你的应用面向新兴市场、农村地区或灾害场景，理解这些权衡是很重要的。IETF花了30年思考当你的网络是一群鸽子的时候会发生什么。这项工作可能比你想象的更有现实意义。

你有没有遇到过让你质疑网络工作原理的协议？在评论区分享一下你觉得离谱的RFC吧。还有，如果你真的捡到一只绑着DNS记录的标本信鸽，也告诉我们后来怎么样了。