本文目前是实验性的机器翻译，可能包含错误。如果有任何不清楚的地方，请参考原始中文版本。我正在持续努力改善翻译。这是“ISP@Home”系列的一个侧面条目，事情正式进入了恶搞领域。如果一些概念或背景感觉解释得不够充分，您可能需要先查看该系列的早期帖子。 前言 想象一下这个场景：某一天，一个神秘的人物（或者可能是一个大型语言模型）发现了主流Linux内核网络栈中的一个RCE漏洞。考虑到Linux的广泛使用，这个单一的缺陷会立即让整个互联网处于崩溃的边缘——每个联网的主机都会遭受巨大的风险。这实在是太集中化了。因此，我相信，在一个真正去中心化的网络中，每个人都应该实现自己独特的网络栈，并用它来访问互联网。这样，即使某个实现存在缺陷或漏洞，也不会导致整个网络瘫痪。 好吧，我再也无法保持严肃的表情。说实话，当我在南京大学学习计算机网络时，我突然产生了为自己写一个网络栈的冲动。觉得DN42的混乱还不够，我决定再提升一个档次，把自己定制的栈部署到DN42上——也许有一天还可以部署到IANA上——提供实际的服务。 DNet 当时我确实写了几篇关于这个项目（DNet）的博客帖子，尽管我没有坚持太久： https://github.com/lyc8503/DNet-core 当时，它或多或少地实现了以下功能： - 在Linux上创建一个TAP设备，发送/接收以太网帧 - 解析以太网帧，处理ARP查找和响应 - 解析IPv4数据包，并响应ICMP回显请求 - 发送和接收UDP数据包 最近，经过四年的废弃，我再次拾起这个项目，修补了一些漏洞，并凑合着搭建了一个勉强能用的DNS服务器，作为我DN42域名42420167.xyz的权威DNS。现在，如果您从任何联网的机器上运行dig TXT sgp1.dn42.42420167.xyz，您会直接获得我手动编写的网络栈提供的DNS响应： ``` # dig TXT sgp1.dn42.42420167.xyz ; <<>> DiG 9.18.39-0ubuntu0.24.04.5-Ubuntu <<>> TXT sgp1.dn42.42420167.xyz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21546 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;sgp1.dn42.42420167.xyz. IN TXT ;; ANSWER SECTION: sgp1.dn42.42420167.xyz. 20 IN TXT "IPv6 LLA: fe80::167" sgp1.dn42.42420167.xyz. 20 IN TXT "PubKey: 8BKrEUrqba9mCzYHqWD2uTNtvrcYcKAls3vBQrY6dxE=" sgp1.dn42.42420167.xyz. 20 IN TXT "MP-BGP: enabled" sgp1.dn42.42420167.xyz. 20 IN TXT "Extended Next Hop: enabled" sgp1.dn42.42420167.xyz. 20 IN TXT "Looking Glass: http://sgp1.dn42.42420167.xyz:5000/" sgp1.dn42.42420167.xyz. 20 IN TXT "ASN: 4242420167" sgp1.dn42.42420167.xyz. 20 IN TXT "Endpoint: sgp1.dn42.42420167.xyz:2xxxx (xxxx是您ASN的最后四位数字)" ;; Query time: 11 msec ;; SERVER: 223.5.5.5#53(223.5.5.5) (UDP) ;; WHEN: Sat Jun 13 22:22:39 CST 2026 ;; MSG SIZE rcvd: 397 ``` 而且，如果您在DN42内部，您可以直接通过IP 172.20.42.224发送任何内容到这个栈，例如：ping 172.20.42.224 在我最后一篇博客帖子中，我将所有VPS实例迁移到了NixOS，使用纯Vibe编码构建。但是，由于我实际上并不懂Nix，它很快变成了一个无法维护的混乱，部署时随机崩溃。经过短暂的犹豫，我决定清空一切，回到Debian。这次，我使用pyinfra（基于Python的基础设施工具）：lyc8503/infra 。在Debian上，我使用Docker Compose管理所有DN42服务（请见这里）。这使我能够使用Docker的网络命名空间来隔离服务——每个容器都在一个“干净”的环境中启动，避免了重复部署所带来的配置漂移的混乱。 后记 好了，就到这里——这篇文章的结束和开始一样突然。这只是我最新恶搞项目的简单展示，这次没有深入探讨代码。最近，我感觉DN42参与者太少。网络的流量主要只是ICMP和BGP——没有真正的应用程序运行，新的恶搞活动也没有太多余地。除非我稍后得到一些新的灵感，否则DN42系列可能就到此为止~