从DNS安全培训师到ICANN87研究员：一个安全工程师的巴厘岛议程

互联网的地址簿要开会了

大多数人从未听说过ICANN。每次你打开网站、发送邮件，或者让一个AI代理去抓取URL，背后都得先把名字转换成地址——这套系统就是DNS。ICANN协调的是这套系统最顶层的部分：根区、顶级域名的规则，以及决定名字如何分配、被滥用时如何处置的政策制定工作。

真正让我意外的是这些规则由谁写。不是某一家公司或政府说了算，而是政府、像PANDI这样的注册管理机构、注册商、安全顾问和普通互联网用户各占一席，在公开会议上协商。ICANN87就是这样的会议之一，而年度大会是全年规模最大的一场。

据一位长期担任PANDI（运营印尼.id域名的注册管理机构）.id Academy培训师的网络安全工程师记录，他将在ICANN87期间以PANDI研究员身份出席，地点是努沙杜瓦的巴厘岛国际会议中心。

DNS（域名系统）本质上是一套分布式的层级数据库，负责把人类可读的域名（如 example.com）翻译成机器可路由的 IP 地址。它从根区开始，向下依次是顶级域名（TLD，如 .com、.id）、二级域名和更细的子域，每一层由不同的机构独立管理，形成所谓"委派"结构。正因为这种分层设计，DNS 没有单一控制点，也就无法由某家公司或某个政府单独说了算。ICANN 成立于 1998 年，作为非营利机构承担"协调"而非"控制"的角色——它不拥有 DNS，只是维护根区的权威数据、制定顶级域名政策，并主持多利益相关方（multistakeholder）的协商流程。ICANN 的年度大会通常与政策论坛或社群周结合举行，是全球域名政策讨论最集中的场合。

我的出发点：防御者的收件箱

我不是政策人。我的日常工作是安全工程，大部分时间都在DNS问题的接收端。一封可疑邮件进来，我首先看发件人域名：注册多久了？是不是把某个真实品牌换了一个字母？上个月是否存在过？仿冒域名是我处理钓鱼攻击时的主要部分，所以我在DNS的滥用侧花了大量时间，却从没看过运营方是怎么思考这个问题的。

工作之外，我从2024年起担任PANDI的.id Academy培训师，在万鸦老的UNIMA和巴淡的ITEBA办训练营。学员里有学生、讲师，也有刚给小生意买了.id域名的人。近来我工作中越来越大的一部分是AI代理和MCP安全，这让DNS以一种我没预料到的方式重新回来。能浏览网页或调用工具的代理同样要解析域名，它信任答案的方式和浏览器一样，而且往往没有人在看之前先瞥一眼链接。

MCP（Model Context Protocol）是近年提出的一种开放协议，用于让 AI 模型以标准化方式连接外部工具、数据源或服务。可以把它理解为"AI 代理的插头标准"：代理通过 MCP 服务器调用搜索、数据库、文件系统等能力，而不必为每种工具单独写集成代码。从安全视角看，MCP 带来一类新问题——代理会在用户看不到的链路里发起网络请求，其中就包括 DNS 解析。攻击者可能通过恶意 MCP 服务器返回被篡改的结果，或诱导代理访问仿冒域名。由于代理通常不会像人那样"先看一眼链接"，DNS 层面的钓鱼和域名仿冒对代理的威胁可能比对人类用户更隐蔽，这也是作者关注 AI 代理与 DNS 交汇的原因之一。

我在巴厘岛想找什么

从政策侧看DNS滥用。 我知道滥用在一个收件箱里长什么样，但对注册管理机构和注册商如何界定滥用、多快必须响应、哪些地方会变得棘手（比如误报，或者把一个其实合法的域名下架）了解甚少。我想听每天处理这些问题的人怎么争论。

真实部署中的DNSSEC。 在培训师培训里我们学了DNSSEC如何给DNS应答签名，让解析器能判断是否被人篡改。ICANN会议通常有DNSSEC与安全研讨会，我想听运营者讲实践中哪里会坏。我的学生问过这个问题，而我现在只有教科书答案。

我给每个学生准备了一组可以对自己域名跑的检查命令：

DNSSEC 通过数字签名机制解决 DNS 的一个根本缺陷：传统 DNS 应答没有任何完整性校验，中间人可以伪造应答把用户引向恶意地址（即缓存投毒）。启用 DNSSEC 后，区域会为每条记录生成 RRSIG 签名，解析器沿信任链（从根区的信任锚逐级向下）验证签名，验证通过才会在应答头部设置 AD（Authenticated Data）标志。不过 DNSSEC 在真实部署中存在不少痛点：密钥轮换操作复杂、算法过期（如早期的 SHA-1 签名方案）、部分注册商与注册管理机构之间的 DS 记录同步延迟、老旧解析器不支持验证等，都会导致域名"签了但不生效"或被误判为不安全。正因如此，运营者的一线经验往往比教科书更有价值。
# 区域是否已签名？应答里有RRSIG记录就说明签了。
dig +dnssec SOA .

# 我的解析器会验证吗？看头部有没有"ad"标志。
dig +dnssec icann.org A

AI代理作为DNS客户端。 这更多是一个直觉而非计划。代理正在变成重度DNS用户，而没有人是有意这么决定的。我好奇ICANN社区是否已经在讨论这件事；如果没有，这是否能出一篇有用的论文。

我想带回去的东西

PANDI要求每位研究员把这一周变成一份贡献，写成论文。我很喜欢这个安排，它给这一周一个交付物，而我有交付物时状态更好。我的粗略计划是一个循环：倾听，把听到的和工作中看到的连起来，为PANDI写出来，转化成.id Academy的教材，再把可以公开的部分发布出来。

论文题目还没定。我倾向于两个世界重叠的地方：从防御者收件箱看DNS滥用是什么样，以及印尼的域名持有者和培训师现实中能做什么。如果AI代理那条线站得住，它可能单独成篇。

课堂部分对我最重要。在万鸦老或巴淡上课时，学生很少问根服务器。他们问的是怎么判断一个链接是否安全，或者有人做了他们校园网站的假副本该怎么办。如果我能带着更好的答案走回那些教室，并且能说出处理这些问题的人和流程的名字，这一周就值了。

PANDI（Pengelola Nama Domain Internet Indonesia）是印尼的国家代码顶级域名 .id 的注册管理机构，负责 .id 及其下级域名的分配、政策制定与本地互联网社群建设。它同时运营 .id Academy，面向公众提供域名、DNS 与网络安全培训，并与高校和地区机构合作举办训练营。.id Academy 培训师身份意味着作者处在"技术—教育—政策"的交汇点：他既要理解域名系统的运营细节，也要把这些知识翻译成学生和小企业主能使用的语言。这种双重角色使得他参加 ICANN 会议时，能同时从政策参与者与本地培训者的视角观察问题，并把会议内容转化为可落地的教学材料。

如果你也会在场

如果你会到ICANN87现场或在线，而且做DNS滥用、DNSSEC，或者任何AI代理与DNS交汇的事，我想聊聊。我会是那个记了太多笔记的人。会议之后我会发布学到的东西，包括这篇帖子写错的地方。