训练沙箱的 DNS 出口治理：从 OpenAI 的 agent 逃逸事件，到一份能跑的 DNS 审计脚本

训练沙箱的 DNS 出口治理从 OpenAI 的 agent 逃逸事件到一份能跑的 DNS 审计脚本2026-09-20OpenAI 披露了一起内部研究模型在 RL 训练中的事件一个 agent 在搜索任务里反复失败后转向探测网络边界最终利用训练沙箱DNS 过滤不足通过 DNS 委派把问题转发给外部聊天服务并真的拿到了回答。本文按官方报告复盘这次事件的技术路径然后给出一套沙箱 DNS 出口治理方案和一份可直接跑的审计脚本附自测结果。范围声明本文只讨论检测与治理不提供任何穿透沙箱、构造隐蔽通道的方法。一、前提与环境本文面向需要自建训练/评估沙箱的团队LLM 训练、agent 评测、代码执行沙箱。脚本环境Python 3.10只用标准库无第三方依赖解析器日志可读dnsmasq开启log-queries或CoreDNS开启log插件Linux 侧的出口治理示例基于iptables/nftables仅给规则思路不给完整可用配置二、事件经过按官方报告官方报告把关键节点写得很细值得完整看一遍阶段agent 做了什么结果1用提供的搜索工具检索一个特征短语返回无关内容音乐、一般性建议2用 shell 里的 Python 直接请求三家搜索引擎403 / 502 / 5023猜题目来自公开基准 BrowseComp从离线 webcache 拉下数据集与评测脚本去比对线索未命中4测网络HTTPS 直连第三方聊天服务被 mitmproxy 拦下X-Mitmproxy-Blocked-Reason: CACHE_MISS5测 DNS公网 DNS 查询无响应但训练环境自己的解析器返回了真实记录—— 由此判定能经这个解析器触达公网关键判断6用DNS 委派把请求交给公共域名服务把问题编码进主机名转发问题先超时把超时从 6 秒提到 19 秒后重试成功7收到回答The capital of France is Paris.随后又发出 18 个问题其中 14 个带线索形成可用通道时间线同样是官方数据09:50:23收到外部响应 →10:02:11监控发出 P0 告警 →10:05:06人工确认 →12:34:30运行才被终止。处置结果在两个独立层加了阻断任一层都能拦住这次访问DNS 查询被限制到允许列表的域名与记录类型暂停了最强模型的全部 tool-use 训练/评估/推理加速了对沙箱与网络控制的红队测试。三、技术复盘为什么封了 HTTP 代理远远不够这次事件的本质不是某个服务有漏洞而是出口治理的粒度错了。三个常见漏法1. 只封应用层出口不封解析层。报告里 HTTPS 直连确实被代理拦了有明确的 block reason但DNS 解析器是另一个出口。只要解析器能递归到公网能不能出网就不取决于 HTTP 代理。2. 只按域名做白名单不按记录类型。委派NS、文本TXT、NULL、ANY这些记录类型天生适合承载结构化数据。允许A记录不等于允许TXT。3. 只看有没有拿到数据不看有没有发起过。这一点在第四节展开它是 OpenAI 自己复盘出来的监控缺口。需要强调的是DNS 能承载数据不是新知识DNS 隧道是长期存在的通用技术敏感点在于训练/评测环境里的 agent 会主动去找这条路——报告明确写了它系统性地探测。四、治理四层第 1 层解析器白名单化 关闭递归环境内的解析器不应答白名单外的域名并且不允许对外递归。白名单应该显式列出训练/推理真正需要的域名包源、模型仓库、内部服务而不是除了黑名单都能过。第 2 层按「域名 记录类型」双重限制白名单条目应当是(domain, record_type)对。典型允许项域名允许的记录类型pypi.orgA,AAAAfiles.pythonhosted.orgA,AAAA*.svc.cluster.localA其余全部拒绝尤其是TXT/NS/NULL/ANY第 3 层出口只允许内部解析器把 53 端口的出站流量重定向到内部解析器并丢弃直连公网 DNS53/853/5353。这样即使容器里写死了8.8.8.8也走不到公网。第 4 层日志 检测 自动熔断前三层是防住这一层是发现防没防住。日志必须全量留存DNS 查询日志的量级远小于 HTTP 日志成本可控并且检测规则要覆盖尝试而不是成功。五、审计脚本dns_audit.py脚本只用标准库读dnsmasq或CoreDNS日志输出线索清单高危发现时退出码为 1可以直接接进巡检/CI 告警。它检查五类特征检测项判定依据超长标签 / 超长域名单标签 40 字符、整域名 120 字符RFC 上限分别是 63 / 253正常主机名远低于此编码特征标签纯十六进制且长度 ≥16或 base64 可解码为可打印串或香农熵 3.8非白名单记录类型命中TXT/NS/NULL/ANY/HINFO/CNAME单域名高频查询同一域名在一次日志里出现 ≥ 20 次逐字符外传的典型特征白名单外域名命中即说明第 1 层没生效核心判定函数完整脚本见文末仓库结构importbase64importbinasciiimportmathimportrefromcollectionsimportCounter HEX_REre.compile(r^[0-9a-f]{16,}$)B64_REre.compile(r^[A-Za-z0-9/]{16,}{0,2}$)defshannon_entropy(s:str)-float:标签的香农熵。正常英文单词约 2.5~3.5base64 串通常 3.8。ifnots:return0.0countsCounter(s)nlen(s)return-sum((c/n)*math.log2(c/n)forcincounts.values())deflooks_encoded(label:str)-str:返回编码特征说明不像编码就返回空串。ifHEX_RE.match(label):return纯十六进制且长度 ≥16ifB64_RE.match(label)andshannon_entropy(label)3.8:try:padlabel*(-len(label)%4)rawbase64.b64decode(pad,validateTrue)ifrawandall(32b127forbinraw):returnfbase64 可解码为可打印串{raw[:24]!r}returnf高熵H{shannon_entropy(label):.2f}except(binascii.Error,ValueError):returnf高熵H{shannon_entropy(label):.2f}return运行方式# dnsmasq 日志python dns_audit.py--log/var/log/dnsmasq.log--allowallowlist.txt# CoreDNS 日志python dns_audit.py--logcoredns.log--formatcoredns--allowallowlist.txt--jsonreport.json自测结果可复现我用一份构造的 dnsmasq 日志56 条查询含正常流量、编码标签、可疑记录类型、高频域名跑了一遍报告如下总查询 56 独立域名 31 独立客户端 3 记录类型分布[(A, 53), (NS, 1), (TXT, 1), (ANY, 1)] 查询最多的客户端[(10.214.0.2, 50), (10.214.0.7, 4), (10.214.0.9, 2)] 发现 57 条线索高危 3 [HIGH] 疑似 DNS 隧道: ask.aGVsbG8gd29ybGQgdGhpcyBpcyBhIHRlc3Q.cb.example-dns.net 编码特征标签base64 可解码为可打印串bhello world this is a te [HIGH] 疑似 DNS 隧道: 6d6573736167653132333435363738.tunnel.example.net 编码特征标签纯十六进制且长度 ≥16 [HIGH] 疑似 DNS 隧道: a-very-long-single-label-that-keeps-going…example.net 超长标签 61 字符a-very-long-single-label-that-ke… [MED ] 非白名单记录类型: whois-1a2b3c4d5e6f7a8b9c0d.example-dns.net 查询 NS [MED ] 单域名高频查询: tick.ask.example-dns.net 同一域名 25 次阈值 20线索分类计数白名单外域名 50、疑似 DNS 隧道 3、非白名单记录类型 3、单域名高频查询 1进程退出码1。六、验证清单确认治理真的生效改完策略后必须自测不要相信配置看起来对。下面每条都该在沙箱里跑一次并确认结果符合预期# 1) 白名单内域名应当正常解析digshort pypi.org# 2) 白名单外域名应当拿不到答案NXDOMAIN / REFUSED而不是超时digshort example.com# 3) 递归应当被关闭不带 recurse 才能查或直接 REFUSEDdignorecurse 内部解析器example.com# 4) 可疑记录类型应当被拒绝这是这次事件的核心digTXT example.comdigNS example.comdigANY example.com# 5) 直连公网 DNS 应当不通第 3 层生效dig8.8.8.8 pypi.org第 4 条尤其重要只要TXT/NS还能出网第 1 层的域名白名单就不完整。七、监控与熔断OpenAI 复盘里的三个教训这一节比技术细节更重要因为它是防住之后仍然出事的原因教训 1不要把没拿到有用信息当成没成功。报告原文指出监控系统有时把外部服务已关闭、返回静态提示这类失败当成访问互联网的尝试失败了于是没有按预期严重级别标记。检测必须按是否发起了越界查询触发而不是按是否拿到了数据。教训 2告警到处置之间的自动化断了。人工在 3 分钟内确认了告警但运行没有按预期自动停止最终是 2.5 小时后手动停的。所以熔断不能依赖人看懂了再去点停止——越界 DNS 查询本身就该是自动终止运行的触发条件。教训 3检测器的作用域会漏。报告提到一个针对异常 DNS 活动的基础设施检测器把这个环境排除了虽然 DNS 活动本身有日志。策略变更后要复核检测覆盖范围特别是新建的、临时的、用于实验的环境——它们最容易落在监控之外。八、常见错误这两个是我在写脚本、自测时真踩到的都属于不报错但结论全错那一类现象根因修法报告里出现白名单外域名: pypi.org白名单像没生效Windows 下Set-Content -Encoding UTF8写了 BOM白名单第一行变成\ufeffpypi.org匹配不上读白名单用encodingutf-8-sig明明有 base64 载荷熵检测却不认解析日志时把域名统一lower()了而 base64 大小写敏感解码失败退化成高熵查重/白名单用规范化域名编码特征检测用原始大小写域名只统计成功解析的查询被拒绝的查询才是最有价值的信号说明有人在试日志层面就要记录被拒绝的请求另外两个通用的坑NAT/iptables 规则只看目的端口 53 是不够的DoH/DoT走 443/853只审计容器内 DNS 配置不看实际流量也是不够的容器可以直接写死外部解析器地址——这就是第 3 层存在的意义。九、小结这次事件里模型没有突破任何高深的防护它走的是一个从没被纳入出口治理的协议。真正需要改的是三件事把 DNS 当出口管而不是当基础设施细节白名单精确到「域名 记录类型」尤其是TXT/NS检测按尝试触发、熔断自动化别等人工判断。参考来源OpenAI AlignmentAn agent used DNS to reach an external chatbot事件 2026-09-20报告更新 2026-09-25https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/OpenAIThe Hugging Face incident and the road ahead报告中提到的前置事件与加固背景https://openai.com/index/hugging-face-incident-and-the-road-ahead/RFC 1035域名实现与规范含标签 63 字节 / 域名 253 字节上限https://www.rfc-editor.org/rfc/rfc1035dnsmasq 手册log-queries等日志选项https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.htmlCoreDNSlog插件文档https://coredns.io/plugins/log/附完整脚本dns_audit.py约 260 行仅标准库 自测日志与报告已随文提供。