文档变身基础设施：复制粘贴示例的隐形炸弹

在NameOcean，我们天天聊域名安全、DNS配置，还有搭建基础设施的正确姿势。但有个怪问题没人深挖：文档啥时候偷偷成了你的真基础设施？

去年，有个安全研究员随便注册了个third-party-example.com，普普通通的.com域名，从没被别人要过。几天内，他的邮箱就收到真DMARC报告了。一个月不到，22家以上的组织发来报告。这些组织压根不知道自己在干啥。

关键是：这个域名出现在Cloudflare的DMARC文档里，当作例子。那些组织直接复制粘贴，扔进生产DNS记录，没换成自己的报告域名。

文档供应链的坑

这不光是Cloudflare的毛病，才真可怕。同一域名在多语言文档里出现，还被至少8个第三方文档抄袭。代码片段一传十十传百，就从“文档”变成软件供应链漏洞。

根子在人：大家爱照葫芦画瓢。第一次搞DMARC，你看到example@third-party-example.com，觉得靠谱，就贴进DNS TXT记录，继续干下一个活。文档不是指导手册，它直接跑进生产环境了。

到底泄露了啥情报

说具体点，为啥这么严重。DMARC报告里有：

• 邮件系统全家桶：发票用啥邮件服务商，新闻通讯靠哪个平台，备份服务器占哪些IP段
• 认证失败痕迹：SPF/DKIM失败的量和来源
• 伪造攻击：谁在假冒你域名，从哪来，多少量
• 合作伙伴图谱：合作方、客户、供应商，全从信封分析漏出来
• 服务依赖：哪些云商转发、转寄你邮件

不算法律意义的数据泄露，没加密密码，没客户隐私。但对黑客来说？这简直是天上掉的礼物：你邮件架构地图、供应商名单、弱点曝光、转发链条，每天自动送上门。

对你基础设施的三大教训

第一：文档例子必须用IANA保留域名。不止主例子用.example.com，次要的也得用保留段。third-party-example.com听着像保留的，其实能注册，就能被利用。

第二：配置例子别直接能复制上生产。得逼人改改。有些团队在前面加CHANGEME_标记，增加点摩擦，但这是好摩擦。

第三：从文档部署前，多验证。DMARC记录上生产DNS前，确认它适合你域名。测试报告地址，别直接硬上。

对域名策略的提醒

我们NameOcean总说，DNS就是基础设施，是域名在网上的骨架。配置DNS得像写生产代码一样严谨。别不加思考就抄文档的DNS记录。紧急改配置，也得先验证。

那22家组织，邮件安全做好了，DMARC记录也没语法错。但因为懒得换例子，成了无意中的监控通道。

这事儿不怪Cloudflare或谁的文档团队。它证明行业把文档例子当静态参考，其实它们就是可部署的基础设施。心态不改——不把例子当代码一样严防——这类曝光还会继续。

下次复制配置例子上生产，停一秒。确认适合你。手动换占位符。因为现实中，文档不只指导基础设施，它就是基础设施。