本帖最后由 BekenYang 于 2026-6-18 16:24 编辑
摘要：随着《网络安全法》和等级保护2.0标准的全面落地，国内绝大多数三级及以上信息系统已采用严格的出站域名访问控制机制，其核心实现方式为应用控制层面的域名访问控制规则。然而，内容分发网络（Content Delivery Network，CDN）的动态IP调度与多层规范名记录（Canonical Name，CNAME）重定向机制，与企业级防火墙域名访问控制策略的核心设计存在根本性冲突。本文通过对深信服AF、华为USG）、飞塔FortiGate、山石网科SG-6000、PaloAltoPA系列等5款主流防火墙产品的官方技术文档分析（因条件所限，本文撰写主要依赖深信服下一代防火墙AF；其它设备只对应设备文档进行分析，未进行实物配置测试），本文分析表明“防火墙不自动跟随CNAME链”和“泛域名仅支持单级通配”并非技术缺陷，而是防范CNAME绕过攻击和遵循DNS标准RFC 1034的必要设计。研究通过真实生产环境多阶段对比实验发现：严格按照火山引擎官方应用程序编程接口（Application Programming Interface，API）文档要求仅添加主域名时，API调用成功率仅为54.62%；按照官方智能助手推荐添加27个泛域名后，成功率仅提升至64.54%。经与火山引擎官方技术支持正式沟通，确认其未发布完整域名-CNAME-IP段三元组列表，且给出的补充配置建议仍无法解决问题。而参考企业微信、钉钉的行业实践，发布完整三元组列表可将业务中断率降至0.3%以下。本文结合4年跨度的钉钉生产环境对比案例，提出了标准化的SaaS服务白名单发布规范，为解决企业级网络环境下的CDN服务兼容性问题提供了理论依据和可落地的实践指南。
关键词：企业级防火墙；域名访问控制策略；CNAME重定向；内容分发网络；访问控制；网络安全合规
1. 引言 1.1 研究背景与意义 网络安全等级保护制度已成为我国网络安全的基本国策。《网络安全等级保护基本要求》（GB/T 22239-2019）明确规定，第三级及以上信息系统必须“采用白名单机制，仅允许授权的程序和网络连接运行”[1]。这一要求使得严格的出站域名访问控制机制成为政府、金融、能源、制造等关键行业企业网络的标准配置。
与此同时，CDN技术已成为互联网基础设施的核心组成部分。Hao等人[2]在USENIXSecurity 2018上发表的大规模实证研究表明，CDN的动态DNS映射机制存在重定向劫持漏洞，攻击者可通过注入精心构造的合法DNS记录来操纵CDN的用户重定向，且由于攻击发生在CDN边缘侧，DNSSEC对此类攻击的防护能力有限。Guo等人[3]在IEEE SRDS 2018上进一步揭示了CDN在源站验证方面的严重缺陷：8家主流CDN中有3家在默认配置下未对源站身份进行严格验证，攻击者可借此构造非法请求，将CDN节点作为代理发起访问。Shobiri等人[4]在ACMTOPS 2022上的研究对14家领先CDN的后端TLS连接进行了全面安全评估，发现所有CDN在源站证书验证的实现上均存在不同程度的配置风险，其中9家（包括Microsoft Azure）在特定场景下未能严格执行证书校验机制。在企业边界防护方面，Chen等人[5]在NDSS 2016上提出的转发环路攻击揭示了CDN与企业网络边界设备之间的交互风险，其发现被IETF采纳并形成RFC 8586的标准化建议。Ren等人[6]进一步揭示了CNAME重定向被滥用于绕过浏览器安全机制（CNAME Cloaking）的问题，导致敏感Cookie被泄露给第三方追踪域。
上述研究均表明，CDN的动态IP调度、多层CNAME重定向和复杂的请求路由机制本身就带来了显著的安全挑战。然而，现有研究主要从攻击者视角出发，关注CDN自身的安全漏洞；而在等保2.0强制要求严格出站白名单的合规背景下，CDN的动态调度机制与企业防火墙基于域名的访问控制策略之间产生的兼容性冲突，尚未有文献进行系统性分析。本文的研究为该领域提供了来自生产一线的实证数据和可落地的解决方案，对于降低企业网络运维成本、提升SaaS服务企业级可用性具有直接的指导意义。
1.2 现有研究的不足
CNAME安全风险研究：2021年NDSS MADWeb研讨会的研究系统分析了CNAME重定向导致的第一方Cookie泄露问题[6]；同时揭示了CNAME伪装技术可被用于绕过广告拦截器和企业防火墙，证明了CNAME权限委托存在严重的安全隐患。后续研究进一步揭示了CNAME伪装技术如何被用于绕过广告拦截器和防火墙。但这些研究均未涉及防火墙域名访问控制策略机制的兼容性问题。
防火墙域名过滤技术研究：现有研究主要关注如何提高域名过滤的准确性和性能，如基于P4可编程数据平面的DNS深度包检测方案，但均默认防火墙会自动处理CNAME重定向链和多级泛域名，与实际工业界实现存在巨大偏差。
SaaS服务白名单实践：企业微信和钉钉等头部厂商已发布官方白名单列表，但这些实践尚未被学术界系统总结和标准化，也缺乏长期生产环境的对比验证数据。
1.3 本文的主要贡献
理论贡献：通过对主流防火墙产品官方技术文档的系统梳理，首次全面揭示了“防火墙不自动跟随CNAME链”和“泛域名仅支持单级通配”的设计本质，对行业内普遍存在的“这是厂商技术缺陷”的认知进行重新探讨。
实践贡献：通过真实生产环境的多阶段对比实验，量化评估了“仅主域名”、“泛域名列表”和“完整三元组列表”三种配置方案的实际效果，并提供了4年跨度的钉钉生产环境对比数据，为结论提供了坚实的实践支撑。
行业贡献：基于官方技术支持的正式回复，明确指出了当前部分头部云厂商在白名单服务方面存在的系统性缺失，为解决长期困扰行业的兼容性问题提供了共识基础。
2. 相关工作 2.1 核心术语定义 为避免行业术语歧义，本文对以下核心概念进行明确界定：
全局IP/域名白名单：防火墙优先级最高的访问控制规则，一旦添加将直接放行对应IP或域名的所有流量，绕过其他所有安全检测策略。
域名访问控制策略：企业级防火墙最常用的白名单机制实现方式，特指应用控制层面的域名放行规则，通过监听DNS响应报文建立“域名-IP”映射缓存，自动生成临时IP放行规则，仅允许匹配指定域名的流量通过，同时保留深度包检测、入侵防御等安全功能。本文后续讨论的“白名单机制”如无特殊说明，均指此类域名访问控制策略。
2.2 企业级防火墙域名访问控制策略机制 企业级防火墙的应用控制域名访问功能，本质上是“基于域名模板的IP白名单自动生成与更新系统”。其核心工作流程为：防火墙监听所有经过设备的DNS响应报文，提取报文中的域名和对应的IP地址，建立“域名->IP”映射缓存；根据缓存的映射关系，自动生成和更新临时的IP+端口ACL规则；当客户端发起TCP/UDP连接时，防火墙直接用目的IP匹配ACL规则，决定放行或拦截。
该机制的运行规范与功能边界在深信服[7][8]、华为[9]、飞塔[10]等主流厂商的官方技术文档中均有明确界定。需要特别区分的是，防火墙DNS监听解析与主动跟随CNAME链式解析为两种完全独立的技术机制，二者核心差异体现在触发逻辑、解析范围与安全设计层面：
其一，DNS监听解析为防火墙原生标配能力。防火墙仅被动监听、捕获终端主动发起的DNS请求，对请求报文中的原始访问域名进行策略匹配，不会主动发起额外的DNS递归查询，解析行为完全依托终端请求触发[7][9][10]。该机制贴合标准DNS访问流程，性能损耗低且可控性强。
其二，主动跟随CNAME链解析不属于防火墙默认原生能力。CNAME机制的核心是域名别名映射，单次域名解析可触发多层域名跳转，形成完整解析链路[2][5]。华为USG系列防火墙官方技术规范明确说明，设备默认不会主动追踪、递归解析域名对应的CNAME别名链[13]；深信服AF系列技术文档同样指出，防火墙仅对请求报文中的原始域名进行策略匹配，不会解析CNAME跳转后的二级、三级域名及对应IP地址[7][8]。该设计并非功能缺失，而是基于安全防护的主动约束。
主流厂商的官方技术文档均明确说明：防火墙只会主动解析管理员手动添加的域名，不会自动跟随CNAME解析链。这一设计并非技术局限，而是基于严格的安全论证与标准遵从。从安全机制层面分析，CNAME伪装与多层别名跳转是网络追踪与策略绕过的已知攻击手段[2][4][5][6]。若防火墙默认自动跟随多层CNAME链路，恶意域名可通过CNAME指向已加入白名单的合法域名（如攻击者将malicious.com CNAME至api.enterprise.com），诱使防火墙将该IP加入临时白名单，从而突破企业边界访问控制[5]。此类攻击路径已被证实可用于恶意软件的命令与控制（C2）通信。同时，防火墙对泛域名的处理逻辑严格遵循DNS协议标准：RFC 1034[11]定义了域名系统的基础架构，RFC 4592[12]明确了泛域名通配符*仅支持单级匹配、无法跨级生效的限制。该设计规避了多级泛匹配带来的策略粒度失控问题，契合企业边界防护的最小权限原则与等保合规要求[1]。
2.3 CDN 技术的工作原理 CDN通过在全球部署边缘节点，将用户请求调度到最近的节点，从而实现内容加速和容灾备份。其核心技术包括：
多层CNAME重定向：业务域名->CDN加速域名->区域调度域名->边缘节点IP（通常为3-5级CNAME链）。
动态 IP 调度：根据用户地理位置、运营商、节点负载实时调整解析结果。
HTTPDNS：绕过运营商本地DNS，直接向CDN的HTTPDNS服务器发送解析请求，避免DNS污染和劫持。
这些技术在提升用户体验的同时，也给防火墙域名访问控制策略配置带来了前所未有的挑战。
3. 问题机理深度分析 3.1 域名访问控制策略的核心特性 基于对深信服AF 8.0.107下一代防火墙生产环境的系统观测及官方技术文档分析[7][8]，结合华为USG[9]、飞塔FortiGate[10]等厂商公开配置规范的交叉比对，企业级防火墙域名访问控制策略存在以下四个直接影响CDN兼容性的核心特性。需要说明的是，本节所述机制细节主要源于深信服AF系列的实测数据，其他厂商产品在实现上可能存在差异，具体参数应以各厂商官方文档为准。
特性一IP匹配优先：防火墙在连接建立阶段仅匹配数据包目的IP地址，不检查客户端实际访问的域名。域名仅作为生成IP白名单的“模板”，一旦缓存生成，后续流量控制完全依赖IP匹配。该设计决定了防火墙无法区分同一IP地址上承载的不同域名业务。
特性二全局共享缓存：所有内网终端共享同一DNS解析缓存表。任一终端对某域名的解析结果会被缓存并用于全网的后续连接匹配，不同终端的DNS查询结果相互覆盖。
特性三最后写入优先（Last-Write-Wins）：当同一IP地址对应多个域名时，防火墙缓存仅保留最后一次查询到的域名-IP映射关系。此机制在深信服AF系列中表现为：后查询的域名会覆盖先查询域名对应的IP关联记录[8]。华为USG系列采用类似的缓存更新策略，但具体的冲突处理逻辑（如超时时间、老化机制）可能与深信服存在差异[9]。
特性四泛域名通配限制：主流防火墙严格遵循DNS标准RFC 1034[11]及RFC 4592[12]对通配符记录的界定：泛域名通配符仅匹配当前域名级别的任意子域名，且扩展深度受限。以RFC 1034的规范表述为例，.example.com可匹配a.example.com，但不匹配a.b.example.com；*.a.example.com可匹配b.a.example.com，但不匹配c.b.a.example.com[11]。RFC 4592进一步澄清了通配符在DNSSEC及复杂解析场景下的匹配边界，明确排除了跨级匹配的可能性[12]。深信服官方技术文档对此有明确说明[7]，华为、飞塔等厂商的实现亦遵循同一标准框架[9][10]。
此外，深信服AF系列防火墙对单个域名的解析IP缓存数量存在明确上限：老架构默认记录15个，最大可扩展至100个；新架构默认记录30个，最大可扩展至200-300个[8]。该限制意味着，对于解析出数百乃至上千个动态IP的主流CDN服务，即使泛域名配置完整，仍存在因缓存溢出导致的潜在中断风险。华为、飞塔等厂商虽未在公开文档中披露同类上限的具体数值，但其缓存机制同样受设备硬件资源约束，大规模动态IP场景下的稳定性需结合实际部署环境评估[9][10]。上述四个核心特性决定了防火墙域名访问控制策略与CDN动态调度机制之间存在结构性兼容障碍。以下从CDN技术视角分析其带来的具体挑战。
3.2 CDN技术带来的三重兼容性挑战 对于使用CDN加速的API接口，域名访问控制配置面临以下三重不可避免的挑战：
IP 动态变化挑战：CDN边缘节点IP会频繁动态更新，不存在长期固定的静态IP地址,且会根据负载情况动态调整。静态IP白名单无法长期有效，需要频繁手动更新。
全局缓存“域名-IP关联错位”挑战：同一个CDN节点IP会承载上百个不同的域名。当内网中其他终端查询过另一个域名并解析到同一个IP时，防火墙会将该IP与后查询的域名关联，导致原业务域名的流量被错误拦截。
HTTPDNS挑战：现代客户端广泛使用HTTPDNS技术，其DNS查询使用HTTP/HTTPS协议，不经过防火墙的DNS监听端口，导致防火墙完全无法获取域名->IP的映射关系，从而无法生成正确的ACL规则。
4. 生产环境案例分析 4.1 案例背景 我公司采用严格的出站域名访问控制策略，使用深信服AF 8.0.107作为边界防火墙。该企业于2026年4月开始部署了火山引擎智能体会话服务，5月正式使用open.feedcoopapi.com接口进行内容推送。
4.2 问题现象
业务上线后，API调用频繁出现超时失败，失败率约为45%，且无明显规律。失败时客户端返回“接口调用异常：java.net.ConnectException:Failed to connect to open.feedcoopapi.com/240e:f7:a093:101:3:0:0:7:443 OkHttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:285)”错误，防火墙日志显示连接被“默认拒绝规则”拦截。
4.3 排查过程
检查域名访问控制策略，确认已按照官方文档要求添加open.feedcoopapi.com域名。
在客户端手动执行nslookup open.feedcoopapi.com，发现解析结果为112.87.86.147。
检查深信服防火墙的DNS缓存，发现112.87.86.147对应的域名是mssdk.volces.com，而非open.feedcoopapi.com。
进一步排查发现，内网中另一台终端在业务终端发起连接前1分钟，查询了mssdk.volces.com域名，且解析到了同一个IP地址。
由于该防火墙的全局缓存采用“最后写入优先”策略，112.87.86.147被关联到了mssdk.volces.com，而该域名不在白名单中，导致连接被拦截。
本次排查中发现的问题与我们2022年处理钉钉服务访问异常时遇到的问题完全一致。最初误判为网络通信波动导致的API服务间歇性不稳定，连续多日在多个终端同时抓包，交叉对比客户端、防火墙的完整通信日志，最终才定位到问题根源是企业级防火墙全局DNS缓存的“最后写入优先”更新策略。该问题具有极强的隐蔽性，在单终端独立实验测试环境中完全无法复现，只有在多终端并发访问的生产环境中才会随机出现。
4.4 解决方案 进行两个阶段的解决方案迭代，严格遵循火山引擎官方提供的所有配置建议：
阶段1：官方文档标准配置（仅添加主域名） l 配置内容：仅添加open.feedcoopapi.com到防火墙域名访问控制策略。 l 统计周期：2026年5月18日15时33分24秒至2026年6月1日11时32分。 l 数据来源：API调用日志原始记录统计。
阶段 2：官方智能助手推荐配置（添加所有泛域名） l 配置依据：咨询火山引擎官方文档页面的“火山助手”智能客服，按照其回复的完整白名单建议进行配置。 l 配置内容：添加了以下27个域名（包含5个精确域名和22个泛域名）到域名访问控制策略中： ² *.feedcoopapi.com ² mercury.volcengineapi.com ² *.volcengine.com ² *.volcengineapi.com ² *.volces.com ² *.volcimagex.com ² *.trae.com.cn ² *.trae.cn ² *.trae.ai ² *.mchost.guru ² trae-api-cn.mchost.guru ² *.trae.cn.bytexns.com ² *.trae.cn.volctraffic.com ² *.zijieapi.com ² *.bytetcc.com ² *.ibyteapm.com ² *.bytetos.com ² *.marscode.cn ² *.byteacctimg.com ² *.bytedance.com ² *.byted.org ² *.snssdk.com ² *.coze.cn ² api.coze.cn ² *.open-vsx.org ² raw.githubusercontent.com ² registry.npmjs.org l 初始统计：2026年6月1日11时32分至2026年6月2日16时14分38秒。 l 数据来源：API调用日志原始记录统计。
官方技术支持回复与后续观察 截至2026年6月3日，业务仍停留在阶段2配置，API调用成功率稳定在64%左右。经提交正式工单（工单编号：T-2026060116150007）与火山引擎官方技术支持沟通，获得以下正式书面回复：
A. 明确承认未提供完整列表：“目前火山方舟没有公开的全链路域名+IP/CIDR网段持续更新页面，也没有对外提供此类文档”。 B. 给出补充配置建议：“调用时启用了web_search工具，open.feedcoopapi.com的请求是发生在方舟服务端内部，您不需要对其做任何域名访问控制配置，只需保证能正常访问ark.cn-beijing.volces.com即可”。 C. 拒绝提供IP段：“当前没有固定的IP段可用，仅支持根据域名进行访问”。 D. 不建议使用IP白名单：“方舟平台IP是动态的，通过固定公网IP直接调用容易出现连接不稳定、超时、断连等情况，不建议使用固定IP加白的方式”。
后续观察： l 经测试，无论保留还是移除官方建议的ark.cn-beijing.volces.com域名，访问成功率均维持在同等水平，未见提升。 l 从2026年6月2日16时14分至2026年6月3日17时30分，API调用成功率达到100%（567次请求全部成功）。 l 经与深信服技术支持确认，成功率提升的核心原因是：防火墙域名访问控制策略采用渐进式缓存机制，加入泛域名后需要一定时间逐步缓存所有相关域名解析到的IP地址，随着缓存的逐步完善，成功率会逐渐提升至100%。
阶段2（缓存完善后）的界定依据 阶段2配置生效后，API调用成功率呈现明显的时序演化特征：初期（6月1日11:32至6月2日16:14）成功率64.7%，后期（6月2日16:14至6月3日17:30）成功率100%。为排除随机波动干扰，本研究从以下三方面界定“缓存完善”状态：
l 时间窗口阈值：深信服AF系列DNS缓存的典型重建周期为12-24小时[8]。阶段2配置生效至后期观测起点已历经28.7小时，超过典型缓存周期的上限，从时间维度支持缓存已完成重建。
l 历史模式验证：该防火墙设备在2023年及2025年版本升级重启后，均呈现一致的缓存重建模式：重启后域名访问控制策略短期失效（业务中断率35%-40%），启用“排障模式”全流量放行约24小时后，随DNS缓存逐步重建，策略恢复正常，中断率降至0.3%以下。本次阶段2观测到的“初期64.7% -> 24小时后100%”演化趋势，与上述历史模式高度吻合，支持“渐进式缓存完善”的机制解释。
l 稳定性判据：6月2日16:14至6月3日17:30连续25.3小时内，567次请求全部成功，未出现任何因缓存条目过期或IP变更导致的异常波动，满足“连续稳定运行超过24小时”的工程判定标准。
4.5 效果验证 我们对两个阶段的配置效果进行了精确统计，结果如下：
表 1 不同配置阶段的 API 调用成功率对比 [td] | 配置阶段 | 配置依据 | 统计周期 | 总请求数 | 成功请求数 | 成功率 | | 阶段 1 | 火山引擎官方API文档 | 2026.05.18 15:33 - 2026.06.01 11:32 | 390 | 213 | 54.62% | | 阶段 2 | 火山引擎官方智能助手 | 2026.06.01 11:32 - 2026.06.02 16:14 | 1051 | 680 | 64.7% | | 阶段 2
（缓存完善后） | 火山引擎官方智能助手 | 2026.06.02 16:14 - 2026.06.03 17:30 | 567 | 567 | 100% |
4.5.1.效果分析
局限性说明：后期100%成功率亦可能部分归因于“观测期内CDN未引入新域名/IP”这一偶然因素。由于未获取火山引擎CDN调度策略的实时变更日志，无法完全排除该竞争性解释。但结合历史重启后缓存重建的重复模式（见4.4节），缓存完善仍是最可能的归因。
4.5.2.当前方案的潜在致命风险 尽管阶段2后期观测到100%成功率，但该方案存在三个无法解决的根本性问题：
l 不可预测的业务中断风险。若火山引擎在未来启用27个泛域名之外的新域名（特别是多级子域名），防火墙将无法自动缓存对应IP，业务将再次出现无规律访问失败。此类中断具有突发性和不可预测性，无法提前预防。
l 严重违反最小权限原则。阶段2配置开放了*.bytedance.com、*.volces.com等27个一级泛域名，实质上允许访问字节跳动旗下全部互联网服务，使白名单机制的安全边界严重膨胀。该做法直接违反《信息安全技术网络安全等级保护基本要求》（GB/T 22239-2019）中关于“最小权限访问控制”的核心要求[1]。
l 访问控制粒度退化。 泛域名方案无法区分同一域名下不同业务的访问权限。以*.bytedance.com为例，该泛域名涵盖字节跳动旗下广告、社交、办公、云服务等多个业务线，防火墙的访问控制粒度从“单一业务接口‘退化至’整个互联网集团全部服务”级别。这不仅削弱了边界防护的精细度，还增加了内部人员违规访问及恶意软件横向移动的攻击面。
4.5.3.长期生产环境对比验证（钉钉案例） 阶段B（2022年5月—2026年6月）：完整三元组列表配置。 按照钉钉官方发布的《钉钉相关域名和IP列表》[14]配置，包含业务域名、完整CNAME链及200余个聚合IP段（CIDR）。截至2026年6月，该方案已连续运行4年零1个月（共1491天），服务企业内部3800余名员工，支撑自制工作台、人事系统、通知中心、待办中心等10余个自建应用的日常运行。
运维反馈数据。阶段B期间，企业IT部门未收到任何因防火墙拦截导致的钉钉业务中断报告。需要明确说明的是，该数据属于基于运维工单系统的间接观测，存在以下固有局限：
l 轻微超时（如单次API调用延迟>5s但后续重试成功）可能未被用户感知或上报；
l 客户端本地缓存或SDK重试机制可能掩盖了部分底层连接失败；
l 未部署独立的端到端可用性探活监控系统，无法获取精确的可用性百分比。
保守估计下的稳健性验证。即使按高度保守的假设——阶段B期间存在1%的隐性中断率（即每100次API调用中存在1次因防火墙策略导致的超时或失败，但被客户端重试机制自动恢复，未触发运维报告），在1491天的观测周期内，至少发生一次可感知中断的累积概率为file:///C:/Users/Yangxuan/AppData/Local/Temp/msohtmlclip1/01/clip_image046.png，（几乎必然）。然而实际运维记录仍为零报告，说明真实中断率远低于1%。作为对比，阶段A的显性中断率已达35%–40%，两阶段差距至少为一个数量级。
注：钉钉案例的可用性评估依赖于运维工单反馈，未部署独立的端到端监控探针。未来研究可通过引入Prometheus/Blackbox Exporter等工具，获取精确的可用性百分比（如99.9%或99.99%），以弥补当前数据的粒度不足。
5. 行业实践与标准化规范 5.1 行业实践分析 钉钉[14]和企业微信[15]是国内最早发布官方域名访问控制列表的企业级SaaS服务商，其做法已经被全国数百万家企业验证为最可靠、最通用的解决方案。通过对这两个列表的深入分析，我们总结出以下最佳实践：
l 完整的三元组列表：同时公布业务域名、CNAME域名和CDN IP 段，覆盖所有可能的场景。 l 聚合的IP段：将单个IP聚合为CIDR网段，减少防火墙规则数量，提高匹配效率。 l 详细的功能标注：每个条目都标注了对应的业务功能、协议和端口，方便企业按需配置。 l 透明的更新机制：提供历史详细的变更记录。
5.2 标准化的SaaS服务白名单发布规范框架 基于行业最佳实践，本文提出面向企业级网络环境的SaaS服务白名单发布规范框架。该框架界定了服务商应向企业客户披露的必要且充分的信息集与协作机制，包含以下四个核心维度：
A. 信息发布渠道 服务商应建立官方、独立、长期稳定维护的域名与IP地址信息发布入口。信息格式应支持机器可读的开放数据标准（如JSON、CSV），以便于企业自动化导入防火墙及安全策略设备，降低人工配置错误率。
B. 列表内容要素 白名单列表应构建完整的“域名-CNAME-IP”三元组体系，至少包含以下五类要素： l 业务域名全集：所有对外提供服务的主域名及子域名； l CNAME 重定向链：完整的每一级CNAME别名记录，包括 CDN 加速域名与区域调度域名； l CDN节点IP段：按地域或功能聚合的CIDR网段，避免枚举单个离散IP地址； l 端口与协议：各服务对应的传输层协议（TCP/UDP）及端口范围； l 功能映射：各条目对应的业务功能标识，明确区分必备项与可选项。
C. 变更管理机制 服务商应建立白名单内容的版本化变更管理机制： l 常规变更应提前发布预通知，预留企业策略调整窗口； l 重大架构变更（如CDN服务商切换、CNAME链重构）应显著延长通知周期； l 保留完整的历史变更记录，支持企业进行审计、回滚与故障溯源。
D. 配套技术文档与安全约束 服务商应提供与列表配套的《技术实施指南》，涵盖常见问题排查、主流防火墙产品的配置参考及规则批量迁移方案。泛域名不应作为默认推荐配置，除非经过严格的安全评估并明确告知企业客户由此引发的权限膨胀风险。对于确需启用SSL解密或HTTPDNS等高成本兼容方案的特殊场景，服务商应在文档中明确标注其性能损耗与隐私合规风险，为企业提供决策依据。
5.3 不同解决方案的对比与选择 在SaaS服务商未提供完整域名-CNAME-IP段三元组列表的情况下，企业客户只能被迫采用以下四种妥协性解决方案。这些方案均存在不同程度的缺陷，其中代理服务器方案还会带来严重的安全合规风险。表2对比了四种方案的核心指标，所有可用性数据均来自主流防火墙和安全厂商的官方技术配置手册或白皮书及行业实践报告。
表2不同解决方案对比 | 解决方案 | 实用性 | 安全性
(高/中/低) | 运维成本
(高/中/低) | 性能损耗 | 适用场景 | | 发布完整三元组列表 | 极高 | 高 | 低
（导入即可） | 无 | 企业级SaaS服务 | | 开启SSL解密提取SNI | 高 | 中 | 中 | 中 | 终端数量<100的小型企业 | | 强制所有 DNS 流量经过防火墙 | 较高 | 中 | 高 | 无 | 终端数量<500的中型企业 | | 使用代理服务器 | 极高 | 中 | 极高 | 低 | 已有成熟代理架构且已完成安全加固的企业 |
本表数据信源说明： -发布完整三元组列表：基于本文4年钉钉生产环境实际运行验证 -开启SSL解密提取SNI：基于深信服AF8.0[7]、飞塔FortiOS7.4官方技术文档[10] -强制所有DNS流量经过防火墙：基于华为USG系列下一代防火墙官方技术文档[9] -使用代理服务器：基于企业级网络安全架构的通用实践
工作原理：SNI（Server Name Indication）是HTTPS协议的扩展，允许客户端在TLS握手阶段就告知服务器自己要访问的域名，从而实现一个 IP 地址托管多个HTTPS网站。开启SSL解密后，防火墙会作为“中间人”拦截所有HTTPS流量： l 客户端向防火墙发起TLS连接。 l 防火墙伪装成服务器与客户端完成TLS握手。 l 防火墙提取TLS 握手中的SNI字段，获取客户端实际访问的域名。 l 防火墙根据域名访问控制策略规则决定是否放行。 l 如果放行，防火墙再伪装成客户端与真实服务器建立TLS连接。 l 防火墙在两个连接之间转发加密流量。
解决机制：完全绕过了防火墙基于DNS生成IP白名单的传统机制，直接在应用层识别真实域名。无论域名有多少级CNAME，无论IP如何动态变化，只要SNI字段中的域名在白名单中，就会被放行，同时彻底解决了“全局缓存的域名-IP 关联错位”的问题。
核心缺点： l 性能损耗极大：SSL加解密是计算密集型操作，会导致防火墙吞吐量下降30%-50%。对于10Gbps以上的出口带宽，需要专门的硬件加速卡，硬件成本增加2-3倍。
l 严重的隐私风险：防火墙可以看到所有HTTPS流量的明文内容，包括用户密码、敏感业务数据和个人隐私信息。这违反了数据最小化原则，也不符合等保2.0的隐私保护要求。
l 不支持UDP流量：只能处理TCP协议的HTTPS流量，无法处理音视频会议、实时通信等使用UDP协议的流量。
l 证书信任问题：需要在所有终端上安装防火墙的根证书，否则会出现证书错误。对于BYOD设备和移动终端，部署难度极大。
A. 强制所有 DNS 流量经过防火墙 工作原理：主流企业级防火墙均支持透明DNS监听机制，无需修改终端DNS配置，也无需拦截DNS请求。防火墙会解析所有经过设备的UDP 53端口DNS数据包，被动抓取DNS查询请求和响应报文，自动建立并维护全局域名和IP映射缓存： l 终端向任意公共DNS服务器（如 114.114.114.114）发起原生DNS查询。 l DNS查询流量正常经过企业边界防火墙。 l 防火墙实时解析该DNS查询报文，记录请求的域名。 l 上游DNS服务器返回响应报文，再次经过防火墙。 l 防火墙解析响应报文，提取所有CNAME记录和最终IP地址，将完整域名和IP映射关系存入本地缓存。 l 防火墙根据缓存自动生成临时IP域名访问控制规则，同时将DNS响应原封不动转发给终端。 l 终端完全感知不到防火墙的存在，DNS解析过程无任何额外延迟。 深信服官方社区提供的防火墙域名访问控制策略配置方法，与深信服内部技术支持手册中针对企业级客户的标准配置流程完全一致[7]。
解决机制：确保防火墙能捕获全网所有终端的完整DNS交互过程，不会出现“客户端已解析到IP，但防火墙未生成对应域名访问控制规则”的情况。理论上可以自动跟随完整的CNAME重定向链，因为防火墙能看到DNS响应报文中的所有层级记录。
核心缺点： l 网络架构约束极强：要求企业所有对外DNS流量必须100%经过边界防火墙，不能存在绕过防火墙的出口、VPN专线或第三方上网通道。对于多出口、多分支机构的复杂网络架构，部署难度极大。
l 无法阻止HTTPDNS绕过：现代客户端（如微信、抖音、火山引擎 SDK）普遍内置了HTTPDNS功能，会直接通过HTTP/HTTPS协议向CDN的DNS服务器发送查询，完全绕过防火墙的UDP 53端口DNS监听。
l 全局缓存“域名-IP关联错位”问题仍然存在：同一个CDN节点IP对应多个域名时，防火墙仍然只会缓存最后一次查询到的域名，导致先查询的域名流量被错误拦截。
l 防火墙硬件资源消耗巨大：需要为全网所有终端缓存DNS记录，且每条记录会关联多个CNAME和IP地址。对于终端数量多的的企业，会大量消耗防火墙的内存和CPU资源，严重时可能导致数据包转发延迟增加甚至丢包。
B. 使用代理服务器 工作原理：在企业内部部署一台或多台正向代理服务器，通过防火墙策略和路由配置，强制所有终端的对外网络访问必须通过代理服务器转发。防火墙仅需放通代理服务器的出口IP地址，无需放通任何CDN节点的IP。工作流程： l 终端将所有对外HTTP/HTTPS请求发送至内部代理服务器。 l 代理服务器独立完成DNS解析，自动跟随完整的CNAME重定向链。 l 代理服务器直接向CDN边缘节点发起TCP连接。 l 代理服务器将CDN返回的响应转发给终端。
解决机制：将DNS解析和连接建立的过程从终端转移到代理服务器，完全绕过了防火墙的域名访问控制机制。防火墙只需维护少量代理服务器的IP白名单规则，配置复杂度大幅降低。
核心缺点： l 网络架构改造成本极高：最大成本来自全网路由策略的调整，需要重新规划所有终端的互联网出口路由，确保所有流量都能被引导至代理服务器。对于已经成型的大型企业网络，路由改造可能影响现有业务的稳定性，实施周期长达数周甚至数月。同时需要购买或搭建专门的代理服务器集群，增加设备投入；对于已有成熟运维团队的企业，日常维护成本可控，但路由改造和架构调整的一次性成本极高。
l 安全防护能力严重削弱：所有对外流量由代理服务器直接转发，完全绕开了防火墙的深度包检测、入侵防御、威胁情报匹配等核心安全功能。防火墙退化为单纯的IP放行设备，其作为企业边界安全防线的意义大打折扣。
l 单点故障与性能瓶颈风险：即使采用双机热备架构，代理服务器集群仍然是整个企业互联网出口的单点。一旦代理服务器出现性能瓶颈或故障，所有终端的对外访问都会受到影响。随着终端数量和流量的增加，需要持续扩容代理服务器集群。
l 兼容性问题突出：大量传统桌面应用、嵌入式设备和工业控制系统不支持代理服务器配置，无法通过该方案访问互联网。对于混合办公场景下的远程终端，代理部署难度进一步增加。
需要特别说明的是，代理服务器方案与完整三元组列表方案的可用性差距有限，但两者的安全合规成本存在本质差异： 代理服务器方案的上述安全缺陷，严重违反等保2.0关于“边界访问控制”的核心要求。 对于等保三级及以上的企业信息系统，其带来的合规性处罚风险和数据泄露风险，远高于微小的可用性收益。
核心结论：发布完整的域名-CNAME-IP段三元组列表是当前工程实践中对企业和服务商双方综合成本最低的解决方案。其他三个方案都是企业在服务商不作为时的无奈选择，都会给企业带来额外的成本和性能损耗，其中代理服务器方案还会严重削弱企业网络的安全防护能力，违反等保2.0的核心合规要求。
6. 结论与展望 6.1 研究结论 本文通过理论分析、官方文档考证及真实生产环境的多阶段对比实验，得出以下结论：
A. 防火墙不自动跟随CNAME链与泛域名仅支持单级通配，是基于DNS标准RFC 1034 [11]、RFC4592 [12]及防范CNAME绕过攻击的必要安全设计，而非厂商技术缺陷。这是当前主流防火墙厂商的共识性选择。
B. 仅公布主域名或泛域名列表无法保障企业级网络的业务连续性。本文实验表明，即便配置了27个泛域名，初期仍有35.3%的请求被拦截，且需经历24小时以上的缓存渐进期方能稳定；该方案还存在不可预测的突发中断风险。
C. 泛域名方案严重违反最小权限原则。开放大量一级泛域名会导致防火墙访问控制粒度的退化，实质上将安全边界扩展至整个互联网集团的服务范围，不符合等保2.0的核心合规要求，并引入了显著的权限膨胀风险。
D. 对于使用CDN加速的SaaS服务，发布完整的“域名-CNAME-IP段”三元组列表，是当前兼容主流企业级防火墙域名访问控制机制的较为成熟且经长期验证的工程实践。基于钉钉服务长达4年的生产环境纵向对比数据，该方案可将业务中断率从35%–40%降至趋近于零。
E. 企业微信和钉钉等头部SaaS服务商已建立的完整三元组列表发布机制，已被全国数百万家企业验证有效，可作为行业通用的参考范式。
F. 当前部分头部云服务商尚未发布官方的三元组列表，导致企业客户在缺乏完整信息的情况下，被迫采用存在安全隐患的泛域名方案。这种信息披露机制的缺失，构成了企业网络安全合规落地的实质性障碍，为后续研究及行业实践提供了明确的改进方向。
6.2 未来展望 未来的研究和实践方向包括： A. 可控的CNAME跟随机制：研究如何在保证安全的前提下，实现有限度的CNAME跟随，如只跟随一级CNAME且需要管理员手动确认。
B. 标准化的域名访问控制列表更新API：推动SaaS服务商与防火墙厂商建立标准化的API接口，实现域名访问控制列表的自动更新，降低企业运维成本。
C. QUIC协议下的访问控制：研究QUIC协议的加密特性对域名访问控制机制的影响，提出适应新一代互联网协议的解决方案。
6.3 行业建议 基于本文研究结论，建议企业级SaaS服务商，尤其是采用CDN加速的API平台，建立并公开域名、CNAME及IP段三元组信息的发布机制。该机制能够帮助企业客户更准确地完成防火墙、代理、零信任网关及安全策略的配置，降低网络适配成本，提高服务在企业级网络环境中的可用性。对于尚未建立此类机制的服务商，其企业客户在实施网络安全策略配置和等保合规建设时，可能面临更高的沟通成本、更复杂的运维流程以及额外的技术适配压力。因此，完善域名-CNAME-IP段信息发布机制，可作为提升企业级SaaS服务可用性和合规适配能力的重要工程措施。
7. 参考文献 [1] 国家市场监督管理总局, 国家标准化管理委员会.信息安全技术 网络安全等级保护基本要求: GB/T 22239-2019[S]. 北京: 中国标准出版社, 2019.
[2] Hao S, Zhang Y,Wang H, et al. End-Users Get Maneuvered: Empirical Analysis of RedirectionHijacking in Content Delivery Networks[C]//Proceedings of the 27th USENIXSecurity Symposium. Baltimore, MD, USA: USENIX Association, 2018: 1-17.
[3] Guo R, Chen J, LiuB, et al. Abusing CDNs for Fun and Profit: Security Issues in CDNs' OriginValidation[C]//Proceedings of the 37th IEEE International Symposium on ReliableDistributed Systems (SRDS). Salvador, Brazil: IEEE, 2018: 98-108.
[4] Shobiri B, MannanM, Youssef A. CDNs' Dark Side: Security Problems in CDN-to-OriginConnections[J]. ACM Transactions on Privacy and Security, 2022, 25(2): 1-28.
[5] Chen J, Jiang J,Zheng X, et al. Forwarding Loop Attacks in Content DeliveryNetworks[C]//Proceedings of the Network and Distributed System SecuritySymposium (NDSS). San Diego, CA, USA: Internet Society, 2016.
[6] Ren T, Wittman A,De Carli L, et al. An Analysis of First-Party Cookie Exfiltration Due to CNAMERedirections[C]//Proceedings of the 2021 NDSS Workshop on Measurements,Attacks, and Defenses for the Web (MADWeb 2021). Internet Society, 2021. DOI:10.14722/madweb.2021.23018.
[11] Mockapetris P.Domain Names - Concepts and Facilities[S]. RFC 1034, IETF, 1987.
[12] Lewis E. The Roleof Wildcards in the Domain Name System[S]. RFC 4592, IETF, 2006.
| 
楼主
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
发表于 
