Public Suffix List中通配符与非通配符规则共存的影响分析

在域名系统管理领域，Public Suffix List（PSL）作为关键基础设施，其规则设计直接影响浏览器安全策略。近期社区对"通配符规则（如*.example.com）与普通规则（如example.com）共存时的处理逻辑"展开深入探讨，这涉及到浏览器对公共后缀的判定机制。

规则共存现状

当前PSL中不存在同时包含通配符和普通规则的案例，这种设计空白引发技术疑问。通过测试主流浏览器（Chrome/Edge/Firefox）发现，现代浏览器已通过代码共享实现行为统一，但历史实现存在显著分歧。

浏览器处理逻辑解析

测试表明处理逻辑呈现三个典型模式：

1. 孟加拉国（.bd）案例

   • 存在规则：*.bd
   • 生效范围：foo.bd和bd均被视为公共后缀
   • 逻辑特征：通配符不自动推导上级域名

2. 巴西（.nom.br）案例

   • 存在规则：*.nom.br和br
   • 缺失规则：nom.br
   • 特殊现象：nom.br虽未显式声明却被识别为公共后缀

3. AWS案例

   • 存在规则：*.compute.amazonaws.com和com
   • 生效范围：foo.compute.amazonaws.com和compute.amazonaws.com
   • 边界情况：amazonaws.com不被识别

核心行为规律

通过模式分析可归纳出：

通配符规则会使其直接父级域名隐式成为公共后缀

这种隐式推导机制导致：

• 无需显式声明父级域名即可生效
• 推导仅作用于直接父级，不递归向上
• 与显式声明规则形成逻辑互补

实际应用影响

该机制对业务部署产生重要约束：

1. 域名规划建议
   推荐采用*.service.example.com而非*.example.com结构，避免主域名被意外识别为公共后缀

2. Cookie安全限制
   公共后缀域名禁止设置域级Cookie，但允许设置主机级Cookie。例如neocities.org若被列入PSL，将无法使用内容分发网络等CDN服务（需特殊申请白名单）

3. 解析器兼容风险
   实验性添加双重规则可能导致旧版解析器异常，需谨慎评估

技术演进方向

社区提出的改进方案包括：

• 方案1：强制要求所有公共后缀显式声明
• 方案2：保持隐式推导但完善文档规范
• 方案3：建立分级声明体系

当前业界更倾向方案1，但面临历史兼容性挑战，需要协调各浏览器实现同步更新。该问题在Chromium项目中已持续追踪近十年，反映出基础设施演进的复杂性。

最佳实践建议

对于业务开发者：

• 避免在PSL注册的域名上部署用户子域名服务
• 新增服务子域建议采用三级以上域名结构
• 必须使用公共后缀时，提前与CDN等服务商沟通特殊配置

对于PSL维护者：

• 保持规则声明显式化
• 新增通配符规则时显式补充父级声明
• 建立更严格的规则冲突检测机制