泛解析与通配符域名的备案规则

DNS 层面的泛解析，备案层面根本不认识它

泛解析（也叫通配符域名解析）在技术层面很简单：在域名解析里配置一条通配符记录（形如 *.example.com），之后无论用户访问 anything.example.com 还是 whatever.example.com，都会被解析到同一个目标地址，不需要为每一个子域名单独配置解析记录。这个技术特性恰好和备案制度的基本假设冲突——备案要求的是逐一登记每一个具体的域名，而泛解析的意义恰恰是不需要逐一配置。多租户 SaaS 平台给每个入驻用户动态生成一个专属子域名（比如 用户名.平台域名.com），数量可能达到成千上万，而且是运行时动态产生的，既没办法、也没必要去逐一申报备案。这类场景该怎么处理，是备案制度建立之初很少被设想到的问题，也是很多技术团队在落地时最容易卡住的点。

关键要点

• DNS 层面的泛解析和备案层面的域名登记是两套完全独立的机制，前者的便利性不会自动转化成后者的合规豁免。
• 实际可访问、产生内容的子域名，理论上都落在需要备案关注的范围内，区别只在于具体的处理方式。
• 批量动态生成的子域名无法逐一申报，实务上通常落到主域名或平台主体名下统一管理，而不是每个子域名单独走一次流程。
• 平台方和租户方（子域名的实际使用者）之间的责任边界需要在产品设计阶段就明确划分，而不是等出问题了才去追溯。

泛解析不是备案层面的免责理由

一个容易产生的误解是："反正是泛解析自动生成的，又不是我手动一个个加的，应该不用管备案"。这个想法在技术实现的角度说得通，但在备案制度的逻辑里站不住——备案关注的是"这个域名对应的内容是谁在提供、谁负责"，而不是"这条解析记录是手动配置的还是通配符自动生效的"。只要一个子域名实际可以被访问到、承载着具体的内容，它就落在备案制度想要覆盖的范围内，不会因为背后是泛解析技术实现就被排除在外。

这个认知上的落差经常出现在技术团队和合规团队之间：技术团队觉得"这是基础设施层面的事，不该归我们管"，合规团队又觉得"这些子域名理论上都要备案，但根本没法一个个去办"——两边说的都有道理，问题的解法不在于争论该不该管，而在于找到一套既符合制度要求、又能适配批量动态场景的实际处理方式。

动态子域名该按谁的名义处理

实务中，面对批量动态生成的子域名，常见的几种处理思路：

处理思路	做法	适用场景
统一归入平台主体	平台方用自己的主体对主域名完成备案，所有子域名默认共享主域名的备案状态，接入和内容责任由平台方统一承担	平台对入驻用户发布的内容有完整的审核机制，内容风险由平台方统一把控

已知的具体子域名该怎么归类备案（而非批量动态场景），见 二级域名需要单独备案吗。
| 租户独立备案 | 对体量较大、需要独立对外运营的租户，引导其使用独立域名并以自己的主体单独完成备案 | 租户规模较大、有独立运营和合规能力，不满足于使用平台分配的子域名 |
| 分层处理 | 小体量租户默认使用平台子域名、纳入平台统一管理；达到一定规模或特定行业的租户要求切换到独立域名并自行备案 | 平台租户规模差异大，需要按风险和规模分层管理，是实务中最常见的组合方案 |

具体该怎么处理，取决于平台的业务模式和实际的内容管控能力，不存在一个放之四海而皆准的标准答案。但有一条底线原则是共通的：平台方不能以"这是用户自己生成的子域名、内容是用户自己发的"为理由，完全免除自己在接入和内容层面的责任，这和备案制度要求的"谁运营谁负责"原则是一致的。

平台方和租户方：责任边界要在产品设计阶段划清楚

多租户场景下最容易出问题的地方，是平台方和租户方之间的责任边界含糊不清——出了问题之后才发现双方都以为对方该负责，这类责任真空的后果远比提前划清边界的成本更高。

需要在产品设计阶段明确的几个问题：

• 子域名下的内容发布，平台方有没有审核机制：如果平台允许租户自由发布内容而完全不做审核，一旦某个子域名出现违规内容，平台作为接入和主体备案方，很难以"不知道""管不到"为由免责，内容审核机制的必要性和备案要求的内容管理责任是直接挂钩的。
• 租户违规时，平台方能不能快速隔离处置：技术上要有能力针对单个子域名做访问控制或下线处理，而不是只能整体下线所有子域名，否则一个租户的问题会牵连所有其他正常用户。
• 租户协议里有没有明确约定内容责任和平台的处置权：这是产品层面的合规文档，不属于备案材料本身，但它是平台方后续处置违规租户、以及向监管说明自己管理机制的重要依据。

把这些机制设计清楚、落到产品和合同层面，比事后被问起来再临时补救要主动得多。

审核时最容易被要求补充说明的点

如果平台把动态子域名归入主域名统一备案，在管局审核或后续核查环节，常见会被要求补充说明的是：

• 网站的实际运营模式：需要能说清楚这是一个支持用户自主生成内容/子站点的平台类产品，而不是一个单一的、内容固定的普通网站，说明材料里要体现这个业务特征。
• 内容管理机制：平台对子域名下内容的审核流程、违规处置能力，这部分内容的呈现方式可以参考 网站情况说明文档 里关于业务模式说明的思路，只是针对多租户场景需要额外说明动态子域名的管理机制。
• 是否存在前置审批要求：如果平台或者某些租户发布的内容本身涉及需要前置审批的类别（如新闻、金融、医疗咨询等），需要说明平台是如何识别和拦截这类内容的，前置审批的覆盖范围见 需要前置审批的行业。

这类补充说明的核心诉求是让管局相信平台"有能力管住"自己名下的这些动态子域名，而不是放任自流。准备得越充分，审核沟通的效率通常越高。

常见坑

• 以为泛解析技术实现本身能规避备案要求：备案关注的是内容和责任主体，不区分解析记录是手动配置还是通配符自动生效。
• 平台方和租户方责任边界始于出问题之后才厘清：责任真空导致处置混乱，也让平台在面对监管问询时缺乏依据。
• 没有针对单个子域名的隔离处置能力：某个租户出问题时只能牵连所有子域名整体下线，影响面被不必要地放大。
• 引导大体量租户继续挂靠在平台子域名下：规模较大、风险敞口高的租户更适合独立备案，继续挂靠会把风险都集中在平台主体上。
• 内容审核机制只停留在产品文档里，实际没有落地执行：一旦被问及实际执行情况，缺乏真实的审核记录支撑说明材料的可信度。整体接入合规要求见 服务器与备案接入合规。

常见问题

我的 SaaS 平台用泛解析给每个用户生成子域名，这些子域名都需要单独备案吗？

通常不需要逐一申报，实务上多采用将这些动态子域名统一归入平台主域名的备案范围、由平台方承担接入和内容管理责任的处理方式。但平台需要具备相应的内容审核和处置能力，不能把动态生成当作免除管理责任的理由。

租户在平台子域名下发布了违规内容，责任该怎么算？

平台作为接入和备案主体，通常需要承担相应的内容管理责任，这也是备案制度"谁运营谁负责"原则的延伸。建议在产品设计阶段就建立内容审核机制和违规处置流程，并在租户协议里明确约定责任划分，而不是等出问题了才去追溯责任归属。

什么情况下应该让租户使用独立域名自己备案，而不是继续用平台子域名？

体量较大、有独立对外运营需求、或者所在行业本身风险较高（涉及前置审批类内容）的租户，更适合引导其使用独立域名并以自己的主体单独完成备案，这样能让风险责任更清晰地对应到具体的运营主体，而不是全部集中在平台身上。

审核时管局问起动态子域名的管理方式，应该怎么说明？

重点说明清楚业务模式（支持用户自主生成内容的平台类产品）、内容审核机制、以及对违规内容的识别和处置能力。核心是让审核方相信平台确实"管得住"这些动态生成的子域名，而不是放任不管，说明材料准备得越具体，审核沟通通常越顺畅。

资料来源

工业和信息化部 ICP/IP 地址/域名信息备案管理系统的公开规定，以及互联网信息服务管理相关的公开法规对主体责任与内容管理要求的说明。本文为一般性说明，仅供参考，涉及平台类产品的具体备案处理方式建议结合业务实际咨询属地通信管理局或专业顾问。