DNSSEC 一开，部分用户直接解析失败：签名链、报文大小和密钥轮换这三处最容易出事

先摆现象：服务器、机房、监控全部正常，用户却在说打不开

某天开始，零星有用户反馈「网站打不开」。去看服务器，进程在，端口通；去看机房，链路正常，没有丢包告警；去看监控面板，CPU、内存、带宽、HTTP 状态码一片绿。可反馈还在持续进来，而且分布得很怪：同一个城市，有人能开，有人死活打不开；换个网络环境就好了；换回原来那条网络又不行；换台手机，结果又翻过来了。

这种现象最恼人的地方在于，它完全不符合「服务器挂了」的任何特征。服务器挂了是所有人都打不开，监控立刻变红，报警电话马上响。现在是只有一部分人打不开，而且打不开的人换条网络就恢复了——这基本可以把问题指向用户侧到权威服务器之间的某一段，而不是源站本身。源站不会挑用户。

最后定位到解析层：验证方在验证 DNSSEC 时失败，返回 SERVFAIL。注意这里的表述，不是返回「没有这个域名」，也不是返回慢，而是返回一个明确的失败码。对验证方而言，这个域名此刻就是「不可解析」的，跟域名被注销了、权威服务器全线宕机了，从用户视角看没有任何区别。浏览器拿到这个结果，能做的只有一件事：告诉你页面打不开。

以下为典型场景推演，并非特指某一真实事件，同类的现象在不同网络环境里反复出现过。这篇文章要回答的也不是「DNSSEC 怎么配」——配置步骤在各大权威服务器软件的文档里都写得比我清楚，抄一遍没有意义。我想回答的是两个更前置的问题：为什么它的失败模式是整域不可用，以及上线之前必须先验哪三件事。

DNSSEC 和普通 DNS 的差别，其实只在「谁来判对错」这一件事上

普通 DNS 是「问什么答什么」。解析器向权威服务器要 A 记录，权威回一个 IP 地址，解析器把这个结果交给客户端，事情就结束了。解析器在整个过程中不做判断，它拿到什么就信什么。链路中间有人篡改了应答内容，解析器不会察觉，客户端更不会察觉。

DNSSEC 加进来的东西只有一件事：让应答带上可以被验证的凭据。具体做法是给资源记录集（RRset）附加一条 RRSIG 签名记录，同一个 RRset 里的所有记录（比如某个主机名下全部的 A 记录）共用这一条签名，而不是每条记录单独签。验证的工作通常由递归解析器承担，也就是所谓的 validating resolver——它是判卷的人。

信任链自根区向下：父区用 DS 记录指向子区的 DNSKEY，子区用对应私钥签名自己的记录。根区签顶级域，顶级域签二级域，一级一级往下传导。链路上任何一环对不上，验证就失败。

这里要特别留意「对不上」这三个字的实际覆盖范围。它不只是「签名算错了」这一种，还包括「该有的签名压根没有」「签名的时间区间对不上」「父区 DS 指向的密钥和子区实际发布的 DNSKEY 不是同一把」。这些在验证方眼里都是同一类结果，统统判不通过。

而最关键、也最容易被低估的一条是：DNSSEC 验证失败的结果通常表现为整个域名对验证方不可用（常见返回 SERVFAIL），而不是「降级成不验证继续用」。很多人的直觉是，签名验不过就当没签名，把 IP 先给用户，网站照样能开，顶多安全性打折。这个直觉是错的，而且是危险地错。验证方的逻辑是：这份应答不可信，我不能把它交给客户端，同时我也不允许自己悄悄绕过安全机制。于是它返回 SERVFAIL。

这就是 DNSSEC 最危险的地方。普通 DNS 出问题，多半表现为变慢、解析到旧 IP、部分记录缺失，用户还能部分访问；DNSSEC 出问题，是域名直接消失。同样是配置上的一个疏忽，代价差了整整一个量级。说白了，DNSSEC 的风险不在于签名对不对，而在于它的失败形态是整域不可用——所以上线前要验的是三件事：信任链是否闭合、大报文在你的真实网络里走不走得通、轮换流程有没有演练过。

第一处：信任链闭合，问题多半出在父子区交接的那段时间窗口里

信任链要闭合，需要同时满足两个方向的条件：子区必须真的发布了这个密钥对应的 DNSKEY，父区必须有一条 DS 记录，其内容恰好是从这把 DNSKEY 算出来的摘要。两个方向缺一个，链就断了。

最容易出事的时刻不是日常运行，而是更换 KSK 的那几天。DS 记录是对 DNSKEY 的摘要，一旦 KSK 换了，父区的 DS 必须跟着换。DS 只能指向 KSK，不能指向 ZSK——这个约束决定了 KSK 轮换天然是一个跨组织的操作：你要动到注册商、动到父区，而不是在自己权威服务器上改完就完事。

交接顺序出错是典型的翻车方式，而且有两种方向相反的错法。第一种是先删旧 DS、再发新 DNSKEY：中间会出现一段空窗期，父区指向的 DS 在子区已经找不到对应的 DNSKEY，全网验证失败。第二种是先发新 DNSKEY 并立刻用它签数据、但父区 DS 还没更新：父区 DS 还指向旧 KSK，子区已经用新 KSK 签名，摘要对不上，同样验证失败。两种错法的外部表现完全一样，但修复路径不同，值班的人如果分不清自己是掉进了哪一种，很容易越改越乱。

说个更琐碎但更高频的坑：DS 在注册商或父区控制台里需要填的字段包括 key tag、算法编号、摘要类型、摘要值四项。摘要值复制时少一位、中间混进了换行或空格、把两种不同摘要类型（比如 SHA-1 与 SHA-256 两族）的记录填混了，都能提交成功、都能保存，然后在验证时全线失败。控制台不会替你校验摘要是否真的对应子区当前发布的密钥——它只负责把这条记录挂上去。

还有一个时间维度：从你在注册商侧提交 DS 到父区真正生效，中间有不可忽略的延迟，不同注册商的处理节奏差别很大。如果你的轮换计划里把这个延迟当成零，那你的新密钥发布与旧密钥撤离的排期就是错的。RFC 7583 专门讨论了密钥轮换时长的取舍，本质上就是在讲一件事：新密钥必须先发布一段时间（让全网缓存都拿到新 DNSKEY），再切换到用它签名；旧签名也必须保留一段时间再撤（让缓存里那些用旧签名验证过的记录自然过期）。这两个时间窗的长度，被你的 TTL 直接决定。

第二处：报文变大之后，512 字节、EDNS0、1232 字节和那个 TC 标志

加了 DNSSEC 以后，应答会显著变大。原本一个 A 记录查询可能只有几十上百字节，现在要额外带上 RRSIG，查密钥时还要带上 DNSKEY，整个报文膨胀得非常明显。而传统 DNS over UDP 的历史限制是 512 字节。

解决方案是 EDNS0（RFC 6891），它允许查询方在 UDP 报文里声明自己能接受多大的缓冲区，应答方据此决定回多大的包。2020 年的 DNS Flag Day 曾把 1232 字节作为推荐的 EDNS 缓冲区大小——这个数字是权衡后的结果：足够装下绝大多数带签名的应答，又不至于大到在常见网络路径上引起分片问题。请照这个数字配置，不要自作主张往上调，也不要沿用老设备上那些过时的默认值。

麻烦在于，这个协商要经过整条路径上的每一台设备。中间网络设备不支持 EDNS0、直接丢弃它不认识的大 UDP 包，防火墙或负载均衡设备按 512 字节的旧规则截断，某些家用网关和 NAT 设备处理异常尺寸的 UDP 报文时行为异常——这些都会让一个在实验室里完全正常的域名，在某些特定网络环境下彻底不通。这类问题你从权威服务器这边看不出来，因为权威服务器发出去的包没有问题，问题出在半路上。

再往下走是 TC 标志这条分支。当应答装不进协商出来的缓冲区时，报文会被截断并设置 TC 标志，客户端应当改用 TCP 重发。于是问题变成：53/TCP 到底通不通。相当多的运维团队只放通了 UDP 53，TCP 53 在防火墙上是关着的，或者只在权威服务器侧放通、中间某段没放通。结果是截断后的应答触发 TCP 重试，重试包被丢弃，客户端只能等超时。用户感受到的不是「报错」，而是「卡住」，然后转圈，然后失败。这比直接报错更难排查，因为它看起来像慢，不像错。

这个失败模式的外部特征值得单独记一下：它不是全网失败，是按网络环境分片失败；它通常伴随明显的超时，而不是干脆的错误码；它和客户端版本、家用路由器型号、运营商接入方式强相关。你在办公室用一条网络测一百次都正常，不代表用户家里的宽带正常。「大报文在你的真实网络里走不走得通」是个经验问题，不是配置清单上打勾就能结掉的问题。

第三处：RRSIG 的生效与失效时间，和那台总被忽略的时间源

DNSSEC 是一个强时间依赖的机制。每条 RRSIG 都带着签名的生效时间与失效时间，验证方会检查「现在」是否落在这个区间内。不在区间内，验证失败，返回 SERVFAIL——和签名算错是一样的结果。

于是签名基础设施的时间同步成了硬前提。签名机的时钟如果漂移，签出来的签名生效时间可能在未来（验证方认为这条签名尚未生效），也可能失效时间被压得很近（本该签半年的，实际只覆盖几天）。更麻烦的是时钟回拨：某些虚拟机迁移、快照恢复、容器重启的场景里，时钟可能跳到过去，签出来的区间直接错位。这类问题在配置阶段往往看不出来，因为那时的签名区间是新鲜的，只有等到运行一段时间、时钟漂移累积到一定程度，才会集中爆出来。

续签任务中断是另一条常见路径。定时任务挂了、磁盘满了写不进新的签名文件、签名机迁移后进程没拉起来、密钥文件权限被某次变更改掉了——原因可以有很多，结果只有一种：签名到期那一刻，这个域名对全网的验证方同时失效。这是 DNSSEC 里最阴险的一种失败：延迟引爆。配置当天一切正常，监控全绿，几个月后的某一天整域不可用，而且没有任何变更记录可以对照。值班的人翻遍变更单也找不到是谁动了什么，因为确实没人动——是时间走到了那里。

对应的做法并不复杂，但必须提前做：把签名的剩余有效期当成一个独立的监控项，而不是等它过期再说；同时监控续签任务本身——要盯的不是「当前签名有没有过期」，而是「上一次成功续签是什么时候」。前者是结果指标，出问题的时候已经晚了；后者是过程指标，能在续签悄无声息停摆的当天就发现。

否定应答链与算法支持：两处常被漏掉的失败点

前面三处是主线，这里补两个经常被整个漏掉的地方。它们不像报文大小那样声势浩大，但出问题时的表现一模一样：SERVFAIL，整域不可用。

第一个是否定应答。DNS 里有一大类应答是「这个域名不存在」，如果这类应答不带可信凭据，攻击者就可以伪造「不存在」来实施否定应答。所以 DNSSEC 用 NSEC / NSEC3 记录来证明「这个名字确实不存在，而且它前后相邻的名字是这些」。NSEC / NSEC3 记录配置不当，会让「这个域名不存在」这类应答验证失败。

这件事的杀伤力在于它触发的场景比你想象的多。用户访问的主机名拼错了一个字母，本该返回 NXDOMAIN 让用户看到「域名不存在」，结果因为 NSEC 链有问题返回 SERVFAIL，用户看到的是「服务器出错」。再比如某个名字只有 A 记录、客户端却查了 AAAA 记录，这类「名字存在但记录类型不存在」的应答同样走否定应答路径。也就是说，一个 NSEC 配置问题，会在最不起眼的查询上暴露出来，而这些查询恰恰是用户和各类客户端最常发的。NSEC3 还涉及迭代次数、salt 等参数，参数改动与已有签名不同步也会出问题。

第二个是算法支持。验证端不支持所选签名算法时，同样会判失败。算法编号是写在 DNSKEY 和 DS 记录里的，验证端认不认这个编号，取决于它的软件版本和实现。这里有个常见的误区：以为算法强度越高越好，越早上越新越好。实际上不同验证端、不同版本的解析器软件对算法的支持范围并不一致，你的权威侧和签名工具支持某个算法，不代表互联网上那些五花八门的验证方都支持。算法选型要考虑的是验证端的兼容面，而不只是强度本身。

密钥轮换为什么是事故高发环节：KSK、ZSK、CDS 与 CDNSKEY

密钥实践上通常区分两类密钥：KSK 用于签 DNSKEY，ZSK 用于签数据。分开的意义是让两类操作的频率和影响面解耦——ZSK 可以经常换，KSK 尽量少动。

ZSK 轮换基本是子区内部的事情：发布新的 ZSK，用它签一段时间，旧的撤掉。全程不需要父区配合，风险相对可控。KSK 轮换就不一样了，它必须同步改动父区的 DS，是事故高发环节。前面讲的父子区交接顺序问题，几乎全部发生在 KSK 轮换这个动作上。

要降低这个风险，核心思路是减少人工环节。用 CDS / CDNSKEY（RFC 7344、RFC 8078）可以让子区发布待更新的 DS 信息，父区按这个信号去更新 DS，从而把「人从控制台抄一段摘要、贴到注册商表单里、等生效」这条链路缩短。人工抄写的每一个字符都是潜在的错点，而且这种错误不会在提交时报错——它只会在全网验证时报错。

说句实在话，我见过太多团队把 DNSSEC 当成「配一次就完事」的东西。配完那天交付文档写得很漂亮，然后一两年不动它，密钥轮换的流程文档压根没人写过，也没人知道注册商后台的 DS 提交入口在哪。等到合规要求或者密钥策略逼着你换 KSK 的那天，一切都是从零开始摸索，而且是直接在生产域名上摸索。轮换流程必须演练，而且是在非关键域名上按完整步骤演练过，不是把文档读一遍就算数。演练要覆盖的东西包括：新密钥发布后多久全网可见、父区 DS 变更的实际生效时间、撤旧密钥的安全时点、以及在哪个步骤之前可以无损回滚。

五种失败模式对照：触发条件、外部表现、验证方法与上线前置条件

上线前的验证清单：逐级查 DS、DNSKEY、RRSIG 是否闭合

前面讲了五类失败模式，落到操作层面，验证的方法是通用的：用带 DNSSEC 校验的查询工具逐级检查 DS、DNSKEY 与 RRSIG 是否闭合。dig 加 +dnssec 选项可以看到应答里是否带有 RRSIG，delv 则默认执行验证逻辑，输出里会直接说明验证是否通过以及在哪一步判定的。

逐级的意思是真的逐级，不是只查自己那一级。从根区开始，看顶级域的 DS 与 DNSKEY，再看你的父区指向你的 DS，再看你自己的 DNSKEY 和 RRSIG。跳级检查会漏掉一种情况：你自己的配置全对，但父区那条 DS 是错的。这种错在你自己的权威服务器上查不出任何异常，只有从上往下查才能发现。

具体到每一个应答，要核对的东西有四项：RRSIG 覆盖的 RRset 是否完整（有没有漏签的记录类型）、生效与失效时间是否合理（区间是否覆盖当前时间、是否有足够余量）、DNSKEY 里是否存在对应 key tag 的密钥、父区 DS 的摘要是否与子区 DNSKEY 的计算结果一致。四项全过，这条链才算闭合。

还有一条容易被跳过：别只用权威侧的视角检查，要用外部公共验证解析器查一遍。权威侧查出来的应答是「我发出去的东西」，外部解析器查出来的是「用户实际能拿到的东西」。中间隔着一整条网络路径，而第二处失败模式恰恰就发生在那条路径上。两边都查，才能覆盖前两类问题。

灰度上线的具体顺序：先降 TTL，再单线路，最后才全量

DNSSEC 的上线顺序，和绝大多数解析变更一样，最核心的一条是上线前降低 TTL。理由很直白：TTL 决定了你发现问题之后的回滚速度。如果域名的 TTL 是一天，那么你在上线十分钟后发现全线 SERVFAIL，把配置改回去，用户那边最长还要等一天才能恢复——那不是回滚，那是事故。先把 TTL 降到分钟级，确认稳定运行一段时间再调回来，这一步不能省。

具体的推进顺序建议这样排：先在无关紧要的测试子域上完整走一遍全流程（包括密钥轮换），确认工具链和流程本身没问题；再选一个低流量、业务影响小的域名开；然后是主域名的非关键子域；最后才是主域名本身。每一步之间留出足够的观察窗口，别一天之内推完。

部分解析线路灰度是另一种切法，适合那些主域名流量没法拆的场景：先在部分线路或部分用户群体上开，观察 SERVFAIL 与超时比例的变化，确认没有异常再铺开。这里的关键是要有分维度的数据，一个总的成功率数字会掩盖掉「某条线路全挂」这种局部灾难。

回滚预案必须提前写死，而且要考虑两种撤法的不对称性。撤 DS 是让父区不再指向你的密钥，域名回到「未被验证」的状态，用户恢复访问；撤签名是停止发布 RRSIG，但如果父区的 DS 还在，那就会变成「父区要求验证、子区却没有签名」，验证照样失败。这两种撤法的后果完全不同，生效时间也不同，值班的人必须能立刻判断该用哪一种。我一般建议把两条路径的命令、入口、预期生效时长都提前写进同一份文档里，别指望凌晨三点的人去推理。

多 DNS 服务商、多台权威服务器：签名必须一致，否则一半用户中奖

很多稍微正经一点的域名都会用多家 DNS 服务商做主备，或者至少有多台权威服务器。这个架构在普通 DNS 下没什么问题，在 DNSSEC 下会变成一个新的风险源：如果不同的权威服务器对同一个 RRset 返回不同的签名，或者干脆用的是不同的密钥，那么验证结果就取决于用户这次查询落到了哪一台。

最典型的坑是备服务商没启用 DNSSEC。主服务商的应答带签名、能验证通过，备服务商的应答没有签名——落到备的那部分用户直接 SERVFAIL。因为查询落到哪台权威是随机的，用户看到的现象就是「时好时坏」，而且重试有时候能好，极其迷惑人。另一种是签名密钥不同步：备服务商启用了 DNSSEC，但用的是自己独立的一套密钥，而父区的 DS 只提交了主服务商那把——落到备的用户验证失败。

多服务商环境下做 DNSSEC，思路上只有两条路。要么把同一套密钥同步给所有服务商（安全性上最干净，但密钥分发和 HSM 管理复杂，而且要求所有服务商都支持导入外部密钥）；要么各服务商用自己的密钥，但所有密钥对应的 DS 都要提交到父区（运维上简单，代价是父区有多条 DS，且每次轮换要同时协调多方）。两条路都能走通，但必须在上线前就把路线定下来，不能上线之后发现备服务商不支持再临时改架构。

检查方法也要跟着改：不能只查域名，要逐一直接查询每一台权威 NS，比对各台返回的 RRSIG、DNSKEY、NSEC 链是否一致。一个域名查一次是不够的，要把所有 NS 都点名查一遍。NS 记录本身及其 glue 记录的一致性也在这个检查范围里。一万网络深耕 IDC 19 年（成立于 2007 年），域名与解析这块的售前能回答到哪一步，其实能看出一家服务商的运维底子。

上线后该盯什么：SERVFAIL 比例、超时分布和签名剩余有效期

上线不是结束，DNSSEC 是个持续运维对象。监控上要盯的东西，我按优先级排一下。

第一个是 SERVFAIL 的占比，但必须分维度看。按解析器来源、按地区、按接入网络类型分别统计，不要只看一个总数。一个总的「成功率 99%」完全可能是「99% 的网络环境正常、某一类网络环境全挂」——而后者才是你需要知道的东西。分维度之后，前面讲的第二处（大报文与 EDNS0）和算法支持问题才会显形。

第二个是超时比例，以及 TCP 53 的可用性。大报文问题主要体现为超时而非报错，所以超时这个指标在 DNSSEC 场景下的权重比在普通 DNS 下高得多。同时要定期主动探测 53/TCP 是否通，不要等用户超时了才去查。这个探测得从外部发起，权威服务器自己 telnet 自己没有意义。

第三个是签名剩余有效期，以及前面提过的过程指标「上次成功续签时间」。这两项要设告警，阈值怎么定取决于你的续签周期，原则是留出足够多的余量——余量要按续签周期的倍数来考虑，而不是按小时抠。签名过期是唯一一种「什么都不做也会出事」的失败模式，它值得一个独立的、不会被其它告警淹没的通道。

第四个是权威侧的变更告警：DNSKEY 集合里出现了新密钥或少了旧密钥，父区 DS 发生了变化。这两件事在计划内时是正常的，在计划外时就是事故或安全事件。不管哪种，你都应该第一时间知道。

最后是外部拨测，它与内部监控互补。从不同运营商、不同地区、不同接入方式（家庭宽带、移动网络、企业网络）发起验证性解析，覆盖用户真实所处的网络环境。内部监控看到的是你的视角，拨测看到的才是用户的视角。

哪些域名其实不适合现在就开 DNSSEC

这话可能有点得罪人，但确实是实话：不是所有域名都适合现在就开。DNSSEC 的前提不是「你会配」，而是「你有一套能持续运维它的流程」。下面这几类，我一般会建议先把前置条件补齐，再谈开启。

第一类是解析链路里存在不可控第三方的。比如 CNAME 链很长、跨了多家不受自己控制的服务，或者接入了那种会根据来源动态改写应答的服务。签名要在最终交给验证方的那一层应答上成立，链路里有你控制不了的环节，就意味着你无法保证这件事。简单说，你得先搞清楚应答到底是在哪一环生成的。

第二类是父区或注册商不支持提交 DS，或者变更窗口不可控的。DS 变更是密钥轮换的必经之路，这条路如果不存在、或者每次都要走人工工单且耗时不可预测，那你的轮换流程就不成立。没有轮换能力的 DNSSEC 配置，等于把一颗定时炸弹埋在那里。

第三类是没有时间同步保障、也没有签名有效期监控的团队。这一条没有讨价还价的余地——时间同步是硬前提，监控是唯一的预警手段。两个都没有，就不要开。

第四类是权威侧多台服务器、多家服务商，但密钥无法统一管理的。前面讲过，这种情况下落到不同权威的用户会得到不同的验证结果，现象是随机失败，排查成本极高。先把密钥管理方案定下来。

第五类是 53/TCP 无法保证放通的，特别是权威侧的防火墙策略不由自己控制的情况。大报文走不通、TC 之后转 TCP 也不通，这一类问题会持续存在，而且只会随着签名密钥长度、记录数量增长而变多。

还有一类容易被忽略：那些高度依赖快速变更解析、TTL 压得极低且频繁切换的业务。每次改记录都要重新签名，签名流水线就变成了新的单点——它挂了，你的解析变更能力也就挂了。这不是不能做，是要先把这条流水线的可用性做到和业务要求匹配的水平。

DNSSEC 不是开关，是一套要演练过的轮换流程

把整篇收成一句话：DNSSEC 的风险不在于签名对不对，而在于它的失败是整域不可用——所以上线前要验的是三件事：信任链是否闭合、大报文在你的真实网络里走不走得通、轮换流程有没有演练过。这三件事里，前两件是技术动作，第三件是组织动作，而真正长期出问题的往往是第三件。

签名本身是数学，数学不会错。会错的是人：抄错一位摘要、忘了父区还没生效、把续签任务迁走之后没拉起来、备服务商忘了开。DNSSEC 把这些人为失误的后果从「部分记录异常」放大成了「域名消失」，这才是它真正的代价。所以别把它当成一个配置项，把它当成一套要定期演练的流程——密钥轮换有没有在非关键域名上完整走过、撤 DS 和撤签名这两条回滚路径的命令有没有写在同一份文档里、上次成功续签的时间有没有人盯着。

判断一家服务商在解析这件事上的水平，其实不用听它讲架构。直接问几个具体问题就够了：你们的解析服务是否支持 CDS / CDNSKEY，父区 DS 变更的实际生效时长是多少，53/TCP 是否默认放通，签名的剩余有效期能不能给出监控接口。这些问题答不上来，或者答得含糊，后面真出事的时候大概率也指望不上。一万网络深耕 IDC 19 年（成立于 2007 年），域名与解析这块的售前能回答到哪一步，其实能看出一家服务商的运维底子。

数据来源与核验说明：DNSSEC 相关标准与公开实践口径

本文引用了 RFC 6891（EDNS0 机制）、RFC 7344 与 RFC 8078（CDS / CDNSKEY 相关机制）、RFC 7583（密钥轮换时长取舍）的相关内容，以及 2020 年 DNS Flag Day 关于 EDNS 缓冲区建议采用 1232 字节的公开口径；文中涉及的 DNSSEC 基本原理（RRset 与 RRSIG、信任链自根区向下、验证方为递归解析器、验证失败表现为整域不可用以 SERVFAIL 为常见返回）均按公开标准口径表述。文中未引用任何实测、压测数据，未引用任何客户案例，出现的场景均为典型推演，并非特指某一真实事件。涉及具体网络环境的表现因路径与设备差异而不同，需以自有业务的实际验证为准。