📍 WDQWDWQD987AAAAA:216.73.216.105
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /62988f9742ca.html
📄

IP反查域名 - 改动前保存原始状态：先固化证据再动手

改动前保存原始状态的核心做法，是先把「此刻能查到的结果」变成可回看的证据，再动任何配置。对IP反查域名来说，这意味着一份带时间戳的结果快照，加上查询所用的方法与参数。只截图不记条件，或只记结论不存原始响应，都会让后续对比失去意义。

常见误解：截图就算留档了

很多人以为把反查结果页面截一张图，就等于保存了原始状态。问题在于，IP反查域名本身不是唯一确定的答案。同一个IP在不同时间、不同数据源、不同查询参数下，返回的域名列表可能不一样。截图只固定了「你当时看到的那一屏」，没有固定「你是怎么问的」。

一旦协作方拿到截图，无法判断：查询的是IPv4还是IPv6、是否包含历史解析记录、是否过滤了泛解析、结果按什么排序。这些条件变了，结果就会变，返工往往就出在这里。

保存原始状态要固定哪几类信息

一份能交付的原始状态记录，至少包含以下内容，缺一项都会给后续核对留下模糊地带：

• 查询对象：完整的IP地址，注明是IPv4还是IPv6，以及是否为单个IP还是网段。
• 查询时间：精确到日期与时分，最好带时区。反查结果随时间变化，时间本身就是证据的一部分。
• 数据来源：用的是哪类数据源，例如被动DNS记录、证书透明度日志、还是自有日志。不同来源覆盖范围不同，结论不能混用。
• 查询条件：是否包含历史记录、时间范围、是否排除共享主机或CDN地址。
• 原始响应：尽量保存未加工的返回内容，而不是只留整理后的表格。

把这几项放在同一个文件或同一份交付物里，别人才能复现你的查询，而不是只能相信你的结论。

一个可执行的最小保存流程

假设你要在调整解析或迁移服务前留档，可以按下面步骤做，示例中的IP与域名为假设，仅用于说明格式：

1. 记录查询条件，写成一行文本，例如：IP=203.0.113.10 type=IPv4 source=passive-dns range=all。
2. 执行反查，把原始返回内容另存为文件，文件名带上IP与日期，例如 203.0.113.10_2025-01-15.txt。
3. 对结果做一次只读整理，生成一份域名清单，但保留原始文件不动。
4. 把条件行、原始文件、整理清单放在同一目录，并在交付说明里写清哪个是原始、哪个是二次加工。

这样做的判断结果是：任何人拿到这份目录，都能重跑一次并对比差异。如果只有整理清单，差异出现时无法判断是数据变了还是整理时漏了。

哪些情况需要更严格的留档

不是所有场景都要做到这个程度。可以按下面的条件判断：

• 需要更严格：多人协作、改动会影响线上解析、结果将作为决策依据、可能涉及责任划分。
• 可以简化：个人临时排查、结果只用于自己参考、不对外交付。

另外要注意，反查结果里出现的域名不一定都归同一主体所有。共享主机、CDN、云服务商地址段上会挂大量无关域名。保存原始状态时不要顺手把这些都标记成「关联资产」，否则会把数据问题变成判断错误。需要确认归属时，应分别核对域名注册信息与解析记录，而不是仅凭同IP就下结论。

交付时怎么减少返工

在交付说明里写清三件事：原始状态保存在哪、查询条件是什么、整理过程做了哪些取舍。例如说明「已排除泛解析记录」「历史记录仅保留近一年」。取舍标准写出来，协作方才能判断你的结论适用范围。

如果改动后需要对比，用同一套查询条件重跑一次，再和原始文件逐项比对。条件不一致的对比没有意义，宁可重新查一次，也不要用两份口径不同的结果硬凑结论。

下一步：在下一次改动前，先按上面的清单建一个留档目录，把条件行和原始响应放进去，再开始改配置。