US.KG 数字平台 FreeDomain 账户数据与产品策略管理：联系人数据、隐私与账户安全实战指南

本文基于 US.KG 教程仓库中 1.5-account-and-policies.md 展开，聚焦 FreeDomain 注册平台（DigitalPlat）中“账户数据与产品策略”这一注册域管理主题：讲解如何保持注册联系人数据准确、理解 WHOIS/RDAP 公开可见性、正确对待当前生效的产品策略、加固注册账户安全，以及在联系官方支持时提交最小必要证据。读完本文，你将掌握一套可落地的账户数据维护、隐私保护与账户安全操作清单，并能结合 5.4-registration-data.md、5.5-security.md 等操作章节完成真实场景下的变更管理与密钥泄漏自查。

为什么“账户与策略”属于注册域管理

注册数据与产品策略之所以归入 DigitalPlat 类别，是因为它们影响的是所有权与注册资格，而不是外部 DNS 区域（zone）的内容。这一点与 1.0-product-boundaries.md 中的产品边界定义完全一致：

• DigitalPlat 负责：账户注册与登录、域名可用性与注册、命名空间策略确认、外部权威 nameserver 提交、域名状态与到期信息、续订流程、注册联系人数据管理、产品通知；
• 外部权威 DNS 服务负责：A、AAAA、CNAME、MX、TXT、CAA、SRV 等记录。

因此在排查问题前要先分诊：如果域名状态正常但 A、CNAME、MX 记录缺失，应排查外部 DNS 服务而非注册状态（参见 1.4-status-and-renewal.md）；而联系人信息、策略合规、账户安全等问题，则属于本文覆盖的注册域范围。

保持注册联系人数据准确

注册数据用于标识域名责任主体。在账户的联系人数据区域，应定期核查以下字段：

字段	说明
姓名或组织名称	域名责任主体，必须真实有效
电子邮箱	可能接收账户恢复、策略通知与续费提醒
电话号码	按表单要求的格式填写
邮寄地址	完整的联系地址
账单地址（如适用）	与域名联系人信息分开维护

几个关键实践要点（结合 1.1-account-registration.md）：

1. 数据必须真实。注册表单将域名联系人信息与账单信息分开；如果界面提供“同一地址”选项，提交前要核对复制结果。不要使用虚构的教材式占位值作为真实注册数据。
2. 准确数据是服务链路的地基。数据不准确会直接影响：账户恢复（recovery）、平台通知送达、续费（renewal）流程，以及策略合规。project-overview.md 将“保持注册数据准确”“持续保持对账户邮箱的访问”列为责任所有者的核心义务。
3. 变更后验证。按 5.4-registration-data.md 的变更管理流程，更新注册数据后应：
   • 确认 Dashboard 显示的是目标值；
   • 验证重要通知能送达新邮箱；
   • 如适用，复查公开注册数据；
   • 记录变更日期与责任人。

理解公开可见性与隐私控制

公开注册数据与隐私控制取决于命名空间和当前策略。注册数据可能通过 WHOIS、RDAP 或命名空间专属查询系统对外可见；部分字段可能被遮蔽（redacted），但 nameservers、注册日期、状态等运行数据通常保持公开（依据 5.4-registration-data.md）。

隐私实践要点：

• 不要用虚构数据规避可见性。规避公开展示的意图如果通过假数据实现，会带来恢复与合规风险；正确做法是提交前阅读产品当前的隐私说明。
• 组织域名的推荐做法：使用组织控制的联系邮箱；政策允许时使用受监控的职能邮箱（role email）；恢复访问权限不要绑定在单个员工的设备上。
• 截图脱敏：不要发布包含完整联系人信息、账户 ID、余额、私有域名或会话数据的 Dashboard 截图。dashboard-tour.md 给出了裁剪清单：仅保留解释操作所需的最小界面区域，排除浏览器地址栏、完整姓名与地址、邮箱与电话、账户 ID、余额与无关订阅数据、私有域名、API 密钥/cookie/会话值。
• 默认 DNS 记录值公开。假设你在外部 DNS 中填写的记录值任何人都可读，不要把内部主机名、IP、备注信息当作私密信息写入 TXT 等记录。

正确对待“当前策略”

提交或更新联系人数据前，应阅读当前生效的策略文档：

• 服务条款（Terms of Service）
• 可接受使用政策（Acceptable Use Policy）
• 隐私政策（Privacy Policy）
• 命名空间专属规则（suffix-specific rules）
• Dashboard 上的最新通知（notices）

两个重要边界：

1. 本仓库教程不具备策略效力。教程是教育性质，不能覆盖服务方当前展示的策略。支持的后缀、暂停状态、免费/付费名额要求、账户限制与续费规则都可能变化，Dashboard 通知板和注册表单才是当前事实来源（见 project-overview.md）。因此不要依据旧截图或旧 README 向他人保证某个域名“免费、可用、可续费”。
2. 高风险用途明确禁止。5.6-acceptable-use.md 指出：不要用域名从事钓鱼、恶意软件、凭据窃取、垃圾信息、冒充、未授权代理、欺骗性跳转、违法内容或违反现行政策的活动。同时要防护表单、文件上传、跳转、用户生成内容和被遗忘的子域名——合法项目也可能因未打补丁的应用或遗留 DNS 记录而被滥用。

注册账户安全清单

注册账户的控制权可以被用来重定向该域名下的所有服务，应像生产基础设施一样保护。1.5-account-and-policies.md 给出的账户安全措施，结合 5.5-security.md 的细化建议如下：

• 使用唯一密码：由密码管理器生成并保存，不与邮箱账户共用。
• 单独保护恢复邮箱：恢复用邮箱应启用独立的多因子认证，恢复码不要和密码存放在同一未加密文件中。
• 启用可用的多因子认证：选择当前 Dashboard 提供的最强 MFA。
• 审查会话与关联账户：当界面提供这些控制项时，定期检查活动会话与已连接账户。
• 验证紧急消息：将“域名即将过期/被暂停”的紧急消息视为不可信，直到在官方 Dashboard 内核实——这是防范注册账户钓鱼的关键动作。
• 人员变动时移除旧管理员：结合 5.4 的人员/组织变更流程，在责任人离职前完成：如支持则迁移到组织控制账户、更新联系与恢复邮箱、轮换密码和 API 密钥、吊销旧会话与设备访问、交接内部文档与续费责任。

5.5-security.md 还建议维护一份恢复计划文档，记录：账户所有者、恢复邮箱所有者、已批准管理员、恢复码存放位置、续费责任人与事故联系人。

联系支持：提交最小必要证据

向官方支持或 issue 渠道求助时，只包含必要的信息：

• 域名（准确拼写）
• 当前状态
• 精确的错误消息
• 操作尝试的时间
• 不含敏感信息的复现步骤

同时必须移除：密码、token、cookie、完整个人地址、无关账户信息。若涉及代码仓库或自动化脚本，在发布代码或提交工单前可以执行密钥泄漏自查（来自 5.5-security.md）：

git status --short
git diff --cached
git grep -n -i 'api[_-]*key\|token\|secret\|password'

这类检查可能漏掉编码过或不常见的密钥，应配合专用密钥扫描器复查。如果密钥已被提交，仅删除可见行是不够的——应立即吊销或轮换凭据，再按项目事故流程处理仓库历史。

对于 API 密钥的安全使用细节（单一用途、最小权限、秘密存储、泄漏后轮换、删除未用密钥），可继续阅读 1.6-api-overview.md；本地环境变量参考模式：

export REGISTRATION_API_TOKEN='load-this-from-a-secret-store'

不要把真实值写入 shell 历史或已提交的脚本。

自查清单：账户数据与策略是否就绪

在完成本文各节后，可对照以下清单验证（合并自 1.5、5.4 与 5.5 章节要求）：

• [ ] 姓名/组织、邮箱、电话、邮寄与账单地址均准确且为当前值
• [ ] 已阅读当前 ToS、AUP、隐私政策、命名空间规则与 Dashboard 通知
• [ ] 未使用虚构数据规避 WHOIS/RDAP 可见性
• [ ] 密码唯一、MFA 已启用、恢复邮箱独立受保护
• [ ] 活动会话与关联账户已审查
• [ ] 紧急过期/暂停消息以官方 Dashboard 内核实为准
• [ ] 人员变动时已移除旧管理员、轮换密钥与会话
• [ ] 支持工单只含最小必要信息，无密码、token、cookie 泄漏

完成上述项后，账户数据与策略层面的管理即可进入稳态：之后只需按 1.4-status-and-renewal.md 的续费提醒节奏（到期前 90/60/30/7 天）定期回访，并在每次变更联系人数据后重复执行变更验证流程。