摘要

  • RFC 10023 允许持有人在 _for-sale.<域名> 发布 TXT 记录；合规记录必须以区分大小写的 v=FORSALE1; 开头，并可用 fcod、ftxt、furi 或 fval 提供一种补充线索。
  • 记录只表达“可谈”。fval 是非约束性参考价，furi 不是安全认证；即使 DNSSEC 验证成功，也只证明 DNS 数据的来源与完整性，不证明发布者有权出售。
  • 可靠交易必须分别验证发现记录、区域写入权、注册人身份、代表权限、正式条款、资金结算、注册商过户和业务连续性。DNS 可以开启对话，不能替双方完成交易。

运营域名突然出现了价格

设想一家企业的主域名仍承担邮件、单点登录、API 与客户门户。资产监控平台却在它下面发现两条记录：一条写着 v=FORSALE1;fval=USD75000，另一条给出 HTTPS 地址。DNSSEC 验证成功，平台便贴上“已验证出售”的绿色徽章。

这时最重要的问题不是价格高低，而是“验证了什么”。

记录可能确实来自该区域的有效 DNS 数据，却由没有资产处分权的运维人员发布。它可能来自已泄露的 DNS API 凭据。联系地址可能属于代理商，但授权昨天已经撤回。参考价可能早已失效。所谓“出售”也许只是租用权，未必包括网站、商标、邮件数据或现有服务。即使注册商账户最终转移，DNSSEC、证书、邮件与身份系统仍可能同时中断。

RFC 10023 在 2026 年 7 月以 Informational RFC 发布。它定义的是一个克制的运营约定：域名持有人可在区域中加入保留的 _for-sale 叶节点，说明父域名可供购买；“for sale”也可以广义涵盖出租或转让合同使用权。该记录可以与正在运行的网站和邮件共存，也不要求修改 DNS 协议。

它补的是信息发现缺口。注册状态说明名字已经被注册，却不说明持有人愿不愿意谈。RFC 10023 让这种意愿能被标准化发现，但明确把谈判留在范围之外。

版本标签比说明文字更重要

一条合规记录必须准确、区分大小写地以 v=FORSALE1; 开头，中间没有空格。后面最多跟一个标签和值：

  • fcod= 是由合作处理者另行约定含义的不透明代码；
  • ftxt= 是供人阅读的简短文字；
  • furi= 是一个 URI 或 IRI；
  • fval= 是大写货币字母加数值金额。

同一 RRset 可以有多条 TXT 记录，同一标签也能出现多次，只要完整的标签—值组合不重复。处理者可以从中选择一条或多条。于是，DNS RRset 与屏幕上的“挂牌信息”从一开始就不是同一个对象：市场平台可能只认自己的 fcod，价格抓取器只展示 fval，人工查询工具则优先显示 ftxt。

合规审计应保存完整 RRset 和选择规则，而不是只截取最终卡片。否则平台做出的删选会被误认为域名持有人做出的声明。

还有一个容易反直觉的规则：只要版本标签有效，即使后续内容缺失或无效，处理者通常仍应认为父域名在出售，除非本地政策另有规定；此时可以通过 RDAP 等传统机制寻找联系信息。反过来，节点里即使写着“domain for sale”，只要没有有效版本标签，就不能按本约定视为出售信号。

版本标签负责“这是一个可识别信号”，补充字段负责“从哪里继续寻找”。两者都不负责“谁能签字成交”。

四种线索对应四种权力边界

fcod 的含义不在公共 DNS 中，而在合作方的约定和后端系统里。注册局、注册商或市场平台可以识别某个前缀，再把用户导向相应页面；即使 DNS 代码不变，后端仍可更换目的地。这能避免区域里直接保存任意链接，也便于集中维护。

同一个优点也是治理风险。外部观察者无法独立解释代码，审计者也无法只凭历史 DNS 回答“当时平台把它映射到哪里”。掌握映射历史的人，获得了对公开信号的实际解释权。

ftxt 适合解释资格、联系方式或补充条件，但它是非结构化输入。控制字符、Unicode 欺骗、脚本片段甚至看起来像 ;ftxt= 的字符都可能出现。一个合法 fcod 值可以包含类似另一标签的片段；简单按分号切割会凭空制造字段。

furi 让联系路径可以机器解析。RFC 推荐 HTTP、HTTPS、mailto 与 tel，并在适用时更倾向 HTTPS。但格式正确不等于目的地安全。规范明确警告钓鱼、恶意软件、脚本攻击与不当内容，处理者不得在未经用户明确确认时自动跳转。

fval 让价格更容易抽取，例如 EUR999 或 USD750。它的金额被明确界定为指示性、非约束性信息；可靠的当前信息仍需直接接洽。自动系统不应只凭该字段作出购买承诺，界面也应展示免责声明。

因此，这四项不是缩小版买卖合同。它们只降低发现和接触成本，不定义交易标的、身份、税费、担保、付款、接受方式或过户条件。

255 个八位字节强迫信号保持简短

每条记录的 RDATA 必须只有一个 character-string，最长 255 octets。多个信息需要拆成多条记录，不能把一份交易说明书塞进 TXT。RFC 1035 提供 TXT 与 TTL 的基础，RFC 10023 再定义这一用途的语法。

解析器必须处理原始 TXT RDATA，而不是把查询工具显示的转义形式当作真实内容。非 ASCII 内容应遵循 UTF-8 与 Network Unicode 建议；异常控制字符需要安全处理。价格或地址在错误解码后仍然“看起来合理”，并不意味着它等于权威服务器发布的值。

小格式的价值就在于它不假装无所不包。公共 DNS 适合承载短小、可互操作的发现信号。试图通过自由文本、编码代码或平台私有解释塞入更多权力，只会把关键语义转移到未经共同审查的外围系统。

叶节点位置决定出售的是谁

_for-sale.example 指向父域名 example。xyz._for-sale.example 不合规，因为 _for-sale 不再是叶节点。_for-sale.*.example 也不能一次性把一个区域下的所有名字挂牌。RFC 4592 解释 DNS 通配符机制，而 RFC 10023 明确排除了这种写法。

不过，已有通配符仍可能与查询发生交互，再叠加 CNAME 或 DNAME，生成看似属于另一名字或第三方域名的结果。采集器必须保留原始查询名、回答所有者、别名链、权威响应与通配符合成证据，不能只储存最后一段 TXT。

该叶节点可以位于多个 DNS 层级。若放在没有公开权利登记的子域标签下面，双方还需另行约定究竟转让什么权利。.arpa 下的记录必须忽略，因为它可能被误读为出售 IP 地址空间或 E.164 号码；特殊用途域名也不在本规范范围内。

RFC 8552 说明全局下划线名称为何需要注册：RR 类型与下划线名称的唯一组合避免不同用途碰撞。IANA DNS 参数注册表 已列出 TXT / _for-sale / RFC 10023。这证明命名得到分配，不证明任何一条记录真实、任何平台已经采用或任何发布者拥有产权。

RFC 10023 官方勘误页 当前有一项 Technical、状态为 Reported 的 erratum 9090，质疑 2.6 节表 1 把首个位置写成 “Root zone”，建议改用 TLD 或 zone apex 的表述。Reported 不等于 Verified，文章可以提示实现者注意，却不能把建议当作已经生效的规范改文。

一小时 TTL 不是一小时有效报价

域名不再出售时，持有人应删除记录。RFC 建议 TTL 不超过 3,600 秒，原因很实际：较长缓存会让已经撤回的意向或过期价格继续误导买家。

但短 TTL 只能限制 DNS 缓存，限制不了爬虫数据库、截图、经纪人后台或数据转售。平台可以在记录消失后继续显示卡片；代理授权也可能在 DNS 仍有效时被撤回。每次观察都必须带时间、TTL、解析器、完整回答和验证状态，并在联系、报价、接受、放款与过户等节点重新查询权威来源。

TTL 不是法律上的要约期限。记录缺失也不证明“不卖”：赎回期、pendingDelete 或 DNSSEC bogus 状态都可能让 DNS 无法返回可用答案。

DNSSEC 能验证 DNS，却验证不了董事会决议

RFC 4033 为 DNSSEC 划定了清楚边界：它提供 DNS 数据的来源认证与完整性保护，并不提供保密。验证成功的 _for-sale RRset 能加强一项证据——这些数据在相应 DNS 信任链下得到认证，传输中没有被无痕替换。

它没有解释数据为什么进入区域。

DNS 托管管理员可能有写权限，却无权处分域名。被盗 API 令牌写入的内容仍可能被区域签名流程忠实签署。经销商可能管理 DNS，注册人却掌握过户。DNSSEC 的“来源”是 DNS 信任链中的来源，不是公司法或合同中的授权主体。

RFC 9083 定义 RDAP JSON 响应，帮助处理者查看实体、状态、名称服务器等注册数据。但这些数据可能被遮蔽或按角色呈现；一个列出的实体并不自动证明受益所有权、内部审批、代理权限或不存在争议。

不同层的冲突不能用平均分抹平。DNSSEC 有效、代理身份不匹配、注册商账户锁定，应该形成暂停条件，而不是合成一个“中等可信”的购买建议。

从发现到交割，至少有八次独立证明

第一是发现：保存查询名、时间、完整 RRset、TTL、DNSSEC 状态、答案所有者与别名链。第二是区域控制：确认谁能通过注册商、DNS 托管、API 或委托写入记录，并保留变更日志。

第三是身份与权利：把 RDAP/注册商信息与经过验证的法律主体相互核对，并明确交易的是注册控制、租赁、许可、子域使用权，还是含商标与内容的资产组合。第四是代表权限：核实员工、经纪人或服务的授权范围、金额阈值、有效期与撤销状态。

第五是正式条款：现价、货币、税费、包含资产、陈述保证、争议地与接受方式都要进入版本化协议，并取代 DNS 提示。第六是资金与托管：证明资金、放款条件与欺诈审查。第七是注册商/注册局状态变化：确认解锁、授权码、账户推送、转移状态与最终注册数据。

第八是运行连续性：名称服务器、DNSSEC 密钥和 DS、邮件、证书、登录、API、续费与回滚都要有负责人。域名可以在商业上成交、在注册商系统中过户，却在用户体验上立刻失效。

这正是 Running-Code Primacy 的检验：权威 DNS 服务产生可观察信号，验证器产生安全判断，身份与合同系统建立主体和权限，注册商系统改变控制，业务系统决定服务是否活着。任何一个记录或徽章都不能通过宣告替其他系统执行。

Minimum Initial Specification 说明共同层为何应保持精简：世界可以共享一个严格的发现语法，却不必接受唯一市场、经纪商、托管机构或法律模型。地方解释可以自主，但必须可导出、可替换，且不能把自身结论夸大成公共协议授权。

Reality Layers 帮助拆开被绿色徽章压扁的现实：TXT 是符号层，区域写入和解析是运营层，注册权与代理权是制度层，报价与支付是商业层，服务是否继续是体验层。把它们全部叫作“已验证出售”，平台就在压缩信息的同时取得了权力。

Data Sovereignty 则揭示谁真正控制争议：能重建原始 RRset、区域历史、fcod 映射、身份、谈判、付款、注册状态与连续性的人。只拿到平台结论的客户拥有数据，却没有解释数据的主权。

来源