要約

  • RFC 10023 は、親ドメインが稼働中でも _for-sale の TXT レコードで購入、賃貸、利用権の譲渡が可能だと知らせる規約である。有効なレコードは厳密な v=FORSALE1; で始まり、fcod、ftxt、furi、fval のいずれか一つを付加できる。
  • 値は手掛かりであって取引ではない。fval は拘束力のない参考価格であり、furi は安全性を保証しない。DNSSEC も DNS データの出所と完全性を検証するだけで、法的な売却権限は検証しない。
  • 取得を正当化するには、DNS 観測、ゾーン変更権限、登録者の本人性、代理権、契約条件、決済、レジストラ移管、サービス継続を別々に立証する必要がある。

入口の標識を、所有権証明書と読み違える

ある企業のドメインは、今もメールと顧客認証に使われている。その配下で、取得候補を探すボットが 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 レコードを置ける。同一タグの異なる値も許されるが、タグと値の完全な組は重複できない。処理者は、その中から一つ以上を選んでよい。

ここで解釈の分岐が生じる。市場 A は自社の fcod だけを認識し、市場 B は fval を一覧にし、人向けの照会画面は ftxt と furi を出すかもしれない。どれも RRset 全体とは違う。画面を証拠として残すなら、同時に完全な RRset と選択規則も残さなければならない。

有効なバージョンタグがあり、その後が空または不正でも、ローカル方針が否定しない限り、処理者は通常「売却可能」とみなす。連絡先は RDAP などで探せる。一方、自然文がどれほど明白でも、有効なバージョンタグを持つ TXT が一つもなければ、この規約の表示としては無視する。

つまり、バージョンは表示の存在を伝える。任意のタグは次の行動の手掛かりを与える。いずれも、誰が契約を締結できるかは答えない。

fcod は見えない市場規則を持ち込む

fcod のコードをどう解釈するかは、DNS の外側で協力者が決める。レジストリやレジストラが接頭辞を認識し、販売ページへ変換できる。DNS の値を変えずに、中央のバックエンドで遷移先を変更できるため、運用上は便利である。

同時に、公開レコードの意味が私的な写像に依存する。第三者はコードだけでは理解できない。過去のある時点でどの URL を返したかは、処理者が写像履歴を保存しなければ復元できない。規格化された入口の先で、解釈権が一社に集中する余地がある。

ftxt は自由度が高い。資格条件や連絡方法を説明できる一方、制御文字、紛らわしい Unicode、危険なマークアップも入り得る。fcod の値中に ;ftxt= に見える文字列があっても、二つ目のタグにはならない。単純な文字列分割は、存在しない主張を作る。

furi は URI を一つだけ格納する。HTTP、HTTPS、mailto、tel が推奨され、適切なら HTTPS が望ましい。しかし URI の構文が正しくても、リンク先の評判や本人性は保証されない。RFC はフィッシング、マルウェア、スクリプト攻撃を警告し、利用者の明示確認なしに自動転送してはならないとする。

fval は機械可読な価格を提供する。法定通貨には標準的な三文字大文字コードが推奨され、暗号資産の略号も構文上は扱える。ただし値は明示的に非拘束・参考用である。現在の確実な条件は直接確認しなければならず、自動システムはこの金額だけで購入を約束すべきではない。

小さな RDATA は小さな主張に向いている

各 TXT RDATA は一つの character-string で、最大 255 octets である。RFC 1035 が TXT と TTL の基本を定め、RFC 10023 が用途固有の規則を加える。複数の情報は RRset 内の別レコードとして表し、一つの長い契約書に連結しない。

実装は照会ツールのエスケープ済み表示ではなく、生の RDATA を解析しなければならない。非 ASCII は UTF-8 と Network Unicode の指針に従い、予期しない制御文字は安全に表示する必要がある。見た目が似ていることと、同じバイト列であることは違う。

この制約は欠点ではない。共通層には、発見に必要な最小の構文だけを置く。本人確認、契約、決済を自由文や独自コードへ押し込めば、複雑さが DNS から私的な処理系へ移るだけである。

名前の位置を誤れば、別の資産を指す

_for-sale.example は親の example を対象とする。xyz._for-sale.example は _for-sale がリーフでないため非準拠である。_for-sale.*.example によって配下を一括販売することもできない。RFC 4592 のワイルドカード規則と RFC 10023 の制限がここで交わる。

既存のワイルドカード、CNAME、DNAME が応答を合成し、別名や第三者ドメインの表示に見える場合はある。収集側は照会名、応答所有者、エイリアス連鎖、権威応答、合成の有無まで残すべきで、最終 TXT だけでは足りない。

リーフは DNS の複数階層に配置できる。しかし公開レジストリのないサブドメインでは、そのラベルにどの権利が伴うかを別契約で定める必要がある。.arpa 配下は IP アドレス空間や E.164 番号の売却と誤解されるため、処理者は無視しなければならない。特殊用途ドメインも範囲外である。

RFC 8552 は、グローバルな下線付き名を RR 型と組み合わせて登録し、用途の衝突を避ける仕組みを説明する。IANA DNS Parameters には TXT / _for-sale / RFC 10023 が掲載された。これは名称割当の証拠であり、普及率、内容の真実性、売主の権限を示すものではない。

RFC 10023 の errata には、Section 2.6 Table 1 の “Root zone” を TLD または zone apex と表すべきだとする Technical erratum 9090 が一件ある。状態は Reported であり Verified ではない。実装レビューの注意点として扱い、確定した改訂とは呼べない。

TTL が切れても、噂は消えない

ドメインが売却対象でなくなったら表示を削除する。RFC 10023 は、古い可用性や価格が買い手を誤らせないよう、3,600 秒以下の TTL を推奨する。

だが、TTL が制御するのは DNS キャッシュである。クローラの索引、スクリーンショット、仲介業者のデータベースには効かない。短い TTL は正式オファーの有効期限でもない。観測には時刻、TTL、リゾルバ、完全な応答、検証状態を付け、接触、正式提示、承諾、資金解放、移管の節目で権威情報を再確認する必要がある。

レコードが見えないことも、不売の証明ではない。redemption、pendingDelete、DNSSEC bogus などで名前解決自体が失敗し得る。存在も不在も、観測条件を伴って初めて意味を持つ。

DNSSEC の署名者と、契約の署名者は違う

RFC 4033 によれば、DNSSEC は DNS データの出所認証と完全性保護を提供するが、機密性は提供しない。検証済み RRset は、関連する DNS 鍵の信頼連鎖の下で認証されたデータだという強い証拠になる。

しかし、ゾーン鍵の統制は法人の代表権ではない。DNS ホスティング担当者、委託先、退職者の残存自動化、侵害された API トークンが変更を起こし、署名系がその内容を正しく署名する場合がある。DNSSEC は DNS 内での出所を答える。登録者の実質的権利、取締役会の承認、仲介人の委任までは答えない。

RFC 9083 の RDAP JSON 応答は、登録データ、entity、status、nameserver の照合に役立つ。だが情報は秘匿や役割単位の表現を含み得る。RDAP に現れる主体が、受益者、最終意思決定者、契約代理人と同じとは限らない。

DNSSEC は有効、仲介者の身元は不一致、レジストラ口座はロック中という三つの事実を平均して「おおむね安全」としてはならない。別の層の矛盾は、取引停止の理由になり得る。

取引は別の状態機械を必要とする

まず発見時の完全な RRset、TTL、時刻、DNSSEC、応答所有者、別名連鎖を保存する。次に、誰がゾーンを書けたかをレジストラ、DNS ホスト、API、委任、変更記録から立証する。

登録者の法的本人性と提供される権利を確認する。登録管理権、賃借、利用許諾、サブドメイン、商標やコンテンツを含む資産譲渡は同じではない。交渉者については委任の範囲、金額上限、期限、撤回を確かめる。

正式な価格、通貨、税、対象資産、表明保証、受諾方法、紛争処理を版管理された契約に記録する。資金証明、エスクロー、解放条件は決済層で扱う。レジストラではロック、認証コード、アカウント移動、移管 status、最終登録データを確認する。

最後に、nameserver、DNSSEC の鍵と DS、メール、証明書、認証、API、更新設定を検証する。登録上の移転完了とサービス継続は別の完了条件である。

Running-Code Primacy は、拘束力ある事実がどこで生まれたかを問う。権威 DNS は表示を返し、validator はセキュリティ状態を作り、本人確認と契約系は主体と権限を確立し、レジストラは管理状態を変え、アプリケーションは稼働結果を生む。文書やバッジが、これらを宣言で代行することはできない。

Minimum Initial Specification の観点では、RFC 10023 の小ささが重要である。世界共通の発見構文を持ちながら、一つの市場、仲介、エスクロー、法制度を義務化しない。ローカル判断は可能だが、規則は持ち出せ、結論は主張範囲を越えてはならない。

Reality Layers で分ければ、TXT は記号、ゾーン更新と応答は運用、登録権と代理権は制度、合意と決済は商取引、サービス継続は利用経験である。「売却確認済み」の一語は、層を圧縮して画面運営者に象徴的な権力を与える。

Data Sovereignty の実務的な問いは、誰が再構成できるかである。生の RRset、ゾーン履歴、fcod 写像、本人確認、交渉、決済、移管、継続性を輸出できる主体が意味を支配する。結論カードしか受け取れない顧客は、データを見ても検証権を持たない。

情報源