要約

  • 第 13 版は Best Current Practice を目指す DNSOP の active Internet-Draft であり、RFC、承認、実装証拠ではない。Datatracker は改訂版が必要な状態を示す。
  • サービス固有の DNS 名で発行済み token が一致すれば、challenge と record 出現の狭い因果関係を示せるが、付与する権限全体は記述しない。
  • 永続 record、CNAME 委任、更新 credential、サービス grant、ドメイン所有権は別々の寿命を持つ。
  • 新しい利用者による再検証は新しい所有権 epoch を始めるべきで、以前の利用者のデータや設定を自動的に再開してはならない。

現在の DNS と過去の資産を分ける

ドメイン制御検証は、申請者が対象名の DNS に影響を与えられるかを調べる。サービスが Unique Token を発行し、利用者が指定 TXT に置き、サービスが照合する。十分な一意性と予測困難性があれば、発行後にその値が現れたという因果関係を支えられる。

revision 13 はアプリケーション固有の underscore-prefixed owner name を推奨する。複数 TXT が存在しても、サービスは対象ドメイン向けに自ら発行した token と少なくとも一つが一致することを確認する。

この証拠が示すのは現在の challenge である。ドメインが以前誰に属していたか、どのアカウントが過去の設定やデータを作ったか、その資産を移す契約があるかは示さない。

ドメイン譲渡後に同じ名前を制御できるのは自然である。しかし、それを以前のアカウント entitlement へ直結させれば、DNS の現在性が履歴資産の所有権に化ける。

reintroduction は token 再利用より広い問題である

草案は、新しい所有者が過去に存在した Validation Record を再導入できる危険を述べる。永続検証では、元の利用者がまだサービスにアクセスできるように見える可能性がある。

同じ文字列が戻る経路は一つではない。ゾーンバックアップ、IaC repository、移行手順、古い vendor documentation、managed DNS template が値を復元する。新所有者は悪意なく実行できる。

サービス側は record の再出現だけで旧関係を復活させてはならない。token の発行 transaction、ユーザー、domain ownership epoch、service grant を結合し、過去の値は新 epoch で無効とする。

新所有者が旧値を見つけた事実も、以前の account secret を知る事実も、資産移転の承認ではない。recovery は別のワークフローである。

application-specific name は意味の境界である

challenge label は host name 衝突を避けるだけではない。DNS 管理者に provider と service を示し、別サービスの token が同じ場所で権限を得る可能性を下げる。

service confusion では、あるサービスが別 provider の challenge を自分の要求のように見せられる。利用者が正確に token を置いても、権限は期待外のサービスに渡る。照合は成功し、説明だけが偽になる。

provider、product、service は明確でなければならない。異なる privilege scope には異なる application name を検討する。公開説明は record が何を許可し、one-off か persistent か、誰が revoke できるかを示す。

account や resource の詳細を DNS に公開する必要はない。保護された authorization record に保持し、transaction ID と token digest で DNS receipt に結ぶ。

domain verified は権限の単位ではない

同じ DNS 制御は証明書発行、メール、custom hostname、hosting、social identity、configuration、future validation delegation に使える。作用範囲も寿命も異なる。

既存 scheme は狭い scope と広い scope を区別しないことがある。provider が一つの match で複数機能を開くなら、DNS 管理者は実際の承認内容を観測できない。

record 作成前に、人が読める scope statement を示す。provider、service、account、domain、resource、期間、persistence、revocation を含める。承認はその文に対して行い、DNS は関連 challenge の実行を証明する。

将来 product が機能を増やしたとき、古い verified state を自動継承してはならない。権限拡張は新しい承認 event である。

identity は各 handoff で変わる

application user が challenge を要求する。DNS administrator が変更する。intermediary が CNAME 先を運用する場合もある。resolver が回答し、provider が account に grant を付与する。

login は user を provider に認証するが、その user が DNS 変更を承認できるとは限らない。DNS 更新能力は domain path を示すが、application account との対応を証明しない。intermediary の応答は契約継続を示さない。

receipt は user、account、challenge、domain、owner name、token digest、provider、service、scope、issue/expiry、DNS response、CNAME、policy、decision、grant ID を保持する。どの join も推測で埋めない。

DNSSEC validation は DNS answer の信頼性を高め得るが product semantics を供給しない。強い account authentication も DNS administrator の informed approval を代替しない。

複数 TXT では一致した値を残す

owner name に複数 record があると、current、expired、別 user、別 flow の token が混在する。サービス仕様に従い少なくとも一つを一致させられても、「match」という一語では audit できない。

exact RDATA、発行 token、query time、TTL、CNAME chain、同時に存在した他の値を保存する。複数 character-string は連結して比較するため、presentation ではなく canonical comparison value が必要である。

expired token は消す。曖昧さと response size を減らし、将来 process が古い値を authority と誤認する面を縮める。削除 owner が不明なら、それ自体が governance failure の信号である。

expiry は grant の notAfter ではない

one-off validation の record は確認後に不要となることが多い。provider は challenge 有効時間と削除可能時点を明示する。draft は expiry metadata に timestamp または never を置く形も、out-of-band policy も認める。

token acceptance、DNS TTL、revalidation cadence、application grant、session、update credential、ownership epoch は別の時計である。TXT を消しても grant は残り得る。token が失効しても automation credential は新しい token に応答できる。

closeout は token rejection、authoritative deletion、cache window、revalidation stop、credential revocation、grant closure を別々に確認する。expiry=never は owner、review date、reason、withdrawal test を必要とする。

CNAME delegation は将来の応答能力を渡す

delegated validation は challenge name を intermediary に向け、persistent relation を recurring one-off validation に変換できる。手作業を減らすが、現在 token ではなく将来 process を承認する。

registry には intermediary、final provider、allowed services、domains、accounts、credential、duration、logs、review、exit を記録する。contract 終了、CNAME 削除、intermediary account 停止、provider grant 終了は同じ event ではない。

exit test では新 challenge を発行し、旧経路では完了できないことを証明する。同時に既存 grant の無効化も確認する。片方だけなら authority が残る。

持続する record は current intent の代用ではない。employee departure、vendor change、scope expansion、account migration は再承認を起動する。

public suffix は分母を大きくする

public suffix の ownership validation は多数 tenant に影響し得る。draft は一般に ICANN division の public suffix を受け入れないよう勧告し、private division には追加 safety check が望ましいとする。

underscore child を作れる tenant が suffix 全体を代表するとは限らない。validator は registrable boundary、delegated zone、実際の update authority を区別する。

DNS record は一つの node の状態である。application grant は多くの名前や resource を覆い得る。その差を query 成功後の暗黙推論に任せない。

draft status は強い結論を許さない

freeze 時点で revision 13 は Best Current Practice を目指す active DNSOP Internet-Draft である。Datatracker の WG state は issue により revised I-D needed と示し、IESG approval と RFC publication はない。

source は公式の threat model と recommendation を示すが、implementation、deployment、service confusion、account takeover、unauthorized certificate、実 incident を証明しない。冒頭は分析用に構成した例である。

改訂で requirement や例が変わり得る。system は draft number を永久 compliance badge にせず、document state と policy version を記録する。

ownership epoch を receipt の主キーにする

validation 前に user、account、provider、service、domain、registrable boundary、owner name、scope、persistence、token digest、issue/expiry を保存する。validation 時に response、CNAME、resolver、DNSSEC observation、policy、decision を追加する。

grant 時に resource、effective scope、grant ID、revalidation cadence、removal instruction を結ぶ。domain transfer signal があれば新 epoch を作り、旧 grant と resource を隔離する。

resource transfer は別 receipt を必要とする。旧 owner と新 owner、provider、registrar が持つ証拠を集め、decision と correction path を残す。DNS match 一つに背負わせない。

service outcome も独立である。validation が成功しても provisioning は失敗し得る。動作した service が新 grant を使ったとは限らない。

leadership が守るべき細い事実

今日の domain control は今日の challenge を支える。過去 account の所有権、全 product scope、永久 consent、future write authority、observed outcome までは支えない。

一つの緑色 “verified” を複数 system の authority にしない。token match、privilege grant、persistent relationship、ownership transfer、service result を別 event として測る。分からない join は unknown として残す。

出典