要約

  • ARIN の Delegation Key 公開ガイドは、ダイジェストタイプ 3 の名前を MD5、長さを 32 としている。IANA が DS のタイプ 3 に割り当てているのは、現在非推奨の GOST R34.11-94 である。
  • 長さの欄には単位がない。GOST の 256 ビットは 32 オクテットだが、十六進表記では 64 文字になる。この違いだけでは API が受け入れる入力や拒否する入力は分からない。
  • 現在の IANA の四つの勧告欄はすべて MUST NOT であり、RFC 9906 の廃止方針に対応する。名前の訂正は利用の再承認ではない。本稿では API、ゾーン、署名ソフト、リゾルバーを試験していない。

表を読む前に、番号の所属を確かめる

同じ整数が書かれていても、同じ意味とは限らない。DNSSEC の設定資料では、特にこの前提が重要になる。ARIN の Reg-RWS 公開リファレンスは Delegation Key の中に複数の数値フィールドを置いている。そのうち DS ダイジェストの種類を示す番号 3 に、登録内容とは異なる名前が付いている。

公開表はタイプ 3 を MD5 と記載し、Digest Length の値を 32 とする。IANA の DS ダイジェストタイプ登録は、同じフィールドの番号 3 を GOST R34.11-94 とする。これは略し方や翻訳の選択ではない。二つの異なる暗号学的関数を、一つの登録番号の説明として並べた状態である。

対象は 2026 年 9 月 14 日に取得した公開資料だ。この日付は観察の範囲を示すが、問題の行がいつ追加されたか、いつ変更されたか、何年間続いているかを示さない。ほかに新しいアルゴリズムが載っていることから、ページ全体の更新履歴を推定することもできない。改訂の起点を示す証拠は得られていない。

そのため、この不一致を「ARIN が MD5 の DS を公開した」と読み替えてはならない。公開ガイドの説明、利用者が送ったデータ、サービスが保存したデータ、DNS で実際に公開されたデータは別の対象だ。本稿は秘密のアカウントや API キーを使わず、DS の送信も設定変更も行っていない。

それでも、単なる誤字として片付けるには意味がある。DS はタイプ番号とダイジェストのデータを組にして運ぶ。番号は、データがどの関数によるものなのかを読み手に知らせる。使いやすい名前はその理解を助けるが、サービス独自のプロトコル上の割り当てを作る権限にはならない。

ここから言えるリスクは条件付きだ。もしクライアントの作者が MD5 という説明に従って値を計算し、それをタイプ 3 と組み合わせれば、登録された関数の意味とは整合しない可能性がある。本稿は、そのようなクライアントや送信、公開回答を発見したわけではない。可能な経路と観測済みの出来事は分けておく必要がある。

algorithm と digestType は別の対応表

ARIN の資料では Delegation Key が Delegation Payload の一部となり、algorithm と digestType がそれぞれ示される。前者は DNSKEY のアルゴリズム、後者は DS のダイジェスト関数に関するフィールドだ。数値が同じ入力形式に含まれるからといって、両者を一枚のコード表として読むことはできない。

アルゴリズムの一覧には 5、7、8、10、13、14、15、16 などが載り、RSA、ECDSA、EdDSA の名称が添えられている。一方、ダイジェストの表には 1 が SHA1、2 が SHA256、3 が MD5、4 が SHA384 とある。長さの欄は順に 40、64、32、96 だ。ここで述べているのは公開資料の記載であり、実装の受け入れ一覧を検証した結果ではない。

ARIN は、アルゴリズムとダイジェストタイプの名前が入力された数値から決まり、入力された名前は破棄されると説明している。この説明どおりなら、別の名前を添えても数値の意味は上書きされない。利用者が数字から読み取る名前の正確さは、それだけ重要になる。ただし説明された処理と、現在稼働するサービスの返答は同じ証拠ではない。

実際にどの名前が返るのか、どの順番で検査するのか、特定の入力にどのエラーが出るのか、どの形式で保存するのかは調べていない。これらに答えるには、日時と条件を明確にした、適切に許可された実行の記録が必要だ。文書に書かれた規則を、その規則が動いたという記録に置き換えることはできない。

RFC 5933 は番号の所属を明確にする。同文書は ECC-GOST の DNSKEY 署名アルゴリズムに 12、GOST R34.11-94 の DS ダイジェストタイプに 3 を割り当てる。DS タイプ 3 は DNSKEY アルゴリズム 3 ではない。DNSKEY のプロトコルフィールドに入る 3 でも、たまたまその数字を含むキータグでもない。

入力となるデータも区別する

RFC 4034 は、DS のダイジェストタイプを、ダイジェストの構築に使うアルゴリズムの識別子と定義する。入力には、正規化された DNSKEY の所有者名に続き、DNSKEY のレコードデータが含まれる。後者はフラグ、プロトコル、アルゴリズム、公開鍵から成る。画面に見える公開鍵文字列だけを任意にハッシュする、という説明では足りない。

関数の選択、入力データの構成、結果の文字表現は別々の説明項目だ。関数名を直したからといって入力の扱いまで確認されたことにはならない。入力が適切でも、長さが何を数えるのかはなお説明が必要である。クライアントの保守者にとって、対応表の目的はこうした区別を明確にすることにある。

IANA の現在の登録と RFC 5933 の元の割り当ては、タイプ 3 が GOST である点で一致する。現在非推奨とされていても、番号が空席になったわけではない。歴史的な番号の意味を残すことと、新しい用途で使うことを勧めることは違う。登録表は前者を維持しながら後者を禁止できる。

本稿は MD5 がすべての DNS 関連技術から存在しないと主張しているのではない。そのような広い命題には別の調査が必要になる。確認したのは、DS ダイジェストタイプ 3 に割り当てられた関数が MD5 ではないという、限定されたフィールド上の比較だ。結論の範囲を保つほど、訂正すべき場所も明確になる。

「長さ 32」の単位が書かれていない

名前の不一致は直接比較できる。一方、長さの値からは慎重に推論する必要がある。ARIN は欄を Digest Length と呼ぶが、単位を記さない。隣接する 40、64、96 は十六進文字数と整合する。この並びは読み方の手掛かりになるが、稼働サービスが同じ文字数制限を適用するという証明ではない。

RFC 5933 の GOST ダイジェストは 256 ビットである。一つのオクテットは 8 ビットなので、データは 32 オクテットになる。十六進数では一つのオクテットを二文字で表すため、同じデータは 64 文字だ。RFC 4034 の DS 表示形式は大文字小文字を区別しない十六進数であり、空白も許している。

したがって、データ量と整形された文字列の長さをそのまま交換してはいけない。もし ARIN の欄が十六進文字数を意味するなら、32 はタイプ 3 の GOST の長さを表さない。もしオクテット数を意味するなら、32 は GOST に合うが、隣の値には別の説明が必要だ。公開ページだけではどちらかを決定できない。

求められる文書上の修正は、単位を明記し、表示上の空白をどう数えるかも説明することだ。読者の合理的な推測を、暗黙の受け入れ仕様にしてしまうのは適切ではない。たとえ後日単位が明らかになっても、それは説明の証拠が増えるのであって、自動的に一件の実行試験が生じるわけではない。

本稿は、64 文字の入力が拒否されるとも、32 文字なら成功するとも示していない。デコード、空白の処理、検査順序、返すエラー、保存形式は未試験だ。名前の誤りと単位の曖昧さを一緒に見つけても、その組み合わせから実装全体の欠陥を確定することはできない。未確認の問いは未確認のまま残すべきである。

正しい名前に戻しても利用は戻らない

タイプ 3 の名前を GOST に直すことには、もう一つの境界がある。現在、GOST R34.11-94 は DNSSEC で利用すべき方式ではない。2025 年 11 月発行の RFC 9906 は ECC-GOST と GOST R34.11-94 を退役させた。現在の IANA ではタイプ 3 の四つの勧告欄がすべて MUST NOT となる。

四項目は委任での利用、検証での利用、委任向けの実装、検証向けの実装だ。古い RFC 5933 の任意実装という記述は、当時の状態と割り当ての由来を説明する。後の退役規定に優先するものではない。古い MAY を現在の検証許可として引用すれば、名前の誤りを直す過程で別の時点の誤りを作ることになる。

歴史的な設定で出会う番号を識別、点検、変更、削除するために説明することはあり得る。しかし、それは新たなデータ生成の推奨ではない。本稿は ARIN に特定の互換経路や削除機能があるかを試験していない。この区別は記述の役割についてのもので、製品機能を認定したものではない。

RFC 9906 は検証状態も区別する。退役した方式だけによる経路しかなく、ほかに受け入れ可能な認証経路がない場合、規定する扱いは insecure である。退役方式で検証して bogus と判定することとは異なる。どちらも単純に名前が到達不能だという意味ではない。ARIN の実際のゾーンで、そうした状態を測ったわけでもない。

本稿の中心は退役方針全体の解説ではなく、特定の入力フィールドの名前と割り当てが食い違う点にある。退役の現行規定は、訂正を新規利用の助言に変えないための境界として必要だ。番号の正しい名前を説明することと、それを選ぶべきかを説明することを、一つの結論にまとめてはいけない。

親側の DS は DNS 全体ではない

ARIN の逆引き DNS ガイドは、運用上の位置を示す。逆引きゾーンを保護した後、運用者は親に DS データを通知し、ARIN Online または RESTful の設定サービスで委任ごとに管理できるとする。問題のフィールドは、子側の鍵の材料と親側で示す情報との境界にある。

この境界は重要だが限定的でもある。親側の DS を管理することは、子ゾーンを署名することでも DNSKEY を公開することでもない。すべてのリゾルバーを管理するわけでもない。誤った説明がある人の理解に入ったとしても、すべての境界を越えて公開 DNS データになったことは、公開資料だけでは分からない。

番号資源への権限も、この文書上の問題から新しく生まれるものではない。ARIN が説明しているフィールドを正し、単位を明らかにし、退役済み番号の扱いを別途示すという要求は、既存の説明責任の範囲で足りる。アドレスに対する制裁や、ほかの運用サービスに対する制限へ広げる根拠はない。

比例した要求は明瞭だ。タイプ 3 の記述を登録と一致させ、長さの計数方法を説明し、歴史的識別と現在の利用方針を分ける。実際の受け入れ条件を争うなら、その実行証拠を別に用意する。この比較は既存 DS の予防的削除や、未試験の鍵切り替えを勧めるものではなく、安全な切り替え手順も提供しない。

資料ごとの役割を混ぜない

今回の六つの文書は、六回の独立した実装監査ではない。ARIN の表はインターフェースの説明、IANA は番号の登録、RFC 5933 は元の仕様、RFC 9906 は現在の退役方針を担う。RFC 間には更新の関係があり、IANA は ARIN の動作を検査した機関として引用されているのではない。

比較の際は、問題の行を文脈から切り離さないことも必要だ。MD5 だけを抜き出すとフィールドが消え、3 だけなら別の DNSKEY 項目と混ざり、32 だけなら単位のない説明を確定した制限へ変えてしまう。名前、番号、単位を元の場所に戻すことは証拠の整理であり、新たなネットワーク試験ではない。

名前の修正は割り当てとの不一致を、単位の追記は表示の曖昧さを、退役状態の説明は時点の混同をそれぞれ解消する。すべて完成しても、過去のクライアントが何を送信し、サーバーがどう処理し、リゾルバーが何を見たかは別の問いである。訂正に無限の責任を負わせるのではなく、完了したことと未観測のことを識別するための区別だ。

未試験の部分を未試験と明記すれば、誤ったデータが既に存在すると暗示せずに追加調査を提案できる。保守者は自分の対応表の出所を確認すべきか判断し、運用者は曖昧な危機感だけで設定を変えずに済む。透明性の価値は、より多くの操作を急がせることではなく、操作の根拠と権限と影響範囲を明確にすることにある。

資料