要約

  • 9月12日に取得したLACNICの公開ディレクトリには、75組の対応名から成る逆引きDNSデータファイル150件と、分離署名150件、公開鍵があった。
  • 抽出した一組はバイト単位で同一で、公開MD5も一致した。これは個別ファイルの有用な証拠だが、生成回全体の構成表ではない。
  • 目録がないことから、欠落、署名不良、DNS障害は導けない。全体をミラーする利用者に完了証明がない、という限定された問題である。

ディレクトリは、一つのファイルを取り出す人には親切だ。002-LACNICの横に同名の.ascと.md5があり、同じ場所にPUBLIC_KEYも置かれている。欲しい名前をあらかじめ知っていれば、検証に必要な材料へ迷わず到達できる。

ところが、全件取得を一つの単位として扱うと、問いが変わる。2026年9月12日15時21分UTCの取得結果には、データ名が150件あった。75件は002-LACNICのような3桁形式、残る75件は2.in-addr.arpa-LACNICのようなDNS形式で、数字による対応関係は全組で成立していた。

署名名は150件、MD5名は151件だった。後者には各データ名の分に加え、索引がサイズ0として示す*-LACNIC.md5が含まれる。README、manifest、SHA-256索引、releaseを示す名前はなかった。

これは公開画面をある時点で数えた結果であり、内部工程を見たものではない。したがって「LACNICに生成台帳がない」とまでは言えない。言えるのは、受信者が取得できる署名対象に全件の予定表がないことだ。

同じ内容の二つの名前

標本の二ファイルはともに2222バイトで、SHA-256も一致した。002-LACNIC.md5に書かれた値は、取得した内容から算出した値と同じだった。HTTPの最終更新時刻だけが1秒ずれていた。

この一秒差に異常の意味を与えるべきではない。互換性のための二つの名前を順番に書き出せば起こり得る。標本で確認できたのも、一組がその瞬間に同じだったことだけである。他の74組を比較したわけではなく、将来も同一であるとの約束も資料にはない。

中身は$ORIGIN .とNS委任行で構成されていた。権威DNSへのライブ問い合わせではないし、全サーバーへの読み込み結果でもない。配布ファイルの整合、権威系への反映、リゾルバーから見える応答は、それぞれ別の確認を要する。

個別署名が答えられない問い

RFC 9580の分離OpenPGP署名は、署名オブジェクトの外部にあるデータを対象にできる。受信者が鍵を目的に照らして受け入れ、実際に検証すれば、一ファイルの由来と改変を調べられる。

今回の調査環境にはOpenPGP検証器がなかったため、署名の成否も公開鍵の信頼性も判定していない。ここで評価しているのは、個別確認の材料をLACNICが公開しているという設計である。その制御は弱点ではなく、次の層の土台だ。

一方、002-LACNIC.ascには「同じ回に残り149件が必要」とは書かれていない。HTML索引から現在の件数は数えられても、その表示が更新途中か完了後かを署名で区別できない。Last-Modifiedも配信メタデータであり、版全体の合意事項ではない。

MD5はさらに役割が狭い。RFC 6151は衝突耐性が必要な用途にMD5を認めず、誤り検出だけを目的とする限定利用には余地を残す。標本の一致は転送確認に役立つが、発行主体も不足ファイルも証明しない。

現行方式を最も好意的に読む

このディレクトリは、そもそも原子的なスナップショット製品ではないのかもしれない。既知の一ファイルだけを独立して取得し、キャッシュする利用を想定するなら、細かな単位は効率的だ。全件を毎回配る必要もない。

二系統の名前も互換性を保つためなら合理性がある。個別署名まで公開している点は、匿名のダウンロード置き場より強い。だから改善案は現行方式を捨てるものではなく、全体取得という別の利用形態にだけ証拠を足すべきだ。

一生成回につき、一つの署名済み目録で足りる。版番号、バッチID、生成時刻、公開完了時刻、順序付きファイル名一覧を載せる。各行には組ID、名前の役割、バイト数、SHA-256、対応署名名を置き、採用した署名鍵のフィンガープリントと直前のバッチも明示する。

訂正時には過去版を消さず、新しい目録から置換対象を指す。二つの名前を意図的に違わせる場合も、その理由を役割欄に書ける。目録が証明するのは「このダウンロード集合をLACNICが完了版とした」という一点であり、DNSの正答性まで請け負わない。

ファイルごとの封印は既にある。冊子として必要なのは、何枚で一冊なのかを示す奥付だ。

出典