要約

  • PeeringDBが公開するAFRINICのASN 33764の記録は、IRR AS-SETを今も AS-AFRINIC とだけ表示する。一方、2026年の変更は、曖昧なIRR参照を解決しやすくすることを目指している。
  • 接頭辞は集合をどのIRRで探すか示せるが、メンバー、管理権限、鮮度、経路フィルターへの適合性までは証明しない。

レコードが示すこと、示さないこと

PeeringDBのネットワークレコード3803には、AFRINIC、ASN 33764、IRR AS-SET AS-AFRINIC が掲載されている。公開APIのスカラー項目 irr_as_set も同じ値を返す。ページには「IRR AS-SET Verified」という表示もある。ただし、確認できた公開ページとAPIには、どのIRRへいつ問い合わせたのか、どんな検証を行ったのか、どのメンバーを取得したのかを示す監査履歴は見当たらない。

更新日時も一つにまとめて読めない。APIのネットワーク本体の updated は2025年5月2日だが、PeeringDBはピアリングLANのサブレコードについて別に netixlan_updated を持ち、日付は2026年3月26日である。後者の更新日はAS-SET項目が同日に変わった証拠ではない。反対に、本体の日時が古いからといってレコード全体が陳腐化したとも言えない。IRR項目固有の更新・検証履歴は公開フィールドからは分からない。

PeeringDBの変更が扱うのは、より限定された問題だ。Issue #1973は、どのIRRの名前か分からない例、複数のIRRに同じ名前がある例、自動化の前に運用者が手作業で確かめる負担を記録した。8月19日の2.82.0リリースノートは、スマートなAS-SET名エディターを導入し、出所が明確な名前を先行修正し、曖昧な名前はネットワーク管理者に確認すると説明する。9月の更新記事は AFRINIC::AS-AFRINIC を出所付きの例として挙げ、不確かな場合の連絡にも触れている。これらは機能と整理手順を示すが、このレコードがなぜ裸の名前を保つのかは説明していない。

名前からメンバーへは距離がある

AS-SET名はメンバー定義を参照する名前であり、メンバー一覧の複製ではない。RFC 2622では、as-set のメンバーにAS番号や別のAS-SET名を含められる。PeeringDBの項目を使うツールは、IRRを選び、レコードを取得し、入れ子の集合を展開してからフィルターを作ることがある。同名レコードが複数のIRRにある場合、出所の接頭辞は最初の照会先を明確にする。

その効果は実質的だが、あくまで発見段階にある。接頭辞は、レコードが現在も存在すること、メンテナーが正当な権限を持つこと、メンバーがネットワークの意図した顧客を表すこと、再帰展開に欠落がないことを証明しない。参照、遅延したミラー、矛盾する複製をどう扱うかも決めない。名前だけでは、完成したポリシーが運用者の意図通りとは判断できない。

ここには運用上の差がある。自動処理が別のIRRを選んだり、空または一部だけの集合を受け取ったりすれば、想定した経路を除外するフィルター、あるいは不要な経路を許すフィルターを作る可能性がある。PeeringDBのIssue #1973もフィルターポリシーの誤りを潜在的影響として挙げている。しかし今回の調査は、ASN 33764で実際に誤りが起きたこと、AFRINIC自身のIRRに問題があること、このレコードが稼働中のフィルターに使われていることを示していない。仕組みとして起こり得ることと、確認された障害は別である。

引き継ぎに証跡を残す

安全な処理では、PeeringDBレコードとその版、選んだIRR、照会時刻、取得したレコードの識別子、展開後のメンバー数と結果ダイジェスト、後段のポリシーテストを一連の記録に残したい。「検証済み」という表示は役立つ場合があるが、判断材料とするには範囲と時点を知る必要がある。確認した公開ページとAPIには、表示と文字列はあるが、その監査連鎖はない。

したがって AFRINIC::AS-AFRINIC が意味するのは、どこを調べるかを絞ることだ。答えの正しさを保証するものではない。AFRINICの公開レコードに残る無修飾の値は、ディレクトリー、IRRレコード、経路判断が別々の制御面にあることを可視化する。接頭辞は受け渡しを明瞭にする。受け取る側には、何を受け取ったかを証明する責務が残る。

一次資料：PeeringDB Issue #1973、2.82.0リリースノート、PeeringDBの9月更新、AFRINICのPeeringDB記録、公開API、API仕様、RFC 2622。