要約

  • ARINは直接割り振りを構成するCIDRブロックに合わせて逆引きの委派を作る。公式の例では/23は二つの/24、/16は一つの/16となり、後から顧客に渡す範囲とは必ずしも一致しない。
  • 共有管理の/16例外は、顧客が受け取る大きさだけでなく、ISPのどのブロックから再割り当て・再割り振りされたかで決まる。一方、DNSの親ゾーン側で子ゾーンを委派する方法は別に存在する。

小さいブロックのほうが二つに分かれる

ある企業がISPから/24を受け取り、その逆引きDNSを自社で管理したいと考えたとする。これは特定の利用者を調べた事例ではなく、仕組みを確かめるための仮定である。必要な範囲は明確に見える。自社のアドレスだけを扱い、隣の顧客には触れない。しかし、その/24に対応する独立した変更権限がARIN側にも用意されているとは限らない。

ARINの逆引きDNSの説明には、管理単位を考えるのに適した対比がある。直接割り振られた/23には二つの/24の委派ができ、それぞれのネームサーバーを別々に管理できる。対して、/16には一つの/16の委派ができ、ネームサーバーの管理もその単位となる。アドレス数が多いほど、登録簿に細かな操作対象が増えるわけではない。

理由は、後から生まれる顧客の区画に合わせて委派を作る方式ではないからだ。ARINは Direct Allocation、すなわち直接割り振りを構成するCIDRブロックごとに、対応可能な最大の委派を作る。IPv4で扱う境界は/8、/16、/24であり、最小の対応サイズは/24だ。/23そのものはこの境界にないため二つの/24になる。/16なら、そのまま一つで対応できる。

ここで重要なのは「直接割り振り」である。顧客への再割り当てが記録されたからといって、元の委派がその区画ごとに分割されるとは説明されていない。また、あるアドレスを含む任意の大きな集約ブロックを探せばよいわけでもない。判断の出発点は、実際の直接割り振りと、それに対応する委派だ。

この違いを、/16の保有者は/23の保有者より全体として権限が弱い、と読むのも適切ではない。一つの操作対象が、より広いアドレス空間を覆っている。比較すべきは権限の総量ではなく、登録簿で独立して編集できる単位である。なお、IPv6についてARINが示すのは4ビットごとの境界であり、以下の/16例外をそのまま移せるわけではない。

例外の条件は上流にある

ARINは、条件を満たす直接・間接の資源保有者が、共有権限によって逆引きDNSを共同管理する仕組みを説明している。対象ゾーンに表示される認可組織は、自らに委派されたアドレスの管理に関与できる。ただし、ISPの/16以上のアドレスブロックから行う再割り当て・再割り振りには、この共有管理が適用されないという明示的な例外がある。

顧客自身が/16を受け取った場合だけの話ではない。先ほどの仮定で、その/24がISPの/16から切り出されたのであれば、見るべき条件はその出所にある。「以上」もアドレス空間の大きさを指す。スラッシュの後ろの数字が16より大きいという意味ではなく、より大きい空間ならプレフィックス長は短くなる。

顧客の情報を登録できることと、この例外を越えてDNSを変更できることは別である。資源記録の管理に関する説明では、ネットワークの変更で名前、連絡担当者、公開コメントを編集できる一方、逆引きの委派は変更できない。資源の共有管理に関する一般的な説明は、DNS固有の条件と併せて読む必要がある。二つの文書が矛盾していると決めつけなくても、操作の対象が違うことを押さえれば整理できる。

共有権限には終了時の扱いもある。ARINは、接続を終了した顧客の再割り当て・再割り振り記録をISPが削除し、共有管理の権利を外すよう案内している。これは記録と権限の関係を示す運用上の説明であって、実際に放置された権限を発見したという証拠ではない。稼働中の顧客の記録を、権限整理の都合だけで取り消してよいという意味でもない。

登録簿の外で引き渡せるもの

では、仮定の企業は自社の逆引きを管理できないのか。ARINの編集権限が独立して付かないことから、そこまでの結論は出ない。次に確かめる場所は、ISPまたはそのDNS事業者が運用する親ゾーンである。

RFC 1034が説明するDNSの階層では、ゾーンの運用者は子ゾーンを委派できる。親側のNSレコードや、必要な場合のグルーレコードを整え、委派の境界の両側を整合させる。/16の下にある通常の/24であれば、この通常の子ゾーン委派によって、顧客が自分の範囲を運用する構成を組める。ISPのARINアカウントや/16全体の変更権限を渡すこととは違う。

ただし、プロトコル上できることと、あるISPがサービスとして提供していることは同じではない。親側の設定を誰が行い、ネームサーバーの変更時に誰が対応するかという合意が要る。子の内部を編集できても、親との接続に必要な変更まで独力で完結するとは限らない。登録画面に操作がないことはDNSの禁止を意味せず、DNSで可能なことは個別事業者の約束を意味しない。

256個未満のIPv4アドレスを扱う場合には、RFC 2317の別の工夫がある。追加の委派名とCNAMEによる参照を用い、DNSの検索手順を変えずに小さな範囲を管理する方法だ。それでも親側への依存は残る。この文書を根拠にARINが任意の/25委派を作れるとは言えないし、/16配下の/24にまで一律に必要な手法でもない。一般的な子ゾーン委派と、小さな範囲のための構成を混同しないことが肝心だ。

変更の単位は実物で確かめる

Reg-RWSの操作説明でも、ネットワークと委派は別の対象として扱われる。委派オブジェクトは関連するネットワークとともに現れ、消えるものであり、独立して作成・削除するものではない。識別にはNETハンドルではなく委派名を使う。NETに関連する委派を取得し、変更前に現在の内容を読むための操作も記載されている。これは公開された設計を読む作業であり、実アカウントでの権限試験ではない。

ARIN OnlineでのDNS管理手順には、実際の逆引きゾーン、ネームサーバー、DSキーのタグ、共有管理組織が並ぶ。ネームサーバーを変更すると、選択したすべての委派で以前の値が置き換わる。顧客の要望が/24に限定されていても、実際の選択がより広ければ、要望の説明が操作範囲を狭めてくれるわけではない。

同じ手順は、TTLを空欄にすると86,400秒となり、データベースは直ちに更新される一方、DNSへの反映には最大24時間かかる場合があると説明する。これは文書上の案内であり、実測した停止時間でも、あらゆるキャッシュが同時に消える保証でもない。ここでの要点は反映速度の評価ではなく、保存した内容と変更対象の範囲を取り違えないことにある。

2026年9月3日時点の資料から分かるのは、こうした管理境界の組み立て方だ。本稿では顧客の権限、DNS応答、移行、拒否、障害を測定しておらず、例外がどれほど多くの利用者に影響するかも分からない。正しいPTRがあることは経路、所有権、完全な本人性の証明にはならない。アドレスの登録から一歩進み、どの親ゾーンを誰が変えるのかを問うことで、初めて実務上の責任が見えてくる。