要約

  • UIXPは、AFDSP／NS2のAS37177とDotARPAのAS37181を、直接接続された別々のネットワークとして掲載する。AFRINICの導入ガイドでも、それぞれに異なるIPv4・IPv6サービスプレフィックスが割り当てられている。
  • NS2はゾーンデータをプライマリから受け取るセカンダリDNSであり、ゾーン内容を決める主体ではない。DotARPAは逆引きDNSの別系統であり、一方の観測結果を他方へ流用できない。
  • UIXP、RDAP、PeeringDBの記録は、識別子と相互接続面を示す。取得時点のBGP広告、ルートサーバー利用、問い合わせが到達したインスタンス、遅延、稼働率、耐障害性までは示さない。
  • 必要なのは地図の一点につき一枚の証明ではなく、サービスごとの受領記録である。ASN、プレフィックス、ピアリング方式、稼働・健全性、対象名前空間、観測地点、応答インスタンス、時刻を結び付ける必要がある。

同じ交換点にある二つの行

UIXPのネットワーク一覧は、掲載されたネットワークがピアリングLANへ直接接続されていると説明する。「AFRINIC - DNS - AFDSP」の行にはASN 37177、オープンなピアリング方針、参加年として2025年が記される。「AFRINIC - DNS - DotARPA」はASN 37181で、方針と年は同じである。組織名が同じでも、ネットワーク番号とサービス名は明確に分かれている。

さらにUIXPは、ルートサーバーを使っているか、どのプレフィックスを広告しているかを知るにはlooking glassを参照するよう促す。この一文が証拠の境界になる。ディレクトリは、交換網上に接続面があることを伝える。現在のBGPセッション、受け入れられたプレフィックス、フィルター、隣接ネットワークごとの経路選択を再現するものではない。

PeeringDBの公開APIにも二つの接続が現れる。凍結した応答では、AS37177とAS37181はいずれもUIXPのix_id 422に属する。AS37177のピアリングLANアドレスはIPv4で末尾が.5、IPv6で::5である。AS37181は.6と::6を使う。これらは交換網でルーター同士が経路をやり取りするためのアドレスであり、利用者が到達するAnycastサービスのプレフィックスではない。

ピアリングアドレスとサービスアドレスは、別の問いに答える。前者は「どこで経路を交換できるか」、後者は「その交換でどの宛先を学べるか」である。インターフェースが登録されていることからサービス経路が現在も見えるとは言えない。登録されたサービスプレフィックスから、その経路がUIXP経由で配布されているとも言えない。

公開地図がカンパラに一つの印を置くこと自体は、協力拠点を示す表現として成立する。しかし運用記録まで一つの印にすると、障害の切り分けに必要な差異が失われる。同じ交換面に二つのルーティング主体がいる、というのが資料から読める最初の事実だ。

AS37177が担うNS2

AFRINICのAnycast導入ガイドは、NS2をAS37177へ割り当て、IPv4サービスプレフィックスを196.216.168.0/24、IPv6を2001:43f8:120::/48とする。プログラムの説明では、アフリカの国別トップレベルドメインなどにセカンダリDNSを提供する地域基盤として位置付けられている。

「セカンダリ」は権限の境界でもある。AFRINICはAfDSPについて、ゾーンデータをプライマリサーバーから転送して受け取るサービスであり、ゾーン内容を管理しないと説明する。追加の権威DNSコピーを提供し、複数地点から到達できるようにする運用上の役割は大きい。それでも、名前やレコードを決める権限がコピー運用者へ移るわけではない。

この区別は、サービスを過小評価するためではなく、正確に評価するために必要だ。コンテンツの決定者と応答経路の提供者が分かれることで、障害時に何を誰へ確認すべきかが変わる。ゾーン転送が止まったのか、DNSプロセスが止まったのか、経路が消えたのか、そもそも問い合わせが別サイトへ送られたのかは、同じ「DNS不調」でも制御者が異なる。

また、本稿は既存のccTLD収容数の調査とは対象が違う。収容ゾーンの一覧は、どの委任やアドレスがNS2のプレフィックスと結び付くかを問う。UIXPで問うべきなのは、AS37177のサービスプレフィックスがウガンダの交換面で見え、どのネットワークがそれを学び、どの問い合わせが当該インスタンスへ届くかである。ゾーン集合の同定と、一地点の稼働状態は別の証拠問題だ。

AFRINICのRDAPは、AS37177と二つの公開アドレスブロックをAFRINICの組織記録へ結び付ける。資源識別として有用だが、ライブの経路表ではない。196.216.168.0/24または2001:43f8:120::/48が取得時にUIXPで広告されていたか、ルートサーバーと二者間セッションのどちらを通ったか、どのインスタンスが選ばれたかは分からない。

登録情報から一件のDNS応答までには複数の継ぎ目がある。プレフィックスが広告され、隣接網が受け入れ、経路選択が特定サイトを選び、そのサイトのDNSアプリケーションが健全で、問い合わせ対象のゾーンを保持して初めて応答になる。公開資料は識別子をよく説明しているが、未観測の継ぎ目まで埋めるものではない。

AS37181が担うDotARPA

DotARPAには別の組が割り当てられている。ASNは37181、IPv4は196.216.169.0/24、IPv6は2001:43f8:110::/48である。NS2の値と似ているため、一つの表に並べると小さな違いに見える。しかしASN、IPv4、IPv6、サービス目的の全てが別であり、似ていることは統合の理由にならない。

AFRINICはAS37181を、RFC 5855に関連する逆引きDNS基盤として説明する。RFC 5855はIN-ADDR.ARPAとIP6.ARPAに専用のネームサーバー識別子を設けた。他のDNS機能と全ての依存関係を共有せず、無関係な障害が逆引き木へ波及する範囲を抑えるためである。別のASNとプレフィックスは、その分離をルーティング層でも見える形にする。

だからといって、AS37181がアフリカの全ての逆引き問い合わせへ答えるわけではない。DNSは名前空間ごとの委任をたどり、再帰リゾルバーは参照とキャッシュを使う。Anycastでは、さらに送信元から見える経路が応答インスタンスを選ぶ。問い合わせ名、キャッシュ状態、経路、アプリケーションの健全性がそろわなければ、UIXPの行だけから応答地点を特定できない。

DotARPAとルートサーバーコピーも別物だ。AFRINICはルートサーバーコピーのプログラムについて、自らを促進者と位置付け、コピーの運用者ではないと説明する。DNS機能を地域へ分散するという広い目的は共有しても、権威、運用責任、障害の意味は共有しない。NS2、DotARPA、ルートコピーを「DNSノード」という一語で束ねれば、公共説明は短くなるが技術的な責任は読めなくなる。

AS37181のRDAPとPeeringDBも、登録資源と交換インターフェースを確認する資料である。経路広告や問い合わせ応答を確認する資料ではない。AS37177で得た成功をAS37181の成功として数えないことが、二つの行を保つ実務的な理由になる。

Anycastでは「現地」が測定結果になる

Anycastは、複数のサービスインスタンスが同じサービスアドレスを広告し、ルーティングが送信元ごとに到達先を選ぶ仕組みである。利用者がサイトを選ばなくても分散できる一方、「ウガンダにある」という文の意味は一層ごとに分けなければならない。

設備や仮想マシンが国内施設にある、サービスASNのインターフェースがUIXPにある、ローカルネットワークがサービスプレフィックスを学ぶ、ローカルのリゾルバーから送った問い合わせがウガンダのインスタンスで処理される。この四つは関連するが同義ではない。設備があっても広告が止まることがあり、経路があってもDNSプロセスが止まることがあり、アプリケーションが健全でも別サイトへの経路が選ばれることがある。

RFC 4786は、BGP到達性とアプリケーション健全性を分けて扱う。DNSが応答できないのにプレフィックスが広告され続ければ、ルーティングは故障したインスタンスへ効率よくトラフィックを集めてしまう。そのため運用者は、サービスの健康判定を経路撤回または受信抑止へつなげる必要がある。BGPの緑表示だけでは、DNSの緑表示にならない。

逆方向の不一致もある。DNSが健全でも、あるUIXP参加網が経路を学ばない場合がある。ルートサーバーを使っていない、二者間セッションが未成立、フィルターがプレフィックスを拒否している、自網の方針が別経路を好む、といった理由が考えられる。Anycastが選ぶのは地図上の最短距離ではなく、BGPに見えるトポロジーと方針に基づく経路である。

RFC 7094が複数地点からの測定を重視するのはこのためだ。一つのlooking glassは、一つの収集点から見た経路を示す。一回のDNS問い合わせは、一つの送信元と時刻における応答を示す。地域全体の傾向を語るには、分散した観測点、反復測定、応答インスタンスを識別する方法が要る。インスタンスが分からなければ低遅延がUIXPサイトによるものか判定できず、時間軸がなければ一度の成功を稼働率へ変換できない。

AFRINICはプログラムの狙いとして性能と耐障害性を挙げる。Anycast設計から見て妥当な目標である。本稿の凍結資料には、UIXP接続前後の比較、フェイルオーバー試験、継続稼働率、問い合わせのサイト別分布は含まれない。したがって「効果がない」とは言えない。同時に「効果を測定済み」とも言えない。設計目標、接続事実、測定結果を別の欄に保つべきだ。

ホストとAFRINICの責任も分かれる

導入ガイドは、ホスト側にBGP能力と、管理用・ピアリング用の二つのネットワークを求める。OVAを動かす環境について、公開された基準は仮想CPU二個、メモリー4GB、ディスク10GBである。これは受け入れ条件であって、UIXPで実際に一台か二台の仮想マシンを使うのか、物理ホストを共有するのか、冗長構成なのかを明かすものではない。

役割分担は明記されている。ホストは基盤、電源、ネットワーク接続を提供し、稼働条件を保ち、停止をAFRINICへ知らせる。AFRINICはソフトウェアと設定を保守し、セキュリティーを扱い、BGPを調整し、サービスの健康を監視し、ホストと障害対応を進める。共同運用として自然な分担だが、障害証拠は「AFRINICノード停止」より細かくなければならない。

経路が残ったままDNSが止まれば、健康判定と経路撤回の連携を調べる。ただし原因はソフトウェア、仮想化、電源、接続のいずれにもあり得る。DNSが健全なのにローカル網へ経路が届かなければ、ルートサーバー参加、二者間セッション、フィルター、参加網の方針を調べる。NS2だけ応答してDotARPAが応答しないなら、「AFRINIC DNSオンライン」という総合状態は誤解を生む。IPv4とIPv6が非対称なら、ASN単位でもまだ粗い。

必要なのは責任を一者へ押し付けることではない。サービス、ASN、アドレスファミリー、ピアリング方式、健康信号、観測インスタンス、各継ぎ目を直せる主体を一緒に記録することだ。それにより、原因が分からない段階でも、分からない範囲を正しく表せる。

記録を五つの証拠層に分ける

公開資料は五種類に分けると扱いやすい。第一はプログラム文書で、目的と設計上の役割を述べる。第二はRDAPなどの資源登録で、ASNとアドレスの登録主体を示す。第三はUIXPやPeeringDBの相互接続ディレクトリで、交換面のインターフェースを示す。第四はlooking glassや参加網RIBの経路観測で、特定時刻に見えた広告を示す。第五はDNS測定で、問い合わせと応答インスタンスを示す。

今回の資料には最初の三層があり、後の二層はない。後二層がないから接続を否定するのも誤りなら、前三層があるから性能を断定するのも誤りである。証拠層を分ければ、新しいデータが現れたとき何が更新されたかを説明できる。プログラム目標が変わったのか、登録が変わったのか、経路が変わったのか、応答が変わったのかを混同しない。

「オープン」というピアリング方針も、成立した全セッションの一覧ではない。相互接続への意思を表すが、各ネットワークが既に経路交換しているとは限らない。「2025」という参加年も、インストール日、初回広告日、最初の成功問い合わせ日にはならない。時間属性は何の出来事に付いているかを保たなければならない。

経路層の証拠は、ASNだけでなくプレフィックスを含む必要がある。AS37177ならNS2の二つ、AS37181ならDotARPAの二つを個別に探す。IPv4だけ見えたとき双方向の完全な展開と書かず、ルートサーバーの視点だけ得たとき全参加網の選択と書かない。少なくとも一つの参加網視点を照合できれば、交換設備の観測と利用者側の選択を分けられる。

DNS層では、単なるポート到達性では足りない。問い合わせ名と型、再帰か権威か、応答コード、回答内容の要約、応答インスタンスの識別方法、観測時刻を残す。ローカル性を主張するなら、遅延だけでサイトを推測せず、明示的なインスタンス識別を使う。ゾーン収容を主張するなら、期待一覧と実際のロード状態を照合する。耐障害性を主張するなら、故障、健康判定、経路撤回、別サイトへの移行を同じ時間軸に置く。

この分離は疑うための儀式ではない。何が既知で何が未知かを狭く保ち、運用上の次の質問を決めるための手段である。

一つのノード表示に二枚の受領記録

受領記録の先頭には不変のサービス識別子を置く。NS2はAS37177、196.216.168.0/24、2001:43f8:120::/48。DotARPAはAS37181、196.216.169.0/24、2001:43f8:110::/48。UIXP上の.5／::5と.6／::6は別欄のピアリングアドレスとして保存し、サービス宛先と混ぜない。

経路欄ではIPv4とIPv6を分け、期待プレフィックスが見えるか、どの収集点が、どの隣接先またはルートサーバーから、何時に学んだかを記録する。アプリケーション欄では、確認対象のサービスまたは名前空間、健康判定と経路制御の関係、インスタンス識別子を記録する。測定欄には観測地点、リゾルバー方式、問い合わせ名と型、応答コード、遅延、時刻を入れる。測定集合のハッシュがあれば、公開要約と元データの対応も検証できる。

一つの欄に全てを背負わせないことが重要だ。稼働開始の宣言は現在の経路を証明しない。経路はDNSの健全性を証明しない。一回の正しい応答は全ての対象ゾーンが収容されていることを証明しない。一観測点の低遅延は地域改善を証明しない。2025年というディレクトリ年は、導入日や初回応答日を証明しない。

現在の資料から言える強い結論は、限定されているからこそ有用である。異なるASN、サービスプレフィックス、DNS機能を持つ二つのAFRINICネットワークが、UIXPへ直接接続されたものとして掲載されている。しかし、関連する全問い合わせがウガンダへ着地し、遅延や耐障害性が改善したとは、まだ言えない。その結果が測定されたときは、地図の一点ではなく二枚の受領記録として現れるべきだ。

出典

  1. AFRINIC DNS Anycast導入ガイド：https://dns.afrinic.net/deployment-guide/
  2. AFRINIC DNSプログラム：https://dns.afrinic.net/
  3. UIXP接続ネットワーク一覧：https://www.uixp.co.ug/networks
  4. UIXPのサービスとルートサーバー：https://www.uixp.co.ug/services
  5. AFRINIC AfDSP説明：https://afrinic.net/dns-support.html
  6. AFRINICルートサーバーコピー：https://afrinic.net/root-server-copy.html
  7. RFC 5855：https://www.rfc-editor.org/rfc/rfc5855.html
  8. RFC 4786：https://www.rfc-editor.org/rfc/rfc4786.html
  9. RFC 7094：https://www.rfc-editor.org/rfc/rfc7094.html
  10. RFC 1034：https://www.rfc-editor.org/rfc/rfc1034.html
  11. AFRINIC RDAP、AS37177：https://rdap.afrinic.net/rdap/autnum/37177
  12. AFRINIC RDAP、AS37181：https://rdap.afrinic.net/rdap/autnum/37181
  13. RDAP、196.216.168.0/24：https://rdap.afrinic.net/rdap/ip/196.216.168.0
  14. RDAP、196.216.169.0/24：https://rdap.afrinic.net/rdap/ip/196.216.169.0
  15. RDAP、2001:43f8:120::/48：https://rdap.afrinic.net/rdap/ip/2001:43f8:120::
  16. RDAP、2001:43f8:110::/48：https://rdap.afrinic.net/rdap/ip/2001:43f8:110::
  17. PeeringDB API、AS37177：https://www.peeringdb.com/api/netixlan?asn=37177
  18. PeeringDB API、AS37181：https://www.peeringdb.com/api/netixlan?asn=37181