要約

  • LOCの検索には、ホストの直接情報がない場合にネットワークやサブネットの位置を使う任意の補完手順があった。補完後も、記録が説明する対象は変わらない。
  • 座標は千分の一角秒単位で表せる一方、水平誤差の既定値は直径一万メートルである。表現の細かさは測定精度ではない。
  • 大きさ、誤差、標高の基準、検索範囲を省いて一点だけ描けば、元の情報より強い主張になる。TTLやDNSSECも実測日時を証明しない。

答えが広くなる瞬間

あるホストの名前で位置を調べる。直接のLOCは見つからない。それでもアプリケーションは処理を終えず、そのホストが属するネットワークの位置を探し出す。地図には無事に印が現れる。

このとき、検索は成功したのだろうか。粗い地域が分かればよい用途なら、有用な結果かもしれない。しかし、一台の機器を実測した地点が必要だったなら、回答は別の対象について述べている。

1996年1月の実験的文書 RFC 1876 は、まさにこのような補完を認めた。詳細がなければ、より広い範囲を表示できるようにするためである。問題は補完そのものではない。補完であることが消え、同じ形の小さなピンだけが残ると、近似が測定結果のように見えてしまう。

この歴史を読む鍵は「座標が返ったか」よりも「誰の何について返ったか」にある。DNSの問いと地図上の断定の間には、アプリケーションの判断が挟まっていた。

名前から始める場合と、アドレスから始める場合

RFC 1876では、名前から検索するアプリケーションは、まずその名前のLOCを問い合わせる。CNAMEは通常の名前解決と同様にたどる。直接のLOCがなければ、関連するAレコードのアドレスを使い、ネットワークやサブネットの位置に進むことができる。

IPv4アドレスから始める場合は順序が異なる。最初にIN-ADDR.ARPAで逆引きし、得た名前についてLOCを調べる。それがなければ、やはり任意のネットワーク検索が候補になる。つまり、アドレスの逆引き名の直下にLOCを置くことを一律に要求した仕組みではない。

複数のAレコードを持つ名前では、関連するネットワークの位置も複数になり得る。どれか一つ、一部、全部を使うか、組み合わせるかはアプリケーション側の選択だった。文書が複数接続を持つホストに直接のLOCを勧めるのは、この曖昧さを減らす意味がある。

どの分岐も、実際に機器の場所を測る動作ではない。記録された地理的な説明を、名前とアドレスの関係から探し直しているのである。

ネットワーク名をたどる古い足場

補完の土台は、1989年の RFC 1101 にあるネットワーク名の表現だった。特定の逆引き名の下にPTRとA形式のデータを置き、ネットワークやサブネットの名前とマスクを得る。この文脈のA形式の値には、接続先ではなくサブネットマスクを示すものがある。

LOCの手順は、その仕組みを使って名前を集め、より具体的なサブネット側から広い側へ位置を探す。最初に見つかった位置を利用するが、それは通常のDNS名の親ラベルを単純に上る処理ではない。BGPの最長一致による転送経路選択でもない。

この手順には当時のIPv4とクラスを前提とするネットワークの考え方が残る。別のアドレス方式への適応可能性に触れていても、RFC 1876は一般的なIPv6拡張を定義してはいない。歴史的なアルゴリズムを、そのまま現在の設定手順として勧めるのは別の誤読になる。

ネットワークの位置をホストの近似に使った時点で、回答の利用範囲を説明する責任が生じる。返された所有者名と元の検索対象を残さなければ、後で見た人は近似に気づけない。

地図の保守を名前の持ち主へ

なぜDNSに地理情報を入れようとしたのか。以前のUUCP地図に記載されていたサイト情報には、集中的な更新や確認の負担があった。名前を管理する側が位置も保守できれば、変更の連絡を中央の一覧に集める必要を減らせる。

1994年11月の実験的 RFC 1712 はGPOSを提案し、ローカルで維持しながら広く問い合わせられる情報を目指した。SNMPのsysLocationが代理プログラムや局所的な場所の記述に結びつくこと、当時のX.500の普及状況なども比較されている。これらは1994年の設計背景であり、現在の導入状況を測った資料ではない。

GPOSは三つの数値文字列を使った。多くの小数桁を書けることと、その桁を正当化する観測があることは同じではない。さらに原文では経度と緯度の呼び方や定義に入れ替わりがあり、2006年報告の公式 正誤情報541 が指摘している。

この正誤情報の状態は「Held for Document Update」であり、「Verified」ではない。数値の並びを維持して名称を直す提案を、既に全面的に改訂された仕様として扱うことはできない。古い座標例をそのまま設定例に流用しない慎重さも必要になる。

後のLOCは別の形式を採ったが、RFC 1876はRFC 1712を廃止したとは宣言していない。IANAのDNSパラメーター一覧 にはGPOSの27とLOCの29がそれぞれ残る。番号の登録は形式の識別を可能にするだけで、利用数や保守状況を証明しない。

小さい物と、よく分からない場所

LOCは三つの区別を明示した。どこを中心として表すか。対象の広がりはどの程度か。その位置はどれほど確かか。この三つは同時に存在する。

SIZEは対象を囲む球の直径である。水平精度は誤差円の直径、垂直精度は垂直方向に生じ得る誤差の全幅を表す。いずれも値をそのまま「プラスマイナス」と読むものではない。直径と半径、全幅と半幅は区別しなければならない。

小さな機器の場所が大まかにしか分からないことはある。逆に、広い対象について基準点がよく分かっていることもある。対象の大きさを位置誤差の代わりに使うと、異なる情報を一つにしてしまう。

テキスト形式でこれらを省くと、SIZEは一メートル、水平精度は一万メートル、垂直精度は十メートルになる。文書は郵便番号から得られるような近似位置との関係を説明する。水平の一万メートルは直径であって、半径十キロメートルではない。

そのため、一メートルの対象と十キロメートル径の誤差円という組み合わせは不自然ではない。省略した情報が線上のレコードから欠けるわけでもなく、既定値として符号化される。

細かい単位が保証しないもの

バージョン0のRDATAは十六オクテットである。バージョン、SIZE、水平精度、垂直精度が各一オクテット、緯度、経度、高度が各四オクテットを占める。十六という長さはDNSメッセージ全体でも、リソースレコード全体でもない。

緯度と経度は千分の一角秒単位で、基準にオフセットを加えた整数として表す。赤道と本初子午線は二の三十一乗に対応し、それより大きい値は北または東を意味する。この形式の細かさは、情報源が同じ細かさで測ったという証明にはならない。

大きさと精度の一オクテットは、一桁の値と十進指数の組み合わせでセンチメートルを表す。半オクテットの値は零から九だけが定義され、零掛ける十の零乗は一センチメートル未満を意味する。誤差が厳密に零である、という宣言ではない。統計的な信頼水準も規定されていないため、円の中に一定の確率で存在するという説明を付け足してはならない。

高度の基準はWGS84の基準楕円体である。格納値の原点をその十万メートル下に置き、センチメートルで数えるので、楕円体に対する零メートルは一千万になる。これは符号化上の都合であり、地上の高さを百キロメートル増やす意味ではない。

平均海面と基準楕円体も同じではない。海面による近似を使うなら、高度や垂直精度を適切に扱う必要がある。テキスト側のメートルと線上のセンチメートルの違いも含め、同じ数字を見つけただけでは同じ位置だとは言えない。

新しい返答は新しい測量ではない

RFC 1035 のDNS資源レコードにはTTLがある。これはキャッシュをいつまで利用するかの情報であり、場所を最後に測った日を表すものではない。問い合わせたばかりの回答が、古い位置の記述を運ぶことは論理的に両立する。

RFC 4033 は、TTLによるキャッシュの整合性とDNSSEC署名の有効期間も区別する。DNSSECが提供するのはデータの出所の認証と完全性であり、測量ではない。したがって、正当に公開された値でも、古かったり、単位や対象の解釈を誤っていたりし得る。これは仕組みから導く限界であり、特定の障害を報告しているわけではない。

LOCには可視化したtracerouteやネットワーク管理地図という用途が提案された。しかし、ある名前に登録された場所から、パケットの実際の物理経路が証明されるわけではない。表形式の地点情報と経路の観測は別の証拠である。

公開にも注意が要る。GPOSはDNSに置く情報の公開性を明記し、LOCは高精度の場所が物理的な安全上の危険を増し得ると警告した。DNSSECは暗号化による秘密保持を提供しない。細かい位置を記載できるという能力は、細かく公開すべきだという判断ではない。