DNSでISSの位置を確認する

 (shkspr.mobi)
3 ポイント 投稿者 GN⁺ 2025-07-07 | 1件のコメント | WhatsAppで共有
  • where-is-the-iss.dedyn.io はウェブサイトではなく、DNS LOC レコードだけで国際宇宙ステーション（ISS）のおおよその位置を返す、遊び心のある実験
  • DNS LOC は RFC 1876 の実験的標準で、ドメインレコードに緯度・経度だけでなく高度まで格納できる
  • LOC レコードの高度範囲は -100,000m から 42,849,672m までで、地下施設から静止軌道衛星まで表現できる
  • ISS の座標は N2YO API から取得し、LOC 形式に合わせるには高度を km から m に、緯度・経度を度・分・秒形式に変換する必要がある
  • deSEC API でレコードを更新し、TTL は 900秒 に設定して、15分ごとにベストエフォート方式で最新位置を反映する

DNS LOC レコードに位置を格納する

  • ドメイン名は通常サーバーを指すが、サーバーも結局はデータセンター内の物理的な位置を持つ機器である
  • DNS LOC レコードは、ドメインに緯度・経度・高度を格納できる DNS レコード
  • RFC 1876 は LOC レコードを定義した実験的標準
    • データセンターは高層ビル内や地下にある可能性があるため、高度パラメータも含まれる
    • 最小高度は -100,000m
    • 最大高度は 42,849,672m で、静止軌道衛星にも使える範囲

where-is-the-iss.dedyn.io

  • where-is-the-iss.dedyn.io は、ISS のおおよその位置をDNS クエリで得るために作られたドメイン
  • このドメインはウェブサイトではなく、ping もできず、DNS 以外の対話手段はない
  • Linux と Mac の利用者は次のコマンドで LOC レコードを確認できる
dig where-is-the-iss.dedyn.io LOC
  • 応答は ISS の緯度・経度・高度を LOC 形式で返す
;; ANSWER SECTION:
where-is-the-iss.dedyn.io. 1066 IN  LOC 47 24 53.500 N 66 12 12.070 W 430520m 10000m 10000m 10000m
  • DNS レコードは15分ごとにベストエフォート方式で更新される
  • Windows の PowerShell やコマンドプロンプトでは、LOC レコードを確認する方法を見つけにくいとしている

位置データを取得する

  • N2YO は、軌道上のさまざまな物体を追跡できるウェブサイトと、無料枠が比較的ゆとりのある API を提供している
  • ISS は N2YO API で衛星 ID 25544 として照会する
  • API 応答には satlatitude, satlongitude, sataltitude, timestamp, eclipsed といったフィールドが含まれる
{
    "info": {
        "satname": "SPACE STATION",
        "satid": 25544,
        "transactionscount": 7
    },
    "positions": [
        {
            "satlatitude": -21.25409321,
            "satlongitude": 140.3335763,
            "sataltitude": 420.09,
            "azimuth": 292.92,
            "elevation": -70.95,
            "ra": 202.69300845,
            "dec": -32.16097472,
            "timestamp": 1751366048,
            "eclipsed": true
        }
    ]
}
  • N2YO 応答の高度はkm 単位だが、LOC 形式では m 単位が必要
  • 緯度と経度は十進数で返ってくるため、LOC レコードに入れるには**度・分・秒（Degrees, Minutes, Seconds）**形式に変換する必要がある

deSEC で LOC レコードを更新する

  • LOC レコードの更新 API を提供する無料のドメイン名プロバイダーは多くなく、ベルリンの慈善団体 deSEC を選んだ
  • deSEC は API ドキュメント を提供している
  • 初期の LOC レコードは rrsets エンドポイントに curl で追加する
curl https://desec.io/api/v1/domains/where-is-the-iss.dedyn.io/rrsets/ \
    --header "Authorization: Token _______" \
    --header "Content-Type: application/json" --data @- <<< \
    '{"type": "LOC", "records": ["40 16 25.712 S 29 32 36.243 W 427550m 0.00m 10000m 10m"], "ttl": 900}'
  • レコード更新は少し厄介で、HTTP PATCH を別の URL に送る必要がある
  • PATCH リクエストには変更されたデータだけを入れればよい
curl -X PATCH https://desec.io/api/v1/… \
    --header "Authorization: Token _______" \
    --header "Content-Type: application/json" --data @- <<< \
    '{"records": ["40 16 25.712 S 29 32 36.243 W 427550m 0.00m 10000m 10m"]}'

更新間隔と限界

  • TTL は 900秒 に設定している
  • コードは15分ごとに実行され、DNS レコードを更新する
  • この間隔により、N2YO と deSEC の両方のAPI 制限内に収まる
  • TXT レコードに最終更新時刻やその他の非構造化データを入れることもできるが、このデモでは素早い概念実証として十分だとしている
  • DNS TXT レコードでデータを配布すれば、実質的にリクエスト制限のない API のようにも使え、静的または頻繁に変わらないデータにより向いている

DNS に入れられる風変わりなデータ

  • このデモは、DNS が予想外の種類のレコードも格納できることを示す、複雑で遊び心のある方法
  • ISS の座標を LOC レコードで表現したように、Mars Rover の座標をどう表現するかも想像できる
  • 関連する DNS 記事として、BIMI - SVG in DNS TXT WTF?! と Why you can't dig Switzerland がある

関連記事

1件のコメント

 
GN⁺ 2025-07-07
Hacker News のコメント

  • 別のレコードである Naming Authority Pointer（NAPTR） には、ヒューストンの Johnson Space Center の電話番号が入っている
    dig where-is-the-iss.dedyn.io NAPTR で見ると E2U+voice:tel と tel:+12814830123 が出てくる

  • API 制限は理解できるが、地球を 90分で一周 する物体に対して15分の更新間隔はかなり長く見える
    平均すると地球の周長の約 1/12、だいたいリスボンとイスタンブールの間くらいの距離だけ位置がずれる可能性がある

    • その通り。記事でも言っているように、これを ドッキング作業 に使ってはいけない
      無料で分単位の更新を許可してくれる DNS 更新方法を知っているなら、喜んで移行する
    • ISS の軌道速度は約 7.66km/s なので、15分で約 6,900km 移動する
      精密な位置追跡には明らかに大きな誤差だ

  • 最初の文を “I love DNS erotica” と読んでしまった。屋内に長くいすぎたので散歩に行けというサインだと思う

    • 意外かもしれないが、こういうものを掘り下げる人はけっこう多い気がする
    • 自分も最初そう読んだので、自分だけ変な人ではないと分かって安心した
      これから散歩に行ってくる
    • これがそれではなかったのかと思った
      冷水シャワーも必要そうだ
    • 「いつも DNS が問題だ」という言葉に、まったく新しい意味が生まれた

  • かなりいい。たった今 dns.toys にも追加した
    dig iss.sky +short @dns.toys
    [1] https://dns.toys

    • 本当にすっきりしている。ツールは全部 TXT レコード を使っているのか、それとも LOC や NAPTR みたいなものも使っているのか気になる
    • 天気のほうにバグがある。ブラチスラバが真夏に摂氏氷点下のはずはないし、タリンも約 17°C ほどずれていた

  • 素晴らしい。賢くて教育的でもある。JWST にも似たことができるのかすぐ気になった
    残念ながら DNS LOC レコード は約 4,200万メートル、つまり高度 42,000km 程度が限界だが、JWST はそれより38倍遠い約150万kmの距離にある
    そのため LOC の高度フィールドでは位置を表現できない。Hubble なら可能かもしれない

    • JWST は 第2ラグランジュ点 を周回しているので、どうなるのかよく分からない
      月の GPS 座標を尋ねるのに似ている。NASA は2023年に LRO で月面における弱い GPS 信号の受信を試験したが、まだ航法には役立たない
      ISS にこの方式が合っている理由は、地球表面上の 衛星直下点 があるからだ。高度に関係なく GPS 信号を受け取れる
      また TLE は、地球周回物体である ISS に適用される。TLE は地球周回衛星の位置と速度を軌道要素として定義し、SGP4 のようなモデルがそれを解釈するよう設計されている
    • おそらく 静止軌道（GSO） がちょうどその高度付近だからだと思う

  • 「RFC 1876 は実験標準だ」とは、本当に長く続いている実験だ
    University of Warwick, January 1996
    [1] https://datatracker.ietf.org/doc/html/rfc1876

  • DNS LOC レコードに関する追加資料: <https://www.ckdhr.com/dns-loc/>

  • 少し複雑だが、はるかに反応のよい方法は、where-is-the-iss.shkspr.mobi の NS レコード を自分の VPS の IP に向けることだ
    そのうえで UDP/53 と TCP/53 を待ち受けるプログラムを動かし、LOC レコードとメッセージ ID だけが動的に変わる DNS パケットを返せばいい
    DNS 仕様に完全には従わないだろうが、この用途には十分だ。API レスポンスはキャッシュして呼び出し制限を避けられる

    • 要はサーバーを運用したくないということだ。その代わりに 世界中に分散したシステム を乱用できる
    • その方式は DNS 仕様に完全に準拠している
      自分でもそういうサービスを運用していて、2+2.op.dyn.bortzmeyer.fr/TXT や paris.now.weather.dyn.bortzmeyer.fr/TXT でテストできる

  • DNS は 連合型、読み取り最適化、地理的複製、結果整合性を備えたキー・バリュー・ストアだ

  • RFC を見ても、なぜこれが必要だったのか説明がない
    1996年当時、大学やデータセンターの物流に関係する理由があったのだろうかと思う

    • 5.1節 “Suggested Uses” には、少なくとも曖昧な利用例がある
      LOC RR は、USENET バックボーンのフロー地図、IP パケットの地理的経路を示す「視覚的 traceroute」、管理対象のホストやルーターの地図を生成するネットワーク管理アプリなどに使えるとされている
    • 経験上、RFC は自分たちが解こうとしている問題をたいてい曖昧に書く
      これが “42 Wallaby Way, Sidney” のような人間が読める文字列ではいけない理由もない