DNSを使用して国際宇宙ステーションの位置を取得する

323日前原文(shkspr.mobi)

概要

DNS LOCレコード を使い、サーバーや衛星の位置情報をDNSで公開する技術の紹介
where-is-the-iss.dedyn.io で国際宇宙ステーション(ISS)の位置をLOCレコードとして配信
API連携 により15分ごとに位置情報を自動更新
RFC 1876 に基づくLOCレコードの仕様と活用例
DNSの意外な使い道と、実装のポイントを解説

DNS LOCレコードでISSの位置を公開する遊び

DNS LOCレコード は、サーバーやデバイスの 緯度・経度・標高 をDNSに記録できる仕組み
RFC 1876（実験的標準）により、 地球上から静止衛星軌道まで 幅広い高さをカバー
LOCレコード例：where-is-the-iss.dedyn.io. 1066 IN LOC 47 24 53.500 N 66 12 12.070 W 430520m 10000m 10000m 10000m
digコマンド でLOCレコードを取得可能（Linux/Macのみ対応）
15分ごと にISSの現在位置に更新、リアルタイム性を確保

位置情報の取得と変換

N2YO API を活用し、ISSの最新位置（緯度・経度・高度）を JSON形式 で取得
- 例："satlatitude": -21.25409321, "satlongitude": 140.3335763, "sataltitude": 420.09
LOCレコード形式へ変換時に必要な処理
- 緯度・経度 ：小数点表記から度分秒（DMS）形式へ変換
- 高度：キロメートルからメートルへ単位変換
LOCレコードの標高範囲： -100,000m～42,849,672m （地下施設から静止衛星まで対応）

DNSプロバイダとAPI操作

deSEC （ベルリンのチャリティ団体）をDNSプロバイダに選定、LOCレコードのAPI経由更新が可能
初回登録： POST でLOCレコード作成
更新時： PATCH で変更部分のみ送信、効率的なアップデート
TTL（Time To Live）は 900秒 に設定し、API制限内で自動更新

応用例・今後の展望

LOCレコード以外にも TXTレコード で更新時刻や追加情報を記録可能
DNSを使った 分散型データ配信 の可能性
- 静的・更新頻度が低いデータ配信に適する
Mars Roverの座標表現や、他の珍しいDNS活用例への発展性

参考リンク・補足情報

BIMI や SVG in DNS TXT など、他のDNSの変わった使い方についても紹介
Windows環境ではLOCレコードの標準的な参照方法がない点に注意
本記事はあくまで 技術デモ であり、正確な運用や宇宙船の誘導には利用不可

まとめ DNSは単なる名前解決だけでなく、 位置情報やメタデータの分散配信 にも利用可能。RFC 1876のLOCレコードを活用し、API連携と自動更新によって、ユニークなDNS活用事例を実現。今後もDNSの新たな可能性に注目。

Hackerたちの意見

すごい！これは賢いし、勉強にもなるね。すぐにJWSTでも似たようなことができるか考えたけど、残念ながらLOCのDNSレコードは約4200万メートル（42,000kmの高度）までしか対応してないんだ。JWSTはその38倍も遠くにあるから（約150万km）、LOCの高度フィールドで位置を表すのは無理だね。ハッブルならどうかな？

└

JWSTは第二ラグランジュ点を周回してるから、どうなるかはちょっと分からないな。月のGPS座標を求めるようなもんだよ。NASAは2023年にLROを使って月で弱いGPS信号を受信するテストをしたけど、ナビには役立たないと思う（まだ誰かが月で逆GPSをする方法を持ってるわけじゃないし、どうなるかは分からないけど）。ISSでこれが可能なのは、サブサテライトポイントのおかげなんだ。地球の表面からの高度に関係なくGPS信号を受信できるし、ISSは地球を周回してるからTLEも適用されるんだよ。TLEは地球軌道の衛星用に設計されていて、軌道要素を使って位置と速度を定義するんだ。

APIの制限は分かるけど、90分で地球を一周する物体に対して15分って多すぎない？平均して地球の周囲の約12分の1、つまりリスボンとイスタンブールの距離くらいずれることになるよ。

└

そうだね。投稿でも言ったけど、これをドッキング操作に使うべきじゃないよ。もし無料で1分ごとのDNS更新ができる方法を知ってたら、喜んで移行するよ。

RFCを見てみると、なぜこれが必要なのか説明されてないね。1996年当時に必要だった理由があるのかもしれないけど、大学やデータセンターの物流に関係してたのかな？

└

私の経験では、RFCは解決しようとしている問題について曖昧なことが多いね。これが「42 Wallaby Way, Sidney」みたいな人間が読める文字列にならない理由はないと思う。

└

RFCを見てみると、なぜこれが必要なのか説明されてないね。第5.1章（提案された使用法）には少なくともいくつかの曖昧な提案があるよ： > LOC RRのいくつかの使用法が提案されていて、 > USENETバックボーンのフローマップ、IPパケットの地理的経路を示す「ビジュアルトレースルート」アプリケーション、 > 管理されているホストやルーターの地図を生成するためにLOC RRを使用できるネットワーク管理アプリケーションなどがある。

APIを使わずにエフェメリスデータからリアルタイムで位置を計算できないかな？そうすれば、リクエストごとに現在の位置を返すことができるかもしれないね。

別のレコード、名前権限ポインタ（NAPTR）には、ヒューストンのジョンソン宇宙センターの電話番号が載ってるよ。 > dig where-is-the-iss.dedyn.io NAPTR ; > DiG 9.10.6 > where-is-the-iss.dedyn.io NAPTR ;; global options: +cmd ;; 答えが返ってきた: ;; ->>HEADER

「すぐに！(...) 15分ごとに」 - まじで

最初の文を「DNSエロティカが大好き」と読んじゃった。長いこと家にいるから、そろそろ散歩に行くべきかな。

└

これってそういうことじゃないの？冷たいシャワーも必要かも。

└

OnlyFansのクリエイターに登録させないで…！

└

いつもDNSっていう意味が全然変わるね。

└

驚くかもしれないけど、結構多くの人がこれを楽しむと思うよ。

DNS LOCレコードについてもっと知りたい方はこちら: https://www.ckdhr.com/dns-loc/>

これめっちゃクールだね！dns.toysに追加したばかりだよ。 [1] dig iss.sky +short @dns.toys [1] https://dns.toys

└

それすごいね！ありがとう :-) みんなTXTレコード使ってるの？それともLOCやNAPTRとか使ってるツールもあるのかな？

ハクソク