DNSでISSの位置を確認する

(shkspr.mobi)

3 ポイント投稿者 GN⁺ 2025-07-07 | 1件のコメント | WhatsAppで共有

DNS LOCレコードを使って、国際宇宙ステーション（ISS） のリアルタイム位置情報を照会できる
LOCレコードは緯度・経度・高度の情報を保存し、衛星の位置追跡に適した機能を提供する
例のドメイン where-is-the-iss.dedyn.io にDNS問い合わせを行うと、ISSの最新位置が返される
N2YO API を活用して位置データを取得し、15分ごとにLOCレコードが自動更新される
deSECのような API対応ドメインサービス を通じて、LOC情報を効率的に更新できる

概要

DNSの esoterica（マニア向け機能）への興味をきっかけに、DNS LOCレコード を使って実際の物理的位置情報を世界中へ配布できる
一般に ドメイン名 はサーバーの物理的な場所と結び付けられるが、LOCレコードを使えばサーバーだけでなく珍しい機器の位置も記録できる

DNS LOCレコードとは？

RFC 1876で定義された 実験的標準 であり、サーバーの 緯度・経度・高度 情報をDNSに記録できる
最低高度は -100,000m（バンカーなど地下の位置も表現可能）、最高高度は 42,849,672m（静止軌道衛星などまで表現可能）
衛星をはじめとするさまざまな機器の位置情報をDNSで伝えられる機能を提供する

国際宇宙ステーション（ISS）の位置照会サービス実装

where-is-the-iss.dedyn.io ドメインを作成し、別個のWebサイト・ping・一般的なインタラクションなしで DNS問い合わせだけで動作 する
LinuxやMacでは、以下のコマンドでISSの位置情報を問い合わせできる
```
dig where-is-the-iss.dedyn.io LOC
```

返却例: 緯度・経度・高度の情報がLOC形式で提供される

where-is-the-iss.dedyn.io. 1066 IN  LOC 47 24 53.500 N 66 12 12.070 W 430520m 10000m 10000m 10000m

15分ごとに最新の位置情報へ更新 される（ベストエフォート方式）

位置データの取得と変換

N2YO のWebサイトとAPIを通じて、さまざまな軌道上の物体を追跡でき、無料ティアのAPIも提供されている
例のAPI呼び出しで、最新の衛星位置（緯度、経度、高度など）を JSON形式 で取得できる
```
https://api.n2yo.com/rest/v1/…=_____
```
返される緯度・経度は 小数点形式、高度はKm単位のため、LOCレコードへ変換する際には度分秒（DMS）およびメートル（m）単位への変換が必要

LOCレコード更新の自動化

deSEC（ベルリン拠点の非営利）では、APIでLOCレコードの初回作成と更新が可能

LOCの初回登録例

curl https://desec.io/api/v1/domains/where-is-the-iss.dedyn.io/rrsets/ ... --data '{"type": "LOC", "records": ["..."], "ttl": 900}'

更新ではHTTP PATCHを使い、変更された情報だけを送信する
TTL（900秒、15分） に設定し、コードが15分ごとに自動更新を行う
API利用量制限 を守りつつ、効率的に最新データを提供する
さらにTXTレコードなどを使って、更新時刻の記録などさまざまな拡張も可能

結論

今回の試みは、DNSのひと味違う活用可能性 を示す技術デモである
今後はMars Roverなど、さらに多様な宇宙オブジェクトの位置もDNS LOCレコードで表現できる可能性を示している
DNSを活用した斬新な応用例として、インフラ/IT業務の自動化、位置情報管理などへの拡張性もある

1件のコメント

GN⁺ 2025-07-07

Hacker Newsのコメント

もう1つのレコードである Name Authority Pointer (NAPTR) は、ヒューストンの Johnson Space Center の電話番号情報も提供している。

> dig where-is-the-iss.dedyn.io NAPTR

; <<>> DiG 9.10.6 <<>> where-is-the-iss.dedyn.io NAPTR
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31786
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;where-is-the-iss.dedyn.io. IN NAPTR

;; ANSWER SECTION:
where-is-the-iss.dedyn.io. 3600 IN NAPTR 100 100 "u" "E2U+voice:tel" "!^.*$!tel:+12814830123!" .

;; Query time: 84 msec
;; SERVER: 100.100.100.100#53(100.100.100.100)
;; WHEN: Sun Jul 06 10:53:39 EDT 2025
;; MSG SIZE rcvd: 111

API に制限があるのはわかるが、90分で地球を1周する物体に対して15分更新間隔はかなり大きいという意見。平均すると地球の外周の1/12ほど、リスボンからイスタンブールまでの距離に相当する誤差が出る可能性があるとの指摘。
- その通りだと思う。投稿にもドッキング作業には使わないでほしいと書いてあるし、1分ごとに無料で更新できる DNS があれば今すぐそちらに切り替えたい。
冒頭の文を "I love DNS erotica" と読み間違えた体験の共有。あまりに長く室内にいたのだと気づき、散歩が必要だと感じたという話。
- 驚くかもしれないが、こういう内容を面白いと感じる人はかなり多いはず。
- 実際、このプロジェクトこそが DNS エロティカなのではないかという冗談。冷たいシャワーが必要かもしれないという話。
- OnlyFans クリエイターにはなりたくないので勘弁してほしい。
- "It's always DNS" というミームに新しい意味が生まれるという冗談。
とてもクールなプロジェクトだと思い、すぐに dns.toys に追加したという報告。
```
dig iss.sky +short @dns.toys
```
- 本当に便利で面白い、ありがとう、すべてのツールが TXT レコードだけを使っているのか、それとも LOC や NAPTR も活用しているのか気になる。
本当に独創的で教育的なアイデアだという称賛。すぐに JWST にも同じ方法を適用できるか気になったが、残念ながら LOC DNS レコードは約4,200万メートル（42,000km）までしか対応しておらず、JWST はその38倍も遠いため位置表現に限界がある。Hubble なら可能性があるかもしれないとのこと。
- JWST は第2ラグランジュ点を公転しているため GPS 座標の指定は簡単ではない。月に GPS 座標を求めるのに近い状況。2023年に NASA は LRO を使って月で微弱な GPS 信号を受信するテストを行ったことがあるが、航法に実用的というほどではない。ISS はサブサテライトポイントだけでなく、地上高度に関係なく GPS 信号を受信できる。TLE（二行軌道要素）は ISS のような地球低軌道衛星に適用でき、SGP4 モデルなどで位置・速度を計算する。
- GSO（静止軌道衛星）の高度と LOC レコードの上限がほぼ一致しているという意見。
ハードコードされたキャッシュに加えて、DNS インフラ自体の TTL もキャッシュに役立つはずだという主張。特に Cloudflare 1.1.1.1 や Google 8.8.8.8 のような大規模パブリック DNS リゾルバが多いことを考えるとなおさらだという。DNS は世界規模で一貫して動作するデータベース的な性質を持ち、一時的なデータ保存が可能で、ファイアウォールにも比較的ブロックされにくい素朴なプロトコルだという利点がある。ただし、現実にはかなり横取りもされるという話。
OpenNotify という別のリソース（機能は限られていて派手さはない）の紹介。
http://open-notify.org/
DNS LOC レコードの詳細情報の紹介。
https://www.ckdhr.com/dns-loc/
RFC を見ても、なぜこの機能が必要だったのかの説明がない。1996年当時、大学やデータセンターの物流のような事情があったのだろうか、という疑問。
- RFC の 5.1 節（Suggested Uses）では曖昧ながらも利用可能性が示されている。たとえば USENET バックボーンのフロー地図、視覚的な traceroute アプリ（IP パケットの地理的移動経路の可視化）、ネットワーク管理アプリでのホスト・ルーターマップ生成などが考えられる。
- RFC では解決すべき問題が明確に定義されていないことが多い。LOC レコードも、厳密な座標ではなく人間が読める住所文字列で十分だったのではないかという考え。
DNS は、連合型で、読み取り最適化され、地理分散複製されたキーバリューストアであり、eventual consistency を持つ、というまとめ。