一個使用 DNS LOC 記錄追蹤國際太空站的創意專案引發了關於這種方法實際限制的討論。這項實驗性服務每 15 分鐘透過 DNS 查詢更新 ISS 位置，但社群回饋突顯了對於如此快速移動目標的重大準確性問題。
更新頻率造成重大準確性落差
社群識別出的最重要問題是 15 分鐘的更新間隔。由於 ISS 繞地球完成一次軌道運行大約需要 90 分鐘，15 分鐘的延遲約占其軌道路徑的十二分之一。這意味著報告的位置可能偏差大約 Lisbon 到 Istanbul 之間的距離——對於任何實際應用來說都是相當大的誤差。
創作者承認這項限制，並指出免費服務的 API 限制是主要約束條件。然而，幾位社群成員建議了替代方案，包括設置專用 DNS 伺服器或使用像 Cloudflare 這樣可能允許更頻繁更新的服務。
ISS 軌道特性：
- 軌道週期：約90分鐘
- 更新頻率：每15分鐘
- 精確度落差：約地球圓周的1/12
- 大約誤差距離： Lisbon 到 Istanbul
技術實作引發疑問
該專案使用實驗性的 RFC 1876 標準進行 DNS LOC 記錄，可以儲存緯度、經度和海拔資訊。雖然在技術上令人印象深刻，但一些使用者質疑這是否構成真正的 DNS 創新，或僅僅是一個碰巧使用 DNS 作為傳遞方法的 API。
該實作依賴 N2YO API 來獲取 ISS 位置資料，然後將十進位座標轉換為 LOC 記錄所需的度-分-秒格式。海拔也必須從公里轉換為公尺以符合 DNS 規範。
DNS LOC 記錄規範（ RFC 1876 ）：
- 最低海拔：-199,666 公尺
- 最高海拔：42,849,672 公尺（足以涵蓋地球同步衛星）
- 格式：座標採用度、分、秒格式
- TTL 設定：此實作中設為 999 秒
社群發現隱藏功能
除了主要的 LOC 記錄功能外，敏銳的使用者還發現了嵌入在服務中的額外 DNS 記錄。一位評論者發現了一個包含 NASA Johnson Space Center 在 Houston 電話號碼的 NAPTR 記錄，展示了 DNS 如何儲存除了簡單位置資訊之外的各種結構化資料類型。
「你會驚訝的，但我很確定許多人會深入研究這個。」
技術實作：
- 資料來源： N2YO API （ ISS 的衛星 ID 為 25544）
- DNS 提供商： deSEC （總部位於 Berlin 的慈善機構）
- 更新方法： HTTP PATCH 請求
- 座標轉換：需要將十進位轉換為 DMS 格式
太空應用的限制
討論也涉及將這個概念擴展到其他太空物體，如 James Webb Space Telescope 或 Hubble。然而，JWST 在距離地球約 150 萬公里的 L2 拉格朗日點運行——遠超過 DNS LOC 記錄支援的最大海拔約 42,000 公里。
該專案作為 DNS 能力的有趣概念驗證，但社群共識認為實際應用需要更頻繁的更新，並可能需要客製化 DNS 基礎設施才能為像 ISS 這樣快速移動的物體達到有意義的準確性。