Memeriksa Lokasi ISS lewat DNS

 (shkspr.mobi)
3 poin oleh GN⁺ 2025-07-07 | 1 komentar | Bagikan ke WhatsApp
  • where-is-the-iss.dedyn.io adalah eksperimen iseng yang mengembalikan perkiraan lokasi Stasiun Luar Angkasa Internasional (ISS) hanya melalui record DNS LOC, bukan sebuah situs web
  • DNS LOC adalah standar eksperimental dalam RFC 1876, yang dapat memuat tidak hanya lintang dan bujur, tetapi juga ketinggian dalam record domain
  • Rentang ketinggian record LOC adalah dari -100.000 m hingga 42.849.672 m, sehingga dapat merepresentasikan apa pun dari fasilitas bawah tanah hingga satelit geostasioner
  • Koordinat ISS diambil dari API N2YO; agar sesuai dengan format LOC, ketinggian harus dikonversi dari km ke m, sementara lintang dan bujur harus dikonversi ke format derajat-menit-detik
  • Record diperbarui melalui API deSEC dan TTL disetel ke 900 detik, sehingga lokasi terbaru direfleksikan setiap 15 menit secara best-effort

Memuat Lokasi dalam Record DNS LOC

  • Nama domain biasanya menunjuk ke server, tetapi server pada akhirnya tetap merupakan perangkat yang memiliki lokasi fisik di dalam pusat data
  • Record DNS LOC adalah record DNS yang dapat memuat lintang, bujur, dan ketinggian pada domain
  • RFC 1876 adalah standar eksperimental yang mendefinisikan record LOC
    • Karena pusat data bisa berada di gedung bertingkat atau di bawah tanah, parameter ketinggian juga disertakan
    • Ketinggian minimum adalah -100.000 m
    • Ketinggian maksimum adalah 42.849.672 m, rentang yang juga dapat digunakan untuk satelit geostasioner

where-is-the-iss.dedyn.io

  • where-is-the-iss.dedyn.io adalah domain yang dibuat untuk mendapatkan perkiraan lokasi ISS melalui kueri DNS
  • Domain ini bukan situs web, tidak bisa di-ping, dan tidak memiliki cara interaksi selain DNS
  • Pengguna Linux dan Mac dapat melihat record LOC dengan perintah berikut
dig where-is-the-iss.dedyn.io LOC
  • Responsnya mengembalikan lintang, bujur, dan ketinggian ISS dalam format 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
  • Record DNS diperbarui setiap 15 menit secara best-effort
  • Di PowerShell atau Command Prompt Windows, tampaknya sulit menemukan cara untuk melakukan kueri record LOC

Mengambil Data Lokasi

  • N2YO menyediakan situs web untuk melacak berbagai objek di orbit dan API dengan free tier yang cukup longgar
  • ISS dikueri dari API N2YO dengan ID satelit 25544
  • Respons API berisi field seperti satlatitude, satlongitude, sataltitude, timestamp, dan 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
        }
    ]
}
  • Ketinggian dalam respons N2YO menggunakan satuan km, sementara format LOC membutuhkan satuan m
  • Karena lintang dan bujur diberikan sebagai desimal, keduanya harus diubah ke format derajat-menit-detik (Degrees, Minutes, Seconds) agar bisa dimasukkan ke record LOC

Memperbarui Record LOC dengan deSEC

  • Tidak banyak penyedia nama domain gratis yang menyediakan API pembaruan record LOC, jadi dipilih deSEC, sebuah organisasi amal di Berlin
  • deSEC menyediakan dokumentasi API
  • Record LOC awal ditambahkan ke endpoint rrsets dengan 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}'
  • Pembaruan record sedikit lebih rumit; HTTP PATCH harus dikirim ke URL lain
  • Permintaan PATCH cukup memuat data yang berubah saja
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"]}'

Siklus Pembaruan dan Batasan

  • TTL disetel ke 900 detik
  • Kode dijalankan setiap 15 menit untuk memperbarui record DNS
  • Siklus ini membuatnya tetap berada dalam batas API N2YO maupun deSEC
  • Bisa saja memasukkan waktu pembaruan terakhir atau data tidak terstruktur lainnya melalui record TXT, tetapi untuk demo ini, proof of concept cepat dianggap sudah cukup
  • Menyebarkan data lewat record DNS TXT juga bisa dipakai layaknya API yang praktis tanpa batas permintaan, dan lebih cocok untuk data statis atau yang tidak sering berubah

Data Tidak Biasa yang Bisa Dimuat di DNS

  • Demo ini adalah cara yang rumit dan iseng untuk menunjukkan bahwa DNS juga dapat memuat record yang tidak terduga
  • Seperti koordinat ISS yang direpresentasikan dengan record LOC, menarik juga membayangkan bagaimana koordinat Mars Rover dapat direpresentasikan
  • Tulisan terkait DNS lainnya adalah BIMI - SVG in DNS TXT WTF?! dan Why you can't dig Switzerland

Bacaan terkait

1 komentar

 
GN⁺ 2025-07-07
Komentar Hacker News

  • Rekor lain, yaitu Name Authority Pointer (NAPTR), berisi nomor telepon Johnson Space Center di Houston
    Jika dilihat dengan dig where-is-the-iss.dedyn.io NAPTR, akan muncul E2U+voice:tel dan tel:+12814830123

  • Pembatasan API bisa dimengerti, tetapi interval pembaruan 15 menit terasa cukup lama untuk objek yang mengelilingi Bumi setiap 90 menit
    Rata-rata posisinya bisa meleset sekitar 1/12 keliling Bumi, kira-kira sejauh jarak antara Lisbon dan Istanbul

    • Benar. Seperti yang disebutkan di tulisan, ini tidak boleh dipakai untuk operasi docking
      Kalau ada cara pembaruan DNS gratis yang mengizinkan refresh per menit, saya dengan senang hati akan pindah
    • Kecepatan orbit ISS sekitar 7,66 km/s, jadi dalam 15 menit menempuh sekitar 6.900 km
      Jelas itu galat yang besar untuk pelacakan posisi presisi

  • Saya sempat membaca kalimat pertama sebagai “I love DNS erotica”, dan itu mungkin pertanda saya sudah terlalu lama di dalam ruangan dan perlu jalan-jalan

    • Mungkin mengejutkan, tapi sepertinya cukup banyak orang yang bakal tertarik mendalami hal seperti ini
    • Saya juga membacanya seperti itu pada awalnya, jadi syukurlah saya bukan satu-satunya orang aneh
      Sekarang saya akan pergi jalan-jalan
    • Saya juga sempat mengira itu yang dimaksud
      Sepertinya perlu mandi air dingin juga
    • Ungkapan “selalu masalah DNS” jadi punya makna yang benar-benar baru

  • Keren sekali. Baru saja saya tambahkan juga ke dns.toys
    dig iss.sky +short @dns.toys
    [1] https://dns.toys

    • Benar-benar rapi. Saya jadi penasaran apakah semua alatnya memakai record TXT, atau juga memakai LOC, NAPTR, dan sejenisnya
    • Ada bug di bagian cuaca. Bratislava tidak mungkin bersuhu di bawah nol Celsius pada puncak musim panas, dan Tallinn juga meleset sekitar 17°C

  • Luar biasa. Cerdik sekaligus edukatif. Saya langsung penasaran apakah hal serupa bisa dibuat untuk JWST
    Sayangnya record DNS LOC punya batas sekitar 42 juta meter, yaitu ketinggian sekitar 42.000 km, sedangkan JWST berada sekitar 1,5 juta km, atau 38 kali lebih jauh dari itu
    Jadi posisinya tidak bisa direpresentasikan dengan field ketinggian LOC. Untuk Hubble mungkin bisa

    • JWST mengorbit titik Lagrange kedua, jadi saya tidak yakin bagaimana itu akan bekerja
      Ini mirip seperti menanyakan koordinat GPS Bulan. NASA memang menguji penerimaan sinyal GPS lemah di Bulan dengan LRO pada 2023, tetapi itu masih belum berguna untuk navigasi
      Alasan pendekatan ini cocok untuk ISS adalah karena ada titik sub-satelit di atas permukaan Bumi. Terlepas dari ketinggiannya, koordinat GPS bisa diperoleh
      Selain itu, TLE berlaku untuk ISS sebagai objek di orbit Bumi. TLE mendefinisikan posisi dan kecepatan satelit orbit Bumi sebagai elemen orbit, dan dirancang agar bisa diinterpretasikan oleh model seperti SGP4
    • Mungkin karena orbit geostasioner (GSO) memang berada di sekitar ketinggian itu

  • “RFC 1876 adalah standar eksperimental” — eksperimen yang benar-benar bertahan lama
    University of Warwick, January 1996
    [1] https://datatracker.ietf.org/doc/html/rfc1876

  • Bacaan tambahan tentang record DNS LOC: <https://www.ckdhr.com/dns-loc/>

  • Cara yang sedikit lebih rumit tetapi jauh lebih responsif adalah dengan mengarahkan record NS where-is-the-iss.shkspr.mobi ke IP VPS milik sendiri
    Lalu jalankan program yang mendengarkan di UDP/53 dan TCP/53, lalu membalas dengan paket DNS yang hanya mengubah record LOC dan ID pesan secara dinamis
    Ini mungkin tidak sepenuhnya mengikuti spesifikasi DNS, tetapi untuk keperluan ini sudah cukup. Respons API bisa di-cache untuk menghindari batas pemanggilan

    • Intinya adalah tidak ingin menjalankan server sendiri. Sebagai gantinya, saya bisa menyalahgunakan sistem yang tersebar di seluruh dunia
    • Cara itu sepenuhnya sesuai dengan spesifikasi DNS
      Saya sendiri menjalankan layanan seperti itu, dan bisa diuji dengan 2+2.op.dyn.bortzmeyer.fr/TXT atau paris.now.weather.dyn.bortzmeyer.fr/TXT

  • DNS adalah penyimpanan key-value yang terfederasi, dioptimalkan untuk pembacaan, direplikasi secara geografis, dan memiliki konsistensi eventual

  • Bahkan setelah membaca RFC-nya, tetap tidak dijelaskan mengapa ini diperlukan
    Saya jadi bertanya-tanya apakah pada 1996 ada alasan yang berkaitan dengan logistik kampus atau pusat data

    • Bagian 5.1 “Suggested Uses” setidaknya memberi contoh penggunaan yang samar
      Disebutkan bahwa LOC RR bisa dipakai untuk peta aliran backbone USENET, “traceroute visual” yang menunjukkan rute geografis paket IP, dan aplikasi manajemen jaringan yang membuat peta host dan router yang dikelola
    • Dari pengalaman saya, RFC biasanya menjelaskan masalah yang ingin mereka pecahkan dengan agak samar
      Tidak ada alasan kenapa ini tidak bisa saja berupa string yang bisa dibaca manusia seperti “42 Wallaby Way, Sidney”