Memeriksa lokasi ISS lewat DNS

 (shkspr.mobi)
3 poin oleh GN⁺ 2025-07-07 | 1 komentar | Bagikan ke WhatsApp
  • Menggunakan record DNS LOC untuk meminta informasi posisi real-time Stasiun Luar Angkasa Internasional (ISS)
  • Record LOC menyimpan informasi lintang, bujur, dan ketinggian, serta menyediakan fungsi yang cocok untuk pelacakan posisi satelit
  • Saat melakukan kueri DNS ke domain contoh (where-is-the-iss.dedyn.io), sistem mengembalikan posisi terbaru ISS
  • Memanfaatkan N2YO API untuk mengambil data posisi, dan record LOC diperbarui otomatis setiap 15 menit
  • Melalui layanan domain yang mendukung API seperti deSEC, pembaruan informasi LOC dapat dilakukan secara efisien

Gambaran umum

  • Berangkat dari ketertarikan pada esoterica DNS (fitur untuk kalangan penggemar), record DNS LOC dapat dipakai untuk mendistribusikan informasi lokasi fisik nyata ke seluruh dunia
  • Secara umum, nama domain terhubung dengan lokasi fisik server, dan melalui record LOC, bukan hanya server tetapi juga lokasi perangkat yang tidak biasa dapat dicatat

Apa itu record DNS LOC?

  • Sebagai standar eksperimental yang didefinisikan dalam RFC 1876, DNS dapat menyimpan informasi lintang, bujur, dan ketinggian server
  • Ketinggian minimum -100.000 m (dapat merepresentasikan lokasi bawah tanah seperti bunker), maksimum 42.849.672 m (dapat merepresentasikan hingga satelit orbit geostasioner)
  • Menyediakan kemampuan untuk menyampaikan informasi lokasi berbagai perangkat, termasuk satelit, lewat DNS

Membangun layanan pencarian posisi Stasiun Luar Angkasa Internasional (ISS)

  • Membuat domain where-is-the-iss.dedyn.io, yang bekerja hanya melalui kueri DNS tanpa situs web terpisah, ping, atau interaksi umum lainnya

  • Di Linux dan Mac, informasi posisi ISS dapat diminta dengan perintah berikut

    dig where-is-the-iss.dedyn.io LOC

  • Contoh hasil: informasi lintang/bujur/ketinggian diberikan dalam format LOC

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

  • Diperbarui dengan informasi posisi terbaru setiap 15 menit (dengan pendekatan best-effort)

Mengambil dan mengonversi data posisi

  • Melalui situs web dan API N2YO, berbagai objek di orbit dapat dilacak, dan tersedia API tingkat gratis

  • Dengan contoh pemanggilan API, posisi satelit terbaru (lintang, bujur, ketinggian, dll.) dapat diperoleh dalam format JSON

    https://api.n2yo.com/rest/v1/…=_____

  • Lintang/bujur yang dikembalikan berbentuk desimal, sedangkan ketinggian dalam Km → saat dikonversi ke record LOC perlu diubah ke format derajat-menit-detik (DMS) dan meter (m)

Otomatisasi pembaruan record LOC

  • Dengan API deSEC (nirlaba yang berbasis di Berlin), record LOC dapat dibuat pertama kali dan diperbarui
  • Contoh pendaftaran awal LOC 
    curl https://desec.io/api/v1/domains/where-is-the-iss.dedyn.io/rrsets/ ... --data '{"type": "LOC", "records": ["..."], "ttl": 900}'
  • Pembaruan menggunakan HTTP PATCH untuk mengirim hanya informasi yang berubah
  • Ditetapkan dengan TTL (900 detik, 15 menit), sehingga kode melakukan pembaruan otomatis setiap 15 menit
  • Menyediakan data terbaru secara efisien sambil mematuhi batas penggunaan API
  • Selain itu, berbagai perluasan juga dimungkinkan, seperti mencatat waktu pembaruan melalui record TXT dan sebagainya

Kesimpulan

  • Percobaan kali ini merupakan demonstrasi teknis yang menunjukkan kemungkinan pemanfaatan DNS yang tidak biasa
  • Ke depan, ini membuka kemungkinan untuk merepresentasikan posisi objek antariksa lain seperti Mars Rover melalui record DNS LOC
  • Sebagai contoh aplikasi baru yang kreatif dengan memanfaatkan DNS, ini juga menawarkan potensi perluasan ke otomatisasi pekerjaan infrastruktur/IT, pengelolaan informasi lokasi, dan lainnya

Bacaan terkait

1 komentar

 
GN⁺ 2025-07-07
Komentar Hacker News
  • Rekor lain, Name Authority Pointer (NAPTR), menyediakan informasi nomor telepon Johnson Space Center di Houston 
    > 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
  • Paham bahwa ada batasan API, tetapi interval pembaruan 15 menit terasa cukup besar untuk objek yang mengelilingi seluruh Bumi dalam 90 menit; rata-rata bisa menimbulkan galat sekitar 1/12 keliling Bumi, kira-kira sejauh jarak antara Lisboa dan Istanbul
    • Rasanya itu masuk akal; di postingannya juga disebutkan agar ini tidak digunakan untuk operasi docking, dan kalau ada DNS gratis yang bisa diperbarui tiap 1 menit, saya akan langsung beralih ke sana
  • Ada yang berbagi pengalaman salah membaca kalimat pembuka sebagai "I love DNS erotica", lalu sadar mungkin dirinya sudah terlalu lama di dalam ruangan dan perlu jalan-jalan
    • Mungkin mengejutkan, tapi saya yakin banyak orang akan menganggap hal seperti ini menarik
    • Bercanda bahwa proyek ini sendiri bukankah justru DNS erotica itu
    • Mungkin perlu mandi air dingin
    • Tolong tahan diri, saya tidak ingin berkarier sebagai kreator OnlyFans
    • Lelucon bahwa meme "It's always DNS" kini punya makna baru
  • Menganggap ini proyek yang sangat keren, dan langsung menambahkannya ke dns.toys 
    dig iss.sky +short @dns.toys
    • Benar-benar praktis dan menakjubkan, terima kasih; penasaran apakah semua alat hanya memakai rekor TXT, atau juga memanfaatkan LOC dan NAPTR
  • Pujian bahwa ini ide yang sangat cerdik dan edukatif; langsung muncul pertanyaan apakah pendekatan serupa bisa diterapkan ke JWST. Sayangnya, rekor DNS LOC hanya mendukung hingga sekitar 42 juta meter (42.000 km), sedangkan JWST 38 kali lebih jauh, jadi ada batasan dalam merepresentasikan posisinya; untuk Hubble mungkin masih ada kemungkinan
    • Karena JWST mengorbit titik Lagrange kedua, koordinat GPS tidak mudah ditentukan; situasinya mirip meminta koordinat GPS di Bulan. Pada 2023 NASA pernah menguji penerimaan sinyal GPS yang lemah di Bulan dengan LRO, tetapi itu tidak praktis untuk navigasi. ISS, selain sub-satellite point, juga bisa menerima sinyal GPS tanpa bergantung pada ketinggian dari permukaan. TLE (two-line element) dapat diterapkan pada satelit yang mengorbit Bumi rendah seperti ISS, dengan model seperti SGP4 untuk menghitung posisi dan kecepatan
    • Ada pendapat bahwa ketinggian GSO (satelit geostasioner) hampir persis cocok dengan batas rekor LOC
  • Ada argumen bahwa selain cache yang di-hardcode, nilai TTL dari infrastruktur DNS itu sendiri seharusnya membantu caching, terutama karena ada banyak resolver DNS publik besar seperti Cloudflare 1.1.1.1 dan Google 8.8.8.8. DNS dipandang sebagai basis data global yang beroperasi konsisten, bisa menyimpan data sementara, dan sebagai protokol sederhana yang sulit diblokir firewall, meski kenyataannya juga sering dicegat
  • Memperkenalkan sumber lain bernama OpenNotify (fiturnya terbatas dan tidak terlalu mewah) http://open-notify.org/
  • Memperkenalkan informasi terperinci tentang rekor DNS LOC https://www.ckdhr.com/dns-loc/
  • Setelah melihat RFC, ada pertanyaan mengapa fitur ini diperlukan, karena tidak ada penjelasan; mungkinkah pada 1996 ada alasan terkait logistik kampus atau pusat data
    • Bagian 5.1 RFC (Suggested Uses) memang memberi gambaran kemungkinan penerapan, walau agak samar, misalnya peta aliran backbone USENET, aplikasi traceroute visual (memvisualisasikan jalur perpindahan geografis paket IP), dan pembuatan peta host/router di aplikasi manajemen jaringan
    • RFC sering kali tidak mendefinisikan masalah yang hendak diselesaikan secara jelas; untuk rekor LOC, rasanya bukan koordinat pun tidak masalah, string alamat yang dapat dibaca manusia saja sudah cukup
  • Ringkasnya, DNS adalah penyimpanan key-value yang terfederasi, dioptimalkan untuk pembacaan, direplikasi secara geografis, dan memiliki eventual consistency