ตรวจสอบตำแหน่งของ ISS ผ่าน DNS

 (shkspr.mobi)
3 คะแนน โดย GN⁺ 2025-07-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สามารถใช้ DNS LOC record เพื่อค้นหาข้อมูลตำแหน่งแบบเรียลไทม์ของ สถานีอวกาศนานาชาติ (ISS) ได้
  • LOC record เก็บข้อมูลละติจูด ลองจิจูด และความสูง จึงเหมาะสำหรับการติดตามตำแหน่งของดาวเทียม
  • เมื่อส่ง DNS query ไปยังโดเมนตัวอย่าง (where-is-the-iss.dedyn.io) ระบบจะส่งกลับ ตำแหน่งล่าสุดของ ISS
  • ใช้ N2YO API เพื่อดึงข้อมูลตำแหน่ง และมีการอัปเดต LOC record อัตโนมัติทุก 15 นาที
  • สามารถอัปเดตข้อมูล LOC ได้อย่างมีประสิทธิภาพผ่าน บริการโดเมนที่รองรับ API เช่น deSEC

ภาพรวม

  • จากความสนใจในลูกเล่นเฉพาะทางของ DNS จึงพบว่าสามารถใช้ DNS LOC record เพื่อเผยแพร่ข้อมูลตำแหน่งทางกายภาพจริงไปยังทั่วโลกได้
  • โดยทั่วไป ชื่อโดเมน มักเชื่อมโยงกับตำแหน่งทางกายภาพของเซิร์ฟเวอร์ และผ่าน LOC record ก็สามารถบันทึกตำแหน่งได้ไม่เฉพาะเซิร์ฟเวอร์ แต่รวมถึงอุปกรณ์ที่แปลกออกไปด้วย

DNS LOC record คืออะไร?

  • เป็น มาตรฐานเชิงทดลอง ที่กำหนดไว้ใน RFC 1876 ซึ่งทำให้สามารถบันทึกข้อมูล ละติจูด ลองจิจูด และความสูง ของเซิร์ฟเวอร์ไว้ใน DNS ได้
  • รองรับความสูงต่ำสุด -100,000m (ใช้แสดงตำแหน่งใต้ดิน เช่น บังเกอร์) และสูงสุด 42,849,672m (ใช้แสดงได้ถึงดาวเทียมวงโคจรค้างฟ้า เป็นต้น)
  • เป็นความสามารถที่ทำให้ส่งต่อข้อมูลตำแหน่งของอุปกรณ์หลากหลายชนิดรวมถึงดาวเทียมผ่าน DNS ได้

การสร้างบริการค้นหาตำแหน่งของสถานีอวกาศนานาชาติ (ISS)

  • สร้างโดเมน where-is-the-iss.dedyn.io โดยไม่มีเว็บไซต์แยก ไม่มี ping และไม่มีการโต้ตอบทั่วไปใด ๆ แต่ ทำงานผ่าน DNS query เท่านั้น

  • บน 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 นาที (แบบ best-effort)

การดึงและแปลงข้อมูลตำแหน่ง

  • ผ่านเว็บไซต์และ API ของ N2YO สามารถติดตามวัตถุต่าง ๆ ในวงโคจรได้ และมี API ระดับฟรีให้ใช้งาน

  • สามารถใช้ตัวอย่างการเรียก API เพื่อดึงตำแหน่งล่าสุดของดาวเทียม (ละติจูด ลองจิจูด ความสูง ฯลฯ) ในรูปแบบ JSON ได้

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

  • ละติจูด/ลองจิจูดที่ส่งกลับมาอยู่ใน รูปแบบทศนิยม ส่วนความสูงเป็นหน่วยกิโลเมตร จึงต้องแปลงเป็นหน่วยองศา-ลิปดา-พิลิปดา (DMS) และเมตร (m) เมื่อนำไปใช้กับ LOC record

การทำให้การอัปเดต LOC record เป็นอัตโนมัติ

  • deSEC (องค์กรไม่แสวงกำไรในเบอร์ลิน) รองรับการสร้างและอัปเดต LOC record ครั้งแรกผ่าน API
  • ตัวอย่างการลงทะเบียน 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 record เพื่อบันทึกเวลาอัปเดต

บทสรุป

  • ความพยายามครั้งนี้เป็นการสาธิตเชิงเทคนิคที่แสดงให้เห็นถึง ความเป็นไปได้ในการใช้งาน DNS ในรูปแบบที่แปลกใหม่
  • ในอนาคตยังชี้ให้เห็นความเป็นไปได้ที่จะใช้ DNS LOC record เพื่อแสดงตำแหน่งของวัตถุอวกาศอื่น ๆ ที่หลากหลายยิ่งขึ้น เช่น Mars Rover
  • เป็นตัวอย่างการประยุกต์ใช้ DNS อย่างสร้างสรรค์ที่สามารถต่อยอดไปสู่การทำงานอัตโนมัติในงานโครงสร้างพื้นฐาน/IT การจัดการข้อมูลตำแหน่ง และด้านอื่น ๆ ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-07-07
ความคิดเห็นบน Hacker News
  • เรคคอร์ดอีกประเภทหนึ่งคือ 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 แต่ช่วงอัปเดตทุก 15 นาทีถือว่าค่อนข้างห่างสำหรับวัตถุที่โคจรรอบโลกครบหนึ่งรอบใน 90 นาที โดยเฉลี่ยแล้วอาจคลาดเคลื่อนได้ราว 1/12 ของเส้นรอบวงโลก หรือประมาณระยะทางจากลิสบอนไปอิสตันบูล
    • เห็นด้วยว่าเป็นประเด็นที่ถูกต้อง และในโพสต์ก็มีบอกไว้ด้วยว่าไม่ควรนำไปใช้กับงาน docking ถ้ามี DNS ที่อัปเดตได้ฟรีทุก 1 นาที ก็พร้อมจะย้ายไปใช้อันนั้นทันที
  • มีคนเล่าว่าอ่านประโยคเปิดผิดเป็น "I love DNS erotica" เลยรู้สึกว่าตัวเองน่าจะอยู่แต่ในบ้านนานเกินไป และควรออกไปเดินเล่นบ้าง
    • อาจจะน่าแปลกใจ แต่ก็มั่นใจว่าคนจำนวนมากน่าจะรู้สึกว่าสิ่งนี้น่าสนใจ
    • มีมุกว่าโปรเจ็กต์นี้ก็คือ DNS erotica นั่นเอง อาจถึงขั้นต้องไปอาบน้ำเย็น
    • ขอให้ยั้งไว้หน่อย เพราะไม่อยากผันตัวไปเป็นครีเอเตอร์บน OnlyFans
    • มีม "It's always DNS" ก็เลยได้ความหมายใหม่ขึ้นมา
  • คิดว่าเป็นโปรเจ็กต์ที่เท่มาก เลยเพิ่มเข้า dns.toys ทันที 
    dig iss.sky +short @dns.toys
    • ทั้งสะดวกและน่าทึ่งมาก ขอบคุณมาก และสงสัยว่าเครื่องมือทั้งหมดใช้แค่ TXT record หรือใช้ LOC, NAPTR ด้วย
  • ได้รับคำชมว่าเป็นไอเดียที่ทั้งฉลาดและให้ความรู้ และมีคนสงสัยต่อทันทีว่าวิธีคล้ายกันนี้จะใช้กับ JWST ได้ไหม น่าเสียดายที่ DNS LOC record รองรับได้ถึงราว 42,000,000 เมตร (42,000km) ขณะที่ JWST อยู่ไกลกว่านั้น 38 เท่า จึงมีข้อจำกัดในการแสดงตำแหน่ง ส่วน Hubble อาจยังพอเป็นไปได้
    • JWST โคจรรอบจุดลากร็องจ์ที่ 2 จึงไม่ง่ายที่จะระบุตำแหน่งด้วยพิกัด GPS คล้ายกับการขอพิกัด GPS บนดวงจันทร์ ในปี 2023 NASA เคยทดสอบรับสัญญาณ GPS ที่อ่อนมากบนดวงจันทร์ด้วย LRO แต่ยังไม่ใช่วิธีที่ใช้งานได้จริงสำหรับการนำทาง ส่วน ISS นั้นนอกจาก sub-satellite point แล้ว ก็ยังรับสัญญาณ GPS ได้โดยไม่ขึ้นกับความสูงจากพื้นโลก และ TLE (two-line element) ก็ใช้ได้กับดาวเทียมวงโคจรต่ำรอบโลกอย่าง ISS เพื่อนำไปคำนวณตำแหน่งและความเร็วด้วยโมเดลอย่าง SGP4
    • มีความเห็นว่าความสูงของ GSO (ดาวเทียมค้างฟ้า) แทบจะตรงกับขีดจำกัดของ LOC record พอดี
  • มีข้อเสนอว่านอกจากแคชที่ฮาร์ดโค้ดไว้แล้ว ค่า TTL ของโครงสร้างพื้นฐาน DNS เองก็ควรช่วยเรื่องการแคชได้ด้วย โดยเฉพาะเมื่อมี public DNS resolver รายใหญ่อย่าง Cloudflare 1.1.1.1 และ Google 8.8.8.8 อยู่มากมาย DNS มีลักษณะเป็นฐานข้อมูลที่ทำงานสอดคล้องกันทั่วโลก ใช้เก็บข้อมูลชั่วคราวได้ และเป็นโปรโตคอลเรียบง่ายที่ไฟร์วอลล์บล็อกได้ยาก แม้ในความเป็นจริงจะถูกดักจับอยู่บ่อยก็ตาม
  • มีการแนะนำทรัพยากรอีกตัวชื่อ OpenNotify (ความสามารถจำกัดกว่าและไม่หวือหวาเท่า)
    http://open-notify.org/
  • มีการแชร์ข้อมูลเชิงลึกเกี่ยวกับ DNS LOC record
    https://www.ckdhr.com/dns-loc/
  • มีคนบอกว่าอ่าน RFC แล้วก็ยังไม่เห็นคำอธิบายว่าทำไมถึงต้องมีฟีเจอร์นี้ เลยสงสัยว่าในปี 1996 อาจมีเหตุผลเกี่ยวกับมหาวิทยาลัยหรือโลจิสติกส์ของดาต้าเซ็นเตอร์หรือไม่
    • ใน RFC หมวด 5.1 (Suggested Uses) มีการยกตัวอย่างการใช้งานไว้อย่างกว้าง ๆ เช่น แผนที่การไหลของ USENET backbone, แอป traceroute แบบแสดงภาพเส้นทางการเคลื่อนที่เชิงภูมิศาสตร์ของแพ็กเก็ต IP, หรือแอปบริหารเครือข่ายที่สร้างแผนที่ของโฮสต์และเราเตอร์
    • หลายครั้ง RFC ก็ไม่ได้นิยามปัญหาที่ต้องการแก้อย่างชัดเจน และมีความเห็นว่า LOC record ไม่จำเป็นต้องใช้พิกัดก็ได้ แค่เป็นสตริงที่อยู่แบบมนุษย์อ่านออกก็น่าจะเพียงพอ
  • มีการสรุปว่า DNS คือคีย์-แวลูสโตร์แบบกระจายศูนย์ อ่านเป็นหลัก ทำซ้ำข้ามภูมิภาค และมีลักษณะ eventual consistency