ตรวจสอบตำแหน่งของ ISS ด้วย DNS

 (shkspr.mobi)
3 คะแนน โดย GN⁺ 2025-07-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • where-is-the-iss.dedyn.io ไม่ใช่เว็บไซต์ แต่เป็นการทดลองขำ ๆ ที่ส่งคืนตำแหน่งโดยประมาณของสถานีอวกาศนานาชาติ (ISS) โดยใช้เพียง DNS LOC record
  • DNS LOC เป็น มาตรฐานเชิงทดลอง ตาม RFC 1876 ที่สามารถเก็บทั้งละติจูด ลองจิจูด และระดับความสูงไว้ในเรคอร์ดของโดเมนได้
  • ช่วงระดับความสูงของ LOC record คือ -100,000m ถึง 42,849,672m จึงใช้แทนได้ตั้งแต่สิ่งอำนวยความสะดวกใต้ดินไปจนถึงดาวเทียมวงโคจรค้างฟ้า
  • พิกัดของ ISS ดึงมาจาก N2YO API และเพื่อให้เข้ากับรูปแบบ LOC ต้องแปลงระดับความสูงจาก km เป็น m และแปลงละติจูด/ลองจิจูดเป็น รูปแบบองศา-ลิปดา-พิลิปดา
  • อัปเดตเรคอร์ดผ่าน deSEC API และตั้ง TTL เป็น 900 วินาที เพื่อสะท้อนตำแหน่งล่าสุดทุก 15 นาทีแบบ best-effort

บันทึกตำแหน่งด้วย DNS LOC record

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

where-is-the-iss.dedyn.io

  • where-is-the-iss.dedyn.io เป็นโดเมนที่สร้างขึ้นเพื่อให้ได้ตำแหน่งโดยประมาณของ ISS ผ่าน การ query DNS
  • โดเมนนี้ ไม่ใช่เว็บไซต์ จะ ping ก็ไม่ได้ และไม่มีวิธีโต้ตอบอื่นนอกจาก DNS
  • ผู้ใช้ Linux และ Mac สามารถดู LOC record ได้ด้วยคำสั่งต่อไปนี้
dig where-is-the-iss.dedyn.io LOC
  • คำตอบจะส่งกลับละติจูด ลองจิจูด และระดับความสูงของ ISS ในรูปแบบ 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
  • DNS record จะถูกอัปเดตแบบ best-effort ทุก 15 นาที
  • สำหรับ Windows PowerShell หรือ Command Prompt ดูเหมือนจะหา方法สำหรับ query LOC record ได้ยาก

ดึงข้อมูลตำแหน่ง

  • N2YO เป็นเว็บไซต์ที่ใช้ติดตามวัตถุต่าง ๆ ในวงโคจร และมี API ที่มี free tier ค่อนข้างใจกว้าง
  • ISS ถูกเรียกดูใน N2YO API ด้วยรหัสดาวเทียม 25544
  • การตอบกลับจาก API มีฟิลด์อย่าง satlatitude, satlongitude, sataltitude, timestamp, 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
        }
    ]
}
  • ระดับความสูงในคำตอบของ N2YO ใช้หน่วยเป็น km แต่รูปแบบ LOC ต้องใช้หน่วย m
  • ละติจูดและลองจิจูดมาในรูปแบบเลขทศนิยม จึงต้องแปลงเป็น องศา-ลิปดา-พิลิปดา (Degrees, Minutes, Seconds) ก่อนใส่ใน LOC record

อัปเดต LOC record ด้วย deSEC

  • ผู้ให้บริการชื่อโดเมนฟรีที่มี API สำหรับอัปเดต LOC record มีไม่มากนัก จึงเลือก deSEC ซึ่งเป็นองค์กรการกุศลจากเบอร์ลิน
  • deSEC มี เอกสาร API
  • LOC record เริ่มต้นถูกเพิ่มเข้าไปด้วย curl ที่ endpoint rrsets
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}'
  • การรีเฟรชเรคอร์ดซับซ้อนขึ้นอีกนิด โดยต้องส่ง HTTP PATCH ไปยัง URL อีกตัวหนึ่ง
  • ในคำขอ PATCH ใส่เฉพาะ ข้อมูลที่เปลี่ยนไป ก็พอ
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"]}'

รอบการอัปเดตและข้อจำกัด

  • ตั้งค่า TTL เป็น 900 วินาที
  • โค้ดจะรันทุก 15 นาทีเพื่ออัปเดต DNS record
  • ช่วงเวลานี้ช่วยให้อยู่ภายใน ข้อจำกัดของ API ทั้งฝั่ง N2YO และ deSEC
  • จะใช้ TXT record เพื่อใส่เวลาที่อัปเดตล่าสุดหรือข้อมูลไร้โครงสร้างอื่น ๆ ก็ได้ แต่เดโมนี้มองว่าแค่พิสูจน์แนวคิดแบบรวดเร็วก็น่าจะพอ
  • หากเผยแพร่ข้อมูลผ่าน DNS TXT record ก็อาจใช้งานได้คล้าย API ที่แทบไม่มีข้อจำกัดด้านจำนวนคำขอ และเหมาะกับข้อมูลแบบคงที่หรือเปลี่ยนไม่บ่อยมากกว่า

ข้อมูลแปลก ๆ ที่ใส่ใน DNS ได้

  • เดโมนี้เป็นวิธีที่ทั้งซับซ้อนและขำ ๆ ในการแสดงให้เห็นว่า DNS สามารถเก็บเรคอร์ดที่คาดไม่ถึงได้
  • เช่นเดียวกับการแทนพิกัด ISS ด้วย LOC record ก็ชวนให้นึกต่อได้ว่าจะอธิบายพิกัดของ Mars Rover อย่างไร
  • บทความ DNS ที่เกี่ยวข้องได้แก่ BIMI - SVG in DNS TXT WTF?! และ Why you can't dig Switzerland

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

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

 
GN⁺ 2025-07-07
ความคิดเห็นบน Hacker News

  • เรคคอร์ดอีกประเภทหนึ่งคือ Name Authority Pointer (NAPTR) มีหมายเลขโทรศัพท์ของ Johnson Space Center ในฮิวสตันอยู่ด้วย
    ถ้าดูด้วย dig where-is-the-iss.dedyn.io NAPTR จะเห็น E2U+voice:tel และ tel:+12814830123

  • เข้าใจเรื่องข้อจำกัดของ API แต่รอบอัปเดต 15 นาทีสำหรับวัตถุที่โคจรรอบโลก หนึ่งรอบใน 90 นาที ดูจะนานพอสมควร
    โดยเฉลี่ยแล้วตำแหน่งอาจคลาดเคลื่อนได้ราว 1/12 ของเส้นรอบวงโลก หรือประมาณระยะทางระหว่างลิสบอนกับอิสตันบูล

    • ใช่ ตามที่บทความบอกไว้ อย่าเอาสิ่งนี้ไปใช้กับ งานเทียบท่า
      ถ้ารู้วิธีอัปเดต DNS ที่อนุญาตให้อัปเดตระดับนาทีได้ฟรี ก็ยินดีย้ายไปใช้
    • ความเร็ววงโคจรของ ISS อยู่ที่ประมาณ 7.66 กม./วินาที ดังนั้นใน 15 นาทีจะเคลื่อนที่ไปราว 6,900 กม.
      สำหรับการติดตามตำแหน่งแบบแม่นยำ ถือว่าเป็นความคลาดเคลื่อนที่มากแน่นอน

  • อ่านประโยคแรกเป็น “I love DNS erotica” สงสัยเป็นสัญญาณว่าผมอยู่ในบ้านนานเกินไป ควรออกไปเดินเล่นแล้ว

    • อาจแปลกใจ แต่คิดว่าน่าจะมีคนไม่น้อยที่ขุดคุ้ยเรื่องแบบนี้
    • ตอนแรกผมก็อ่านแบบนั้นเหมือนกัน ดีใจที่ไม่ได้เป็นคนแปลกอยู่คนเดียว
      เดี๋ยวจะออกไปเดินเล่นแล้ว
    • นึกว่านี่คือเรื่องนั้นซะอีก
      คงต้องอาบน้ำเย็นด้วย
    • คำพูดว่า “มักจะเป็นปัญหา DNS เสมอ” ได้ความหมายใหม่ไปเลย

  • เจ๋งดี เพิ่งเพิ่มเข้าไปใน dns.toys ด้วย
    dig iss.sky +short @dns.toys
    [1] https://dns.toys

    • เรียบง่ายดีจริง ๆ สงสัยว่าเครื่องมือทั้งหมดใช้ TXT record หรือใช้พวก LOC, NAPTR ด้วย
    • ฝั่งสภาพอากาศมีบั๊ก บราติสลาวาไม่น่าจะติดลบองศาเซลเซียสในกลางฤดูร้อน และ Tallinn ก็คลาดไปราว 17°C

  • ยอดเยี่ยม ทั้งฉลาดและให้ความรู้ ทำให้นึกสงสัยทันทีว่าจะทำอะไรคล้าย ๆ กันกับ JWST ได้ไหม
    น่าเสียดายที่ DNS LOC record จำกัดไว้ราว 42 ล้านเมตร หรือก็คือระดับความสูงประมาณ 42,000 กม. แต่ JWST อยู่ไกลกว่านั้น 38 เท่า ที่ระยะประมาณ 1.5 ล้านกม.
    ดังนั้นจึงใช้ฟิลด์ความสูงของ LOC แทนตำแหน่งไม่ได้ ถ้าเป็น Hubble อาจพอทำได้

    • JWST โคจรรอบ จุดลากรองจ์ L2 เลยไม่ค่อยแน่ใจว่าจะเป็นอย่างไร
      คล้ายกับการถามพิกัด GPS ของดวงจันทร์ NASA เคยทดลองรับสัญญาณ GPS อ่อน ๆ บนดวงจันทร์ด้วย LRO ในปี 2023 แต่ยังไม่มีประโยชน์สำหรับการนำทาง
      เหตุผลที่วิธีนี้เหมาะกับ ISS คือมันมี จุดใต้ดาวเทียม บนพื้นผิวโลก รับสัญญาณ GPS ได้โดยไม่ขึ้นกับระดับความสูง
      อีกอย่าง TLE ใช้กับ ISS ซึ่งเป็นวัตถุในวงโคจรโลก TLE ถูกออกแบบมาเพื่อกำหนดตำแหน่งและความเร็วของดาวเทียมในวงโคจรโลกในรูปขององค์ประกอบวงโคจร แล้วให้โมเดลอย่าง SGP4 ตีความ
    • บางทีอาจเพราะ วงโคจรค้างฟ้า (GSO) อยู่แถวระดับความสูงนั้นพอดี

  • “RFC 1876 เป็นมาตรฐานเชิงทดลอง” นี่เป็นการทดลองที่ยาวนานจริง ๆ
    University of Warwick, January 1996
    [1] https://datatracker.ietf.org/doc/html/rfc1876

  • เอกสารเพิ่มเติมเกี่ยวกับ DNS LOC record: <https://www.ckdhr.com/dns-loc/>

  • วิธีที่ซับซ้อนขึ้นเล็กน้อยแต่ตอบสนองได้ดีกว่ามาก คือชี้ NS record ของ where-is-the-iss.shkspr.mobi ไปยัง IP ของ VPS ตัวเอง
    จากนั้นรันโปรแกรมที่ฟัง UDP/53 และ TCP/53 แล้วตอบกลับด้วยแพ็กเก็ต DNS ที่เปลี่ยนแบบไดนามิกเฉพาะ LOC record กับ message ID
    อาจไม่ได้ทำตามสเปก DNS อย่างครบถ้วน แต่สำหรับการใช้งานนี้ก็เพียงพอ สามารถแคชคำตอบของ API เพื่อเลี่ยงขีดจำกัดการเรียกได้

    • ประเด็นคือไม่อยากดูแลเซิร์ฟเวอร์เอง แต่สามารถเอา ระบบที่กระจายอยู่ทั่วโลก มาใช้ผิดวัตถุประสงค์แทนได้
    • วิธีนั้นสอดคล้องกับสเปก DNS อย่างสมบูรณ์
      ผมให้บริการแบบนั้นอยู่ และทดสอบได้ที่ 2+2.op.dyn.bortzmeyer.fr/TXT หรือ paris.now.weather.dyn.bortzmeyer.fr/TXT

  • DNS คือที่เก็บคีย์-ค่าแบบ federated ที่ปรับให้เหมาะกับการอ่าน มีการจำลองแบบตามภูมิศาสตร์ และมีความสอดคล้องแบบสุดท้าย

  • อ่าน RFC แล้วก็ยังไม่เห็นอธิบายว่าทำไมถึงต้องมีสิ่งนี้
    เลยสงสัยว่าในปี 1996 อาจมีเหตุผลเกี่ยวกับลอจิสติกส์ของมหาวิทยาลัยหรือศูนย์ข้อมูลหรือเปล่า

    • ในหัวข้อ 5.1 “Suggested Uses” มีตัวอย่างการใช้งานแบบคลุมเครืออยู่บ้าง
      ระบุว่า LOC RR ใช้ได้กับแผนที่การไหลของแบ็กโบน USENET, “visual traceroute” ที่แสดงเส้นทางเชิงภูมิศาสตร์ของแพ็กเก็ต IP, แอปจัดการเครือข่ายที่สร้างแผนที่โฮสต์และเราเตอร์ที่ดูแลอยู่ เป็นต้น
    • จากประสบการณ์ RFC มักจะเขียนปัญหาที่พวกเขาต้องการแก้ไว้ค่อนข้างคลุมเครือ
      ก็ไม่มีเหตุผลอะไรที่มันจะเป็นสตริงที่มนุษย์อ่านได้อย่าง “42 Wallaby Way, Sidney” ไม่ได้