DNS से ISS की लोकेशन पता करना

 (shkspr.mobi)
3 पॉइंट द्वारा GN⁺ 2025-07-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • where-is-the-iss.dedyn.io कोई वेबसाइट नहीं, बल्कि एक मज़ेदार प्रयोग है जो सिर्फ DNS LOC रिकॉर्ड के ज़रिए International Space Station (ISS) की अनुमानित लोकेशन लौटाता है
  • DNS LOC, RFC 1876 का एक experimental standard है, जिससे domain record में latitude और longitude के साथ altitude भी रखा जा सकता है
  • LOC record की altitude range -100,000m से 42,849,672m तक है, इसलिए इससे भूमिगत सुविधाओं से लेकर geostationary satellites तक को दर्शाया जा सकता है
  • ISS coordinates N2YO API से लिए जाते हैं, और LOC format में फिट करने के लिए altitude को km से m में, तथा latitude·longitude को degrees·minutes·seconds format में बदलना पड़ता है
  • deSEC API से record update किया जाता है और TTL 900 seconds सेट किया गया है, ताकि हर 15 मिनट में best-effort तरीके से नई लोकेशन reflect हो सके

DNS LOC record में लोकेशन रखना

  • Domain name आम तौर पर server की ओर इशारा करता है, लेकिन server भी आखिरकार data center के अंदर किसी physical location पर मौजूद equipment होता है
  • DNS LOC record ऐसा DNS record है जिसमें domain के लिए latitude·longitude·altitude रखे जा सकते हैं
  • RFC 1876 LOC record को define करने वाला experimental standard है
    • Data center ऊंची इमारत में या underground हो सकता है, इसलिए altitude parameter भी शामिल है
    • न्यूनतम altitude -100,000m है
    • अधिकतम altitude 42,849,672m है, जो geostationary satellite के लिए भी इस्तेमाल हो सकने वाली range है

where-is-the-iss.dedyn.io

  • where-is-the-iss.dedyn.io ISS की अनुमानित लोकेशन DNS query से पाने के लिए बनाया गया domain है
  • यह domain वेबसाइट नहीं है, इसे ping भी नहीं किया जा सकता और DNS के अलावा कोई interaction method नहीं है
  • Linux और Mac users नीचे दिए command से LOC record query कर सकते हैं
dig where-is-the-iss.dedyn.io LOC
  • Response ISS का latitude·longitude·altitude LOC format में लौटाता है
;; 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 हर 15 मिनट में best-effort basis पर update होता है
  • Windows के PowerShell या Command Prompt में LOC record query करने का तरीका खोजना मुश्किल माना गया

लोकेशन डेटा लाना

  • N2YO एक website और generous free tier वाला API देता है, जिससे orbit में मौजूद कई objects track किए जा सकते हैं
  • ISS को N2YO API में satellite ID 25544 से query किया जाता है
  • API response में satlatitude, satlongitude, sataltitude, timestamp, eclipsed जैसे fields होते हैं
{
    "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 response में altitude km unit में होता है, लेकिन LOC format m unit मांगता है
  • Latitude और longitude decimal में आते हैं, इसलिए LOC record में डालने के लिए उन्हें Degrees, Minutes, Seconds format में बदलना पड़ता है

deSEC से LOC record update करना

  • LOC record update API देने वाले free domain name providers बहुत ज्यादा नहीं थे, इसलिए Berlin की charitable organization deSEC चुनी गई
  • deSEC API documentation देता है
  • Initial LOC record को rrsets endpoint पर curl से add किया गया
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}'
  • Record update करना थोड़ा ज्यादा tricky है, क्योंकि HTTP PATCH को अलग URL पर भेजना पड़ता है
  • PATCH request में सिर्फ बदला हुआ data रखना काफी है
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"]}'

Update interval और सीमाएं

  • TTL को 900 seconds सेट किया गया
  • Code हर 15 मिनट में run होकर DNS record update करता है
  • यह interval N2YO और deSEC दोनों के API limits के अंदर रहने देता है
  • TXT record में last update time या दूसरा unstructured data भी रखा जा सकता है, लेकिन इस demo में quick proof of concept पर्याप्त माना गया
  • DNS TXT record में data distribute करने पर उसे practically request limit के बिना API की तरह भी इस्तेमाल किया जा सकता है, और यह static या कम बदलने वाले data के लिए ज्यादा suitable है

DNS में रखे जा सकने वाले अनोखे data

  • यह demo एक complex और playful तरीका है यह दिखाने का कि DNS unexpected records भी रख सकता है
  • जैसे ISS coordinates को LOC record से represent किया गया, वैसे ही Mars Rover के coordinates को कैसे represent किया जाए, यह भी सोचा जा सकता है
  • संबंधित DNS posts में BIMI - SVG in DNS TXT WTF?! और Why you can't dig Switzerland शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-07-07
Hacker News की राय

  • एक अन्य रिकॉर्ड, Naming Authority Pointer (NAPTR) में Houston Johnson Space Center का फ़ोन नंबर है
    dig where-is-the-iss.dedyn.io NAPTR से देखने पर E2U+voice:tel और tel:+12814830123 दिखता है

  • API limit समझ में आती है, लेकिन पृथ्वी का 90 मिनट में एक चक्कर लगाने वाली चीज़ के लिए 15 मिनट का update interval काफ़ी लंबा लगता है
    औसतन लोकेशन पृथ्वी की परिधि के लगभग 1/12 हिस्से जितनी, यानी करीब Lisbon और Istanbul के बीच की दूरी जितनी, गलत हो सकती है

    • सही है। लेख में भी कहा गया है कि इसे docking operations के लिए इस्तेमाल नहीं करना चाहिए
      अगर मुझे DNS update का कोई ऐसा तरीका पता चले जो मुफ्त में मिनट-दर-मिनट updates की अनुमति देता हो, तो मैं खुशी से उस पर शिफ्ट हो जाऊंगा
    • ISS की orbital speed करीब 7.66km/s है, इसलिए 15 मिनट में यह लगभग 6,900km चल जाता है
      सटीक location tracking के लिए यह निश्चित रूप से बहुत बड़ी त्रुटि है

  • मैंने पहला वाक्य “I love DNS erotica” पढ़ लिया था; लगता है यह संकेत है कि मैं बहुत देर से घर के अंदर हूं और मुझे टहलने जाना चाहिए

    • हैरानी की बात हो सकती है, लेकिन मुझे लगता है कि ऐसे विषय में गहराई से जाने वाले लोग काफ़ी होंगे
    • मैंने भी पहले ऐसा ही पढ़ा था, राहत है कि मैं अकेला अजीब इंसान नहीं हूं
      अब टहलने जा रहा हूं
    • मुझे लगा था कि शायद यह वही है
      शायद ठंडे पानी से shower भी लेना पड़ेगा
    • “हमेशा DNS की ही समस्या होती है” वाली बात का बिल्कुल नया मतलब बन गया

  • काफ़ी शानदार। अभी-अभी इसे dns.toys में भी जोड़ दिया
    dig iss.sky +short @dns.toys
    [1] https://dns.toys

    • सच में साफ-सुथरा है। सोच रहा हूं कि क्या सारे tools TXT records इस्तेमाल करते हैं, या LOC, NAPTR जैसी चीज़ें भी इस्तेमाल होती हैं
    • weather वाले हिस्से में bug है। Bratislava में गर्मियों के बीच तापमान Celsius में शून्य से नीचे नहीं हो सकता, और Tallinn भी करीब 17°C तक गलत था

  • बेहतरीन। चतुर भी है और शिक्षाप्रद भी। तुरंत मन में आया कि क्या JWST के लिए भी ऐसा कुछ किया जा सकता है
    अफ़सोस, DNS LOC record की सीमा करीब 42 million meters, यानी लगभग 42,000km altitude तक है, जबकि JWST उससे 38 गुना दूर, करीब 1.5 million km पर है
    इसलिए LOC के altitude field से उसकी position व्यक्त नहीं की जा सकती। Hubble के लिए शायद संभव हो

    • JWST दूसरे Lagrange point की परिक्रमा करता है, इसलिए ठीक-ठीक क्या होगा कहना मुश्किल है
      यह चंद्रमा के GPS coordinates पूछने जैसा है। NASA ने 2023 में LRO के साथ चंद्रमा पर कमजोर GPS signals receive करने का परीक्षण तो किया था, लेकिन वे अभी navigation के लिए उपयोगी नहीं हैं
      ISS के लिए यह तरीका इसलिए सही बैठता है क्योंकि पृथ्वी की सतह पर इसका sub-satellite point होता है। altitude चाहे जो हो, GPS signal मिल सकता है
      साथ ही TLE, ISS जैसे Earth-orbit object पर लागू होता है। TLE को Earth-orbit satellites की position और velocity को orbital elements के रूप में define करने और SGP4 जैसे models द्वारा interpret किए जाने के लिए design किया गया है
    • शायद इसलिए क्योंकि Geosynchronous Orbit (GSO) लगभग उसी altitude के आसपास होता है

  • “RFC 1876 is an experimental standard” यानी सच में बहुत लंबे समय से चल रहा experiment है
    University of Warwick, January 1996
    [1] https://datatracker.ietf.org/doc/html/rfc1876

  • DNS LOC records पर अतिरिक्त सामग्री: <https://www.ckdhr.com/dns-loc/>

  • थोड़ा ज़्यादा जटिल लेकिन कहीं अधिक responsive तरीका यह है कि where-is-the-iss.shkspr.mobi के NS record को अपने VPS के IP की ओर point करा दें
    फिर UDP/53 और TCP/53 सुनने वाला program चलाएं, और ऐसे DNS packets से जवाब दें जिनमें सिर्फ LOC record और message ID dynamically बदलते हों
    यह DNS specification का पूरी तरह पालन नहीं करेगा, लेकिन इस काम के लिए काफ़ी होगा। API response cache किया जा सकता है ताकि call limits से बचा जा सके

    • मुख्य बात यह है कि मैं server चलाना नहीं चाहता। इसके बजाय दुनिया भर में फैले distributed system का दुरुपयोग किया जा सकता है
    • वह तरीका DNS specification के साथ पूरी तरह compliant है
      मैं खुद ऐसी service चला रहा हूं, और 2+2.op.dyn.bortzmeyer.fr/TXT या paris.now.weather.dyn.bortzmeyer.fr/TXT से test किया जा सकता है

  • DNS एक federated, read-optimized, geographically replicated, eventually consistent key-value store है

  • RFC देखने पर भी यह नहीं बताया गया कि इसकी ज़रूरत क्यों थी
    सोचता हूं कि क्या 1996 में universities या datacenter logistics से जुड़ा कोई कारण रहा होगा

    • section 5.1 “Suggested Uses” में कम-से-कम कुछ अस्पष्ट use cases दिए गए हैं
      इसमें कहा गया है कि LOC RR का इस्तेमाल USENET backbone flow maps, IP packets के geographic route दिखाने वाले “visual traceroute”, managed hosts और routers के maps बनाने वाली network management apps आदि में हो सकता है
    • अनुभव से कहूं तो RFC आम तौर पर उस problem को अस्पष्ट तरीके से लिखते हैं जिसे वे solve करना चाहते हैं
      ऐसा कोई कारण नहीं कि यह “42 Wallaby Way, Sidney” जैसी इंसानों द्वारा पढ़ी जा सकने वाली string न हो