ISS'nin konumunu DNS ile öğrenmek

 (shkspr.mobi)
3 puan yazan GN⁺ 2025-07-07 | 1 yorum | WhatsApp'ta paylaş
  • where-is-the-iss.dedyn.io, bir web sitesi değil; yalnızca DNS LOC kaydı ile Uluslararası Uzay İstasyonu'nun (ISS) yaklaşık konumunu döndüren eğlenceli bir deney
  • DNS LOC, RFC 1876 kapsamındaki deneysel bir standart ve alan adı kayıtlarında enlem-boylamın yanı sıra irtifayı da tutabiliyor
  • LOC kaydının irtifa aralığı -100.000m ile 42.849.672m arasında olduğundan, yer altı tesislerinden jeostasyoner uydulara kadar ifade edilebiliyor
  • ISS koordinatları N2YO API'den alınıyor; LOC biçimine uyması için irtifa km'den m'ye, enlem-boylam ise derece-dakika-saniye biçimine dönüştürülüyor
  • Kayıt deSEC API ile güncelleniyor ve TTL 900 saniye olarak ayarlanıyor; böylece her 15 dakikada bir en iyi çaba (best-effort) yaklaşımıyla en güncel konum yansıtılıyor

DNS LOC kaydıyla konum saklamak

  • Alan adları genelde sunucuları işaret eder, ancak sunucular da sonuçta veri merkezlerinde bulunan fiziksel konuma sahip cihazlardır
  • DNS LOC kaydı, bir alan adına enlem, boylam ve irtifa ekleyebilen bir DNS kayıt türüdür
  • RFC 1876, LOC kaydını tanımlayan deneysel standarttır
    • Veri merkezleri yüksek binalarda ya da yer altında bulunabileceğinden, irtifa parametresi de buna dahildir
    • Minimum irtifa -100.000m'dir
    • Maksimum irtifa 42.849.672m olup, jeostasyoner uydular için de yeterli bir aralıktır

where-is-the-iss.dedyn.io

  • where-is-the-iss.dedyn.io, ISS'nin yaklaşık konumunu bir DNS sorgusuyla almak için oluşturulmuş bir alan adıdır
  • Bu alan adı bir web sitesi değildir; ping atılamaz ve DNS dışında başka bir etkileşim yöntemi yoktur
  • Linux ve Mac kullanıcıları LOC kaydını şu komutla sorgulayabilir
dig where-is-the-iss.dedyn.io LOC
  • Yanıt, ISS'nin enlem, boylam ve irtifasını LOC biçiminde döndürür
;; 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 kaydı her 15 dakikada bir en iyi çaba yaklaşımıyla güncellenir
  • Windows PowerShell veya Command Prompt üzerinde LOC kaydı sorgulamanın kolay bir yolu olmadığı düşünülüyor

Konum verisini almak

  • N2YO, yörüngedeki çeşitli nesneleri izlemeye yarayan bir web sitesi ve cömert bir ücretsiz katmana sahip bir API sunuyor
  • ISS, N2YO API'de 25544 uydu kimliğiyle sorgulanıyor
  • API yanıtında satlatitude, satlongitude, sataltitude, timestamp, eclipsed gibi alanlar bulunuyor
{
    "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 yanıtındaki irtifa km cinsindedir, ancak LOC biçimi m cinsinden değer ister
  • Enlem ve boylam ondalık biçimde geldiği için, LOC kaydına eklemek üzere derece-dakika-saniye (Degrees, Minutes, Seconds) biçimine çevrilmeleri gerekir

deSEC ile LOC kaydını güncellemek

  • LOC kaydı güncelleme API'si sunan ücretsiz alan adı sağlayıcısı pek olmadığından, Berlin merkezli kâr amacı gütmeyen deSEC seçilmiş
  • deSEC, API belgelerini sağlıyor
  • İlk LOC kaydı, rrsets uç noktasına curl ile ekleniyor
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}'
  • Kaydı güncellemek biraz daha zahmetli; HTTP PATCH isteğinin farklı bir URL'ye gönderilmesi gerekiyor
  • PATCH isteğinde yalnızca değişen veriyi göndermek yeterli
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"]}'

Güncelleme sıklığı ve sınırlamalar

  • TTL 900 saniye olarak ayarlanmış
  • Kod her 15 dakikada bir çalışarak DNS kaydını güncelliyor
  • Bu aralık, hem N2YO hem de deSEC tarafındaki API limitleri içinde kalmayı sağlıyor
  • Son güncelleme zamanı veya başka yapısız veriler bir TXT kaydına da konabilir, ancak bu demoda hızlı bir kavram kanıtı için bunun yeterli olduğu düşünülüyor
  • Veriyi DNS TXT kaydıyla dağıtmak, istek limiti fiilen olmayan bir API gibi de kullanılabilir; bu yaklaşım statik ya da sık değişmeyen veriler için daha uygundur

DNS'e gömülebilecek sıra dışı veriler

  • Bu demo, DNS'in beklenmedik kayıt türlerini de taşıyabildiğini gösteren karmaşık ve eğlenceli bir yöntem
  • ISS koordinatlarını LOC kaydıyla ifade etmek gibi, Mars Rover koordinatlarının nasıl temsil edilebileceği de akla gelebilir
  • Konuyla ilgili DNS yazıları arasında BIMI - SVG in DNS TXT WTF?! ve Why you can't dig Switzerland yer alıyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-07
Hacker News yorumları

  • Başka bir kayıt olan Adlandırma Yetki İşaretçisi (NAPTR) içinde Houston Johnson Space Center’ın telefon numarası yer alıyor
    dig where-is-the-iss.dedyn.io NAPTR ile bakınca E2U+voice:tel ve tel:+12814830123 görünüyor

  • API limitlerini anlıyorum ama Dünya’nın etrafını 90 dakikada bir tur atan bir nesne için 15 dakikalık güncelleme aralığı epey uzun görünüyor
    Ortalama olarak Dünya çevresinin yaklaşık 1/12’si kadar, kabaca Lizbon ile İstanbul arasındaki mesafe kadar konum sapabilir

    • Doğru. Yazıda da söylendiği gibi bunu kenetlenme operasyonlarında kullanmamak gerek
      Ücretsiz olarak dakika düzeyinde güncellemeye izin veren bir DNS güncelleme yöntemi bilirsem memnuniyetle taşırım
    • ISS’in yörünge hızı yaklaşık 7,66 km/sn, yani 15 dakikada yaklaşık 6.900 km yol alıyor
      Hassas konum takibi için kesinlikle büyük bir hata payı

  • İlk cümleyi “I love DNS erotica” diye okudum; sanırım fazla uzun süredir içeride kaldım, yürüyüşe çıkmam gerektiğinin işareti

    • Şaşırtıcı gelebilir ama böyle şeylere dalacak epey insan olduğunu düşünüyorum
    • Ben de ilk başta öyle okudum; tek tuhaf kişinin ben olmadığıma sevindim
      Şimdi yürüyüşe çıkıyorum
    • Bunun o şey olmadığından emin değilim
      Soğuk duş da gerekebilir
    • “Sorun her zaman DNS’tedir” sözünün anlamı tamamen değişti

  • Epey harika. Az önce dns.toys’a da ekledim
    dig iss.sky +short @dns.toys
    [1] https://dns.toys

    • Gerçekten çok temiz. Araçların hepsinin TXT kayıtları kullanıp kullanmadığını, yoksa LOC, NAPTR gibi kayıtları da kullanıp kullanmadığını merak ediyorum
    • Hava durumu tarafında bir hata var. Bratislava yaz ortasında sıfırın altında santigrat olamaz; Tallinn de yaklaşık 17°C kadar sapmıştı

  • Harika. Zekice ve aynı zamanda öğretici. JWST için de benzer bir şey yapılabilir mi diye hemen merak ettim
    Ne yazık ki DNS LOC kaydı yaklaşık 42 milyon metreyle, yani 42.000 km irtifayla sınırlı; JWST ise bundan 38 kat daha uzakta, yaklaşık 1,5 milyon km mesafede
    Bu yüzden LOC’un irtifa alanıyla konumu ifade etmek mümkün değil. Hubble için belki olabilir

    • JWST ikinci Lagrange noktası etrafında döndüğü için ne olacağından pek emin değilim
      Ay’ın GPS koordinatlarını sormaya benziyor. NASA 2023’te LRO ile Ay’da zayıf GPS sinyali almayı denedi, ama bu henüz navigasyon için işe yarar değil
      Bu yöntemin ISS’e uygun olmasının nedeni, Dünya yüzeyi üzerinde bir uydu alt noktası bulunması. İrtifadan bağımsız olarak GPS sinyali alınabiliyor
      Ayrıca TLE, Dünya yörüngesindeki bir nesne olan ISS için geçerli. TLE, Dünya yörüngesindeki uyduların konumunu ve hızını yörünge elemanlarıyla tanımlamak ve SGP4 gibi modellerin bunları yorumlaması için tasarlanmış
    • Muhtemelen jeosenkron yörünge (GSO) tam o irtifa civarında olduğu içindir

  • “RFC 1876 deneysel bir standarttır” denmiş; gerçekten çok uzun süren bir deney
    University of Warwick, January 1996
    [1] https://datatracker.ietf.org/doc/html/rfc1876

  • DNS LOC kayıtları hakkında ek kaynak: <https://www.ckdhr.com/dns-loc/>

  • Biraz daha karmaşık ama çok daha hızlı tepki veren yöntem, where-is-the-iss.shkspr.mobi için NS kaydını kendi VPS’inizin IP’sine yönlendirmek
    Sonra UDP/53 ve TCP/53 dinleyen bir program çalıştırıp yalnızca LOC kaydı ve mesaj ID’si dinamik olarak değişen DNS paketleriyle yanıt vermek yeterli
    DNS spesifikasyonuna tamamen uymaz ama bu kullanım için yeterli. API yanıtı önbelleğe alınarak çağrı limitlerinden kaçınılabilir

    • Asıl mesele sunucu işletmek istememek. Bunun yerine dünya çapında dağıtılmış bir sistemi kötüye kullanabilirsiniz
    • Bu yöntem DNS spesifikasyonuna tamamen uygundur
      Ben bizzat böyle bir hizmet işletiyorum; 2+2.op.dyn.bortzmeyer.fr/TXT veya paris.now.weather.dyn.bortzmeyer.fr/TXT ile test edebilirsiniz

  • DNS, federe, okuma için optimize edilmiş, coğrafi olarak çoğaltılmış ve nihai tutarlılığa sahip bir anahtar-değer deposudur

  • RFC’ye bakınca bile bunun neden gerekli olduğu açıklanmıyor
    1996’da üniversite ya da veri merkezi lojistiğiyle ilgili bir nedeni mi vardı diye düşünüyorum

    • 5.1 “Suggested Uses” bölümünde en azından belirsiz birkaç kullanım örneği var
      LOC RR’ın USENET omurga akış haritaları, IP paketlerinin coğrafi yolunu gösteren “görsel traceroute” ve yönetilen host ile router haritaları oluşturan ağ yönetimi uygulamaları için kullanılabileceği yazıyor
    • Deneyimime göre RFC’ler çözmeye çalıştıkları problemi genelde muğlak yazar
      Bunun “42 Wallaby Way, Sidney” gibi insan tarafından okunabilir bir metin olmaması için de bir neden yok