Die Position der ISS per DNS herausfinden

 (shkspr.mobi)
3 Punkte von GN⁺ 2025-07-07 | 1 Kommentare | Auf WhatsApp teilen
  • where-is-the-iss.dedyn.io ist keine Website, sondern ein verspieltes Experiment, das die ungefähre Position der Internationalen Raumstation (ISS) allein über einen DNS-LOC-Record zurückgibt
  • DNS LOC ist ein experimenteller Standard aus RFC 1876, der in Domain-Records neben Breiten- und Längengrad auch die Höhe speichern kann
  • Der Höhenbereich von LOC-Records reicht von -100.000 m bis 42.849.672 m, sodass sich damit alles von unterirdischen Anlagen bis zu geostationären Satelliten ausdrücken lässt
  • Die ISS-Koordinaten werden über die N2YO-API abgerufen; damit sie in das LOC-Format passen, muss die Höhe von km in m umgerechnet und Breiten- sowie Längengrad in das Grad-Minuten-Sekunden-Format umgewandelt werden
  • Über die deSEC-API wird der Record aktualisiert und die TTL auf 900 Sekunden gesetzt, sodass die aktuelle Position im Best-Effort-Verfahren alle 15 Minuten eingepflegt wird

Positionsdaten in DNS-LOC-Records speichern

  • Domainnamen zeigen normalerweise auf Server, aber auch Server sind letztlich Geräte mit einem physischen Standort in einem Rechenzentrum
  • Ein DNS-LOC-Record ist ein DNS-Record, der Breitengrad, Längengrad und Höhe in einer Domain speichern kann
  • RFC 1876 ist der experimentelle Standard, der LOC-Records definiert
    • Da sich Rechenzentren in Hochhäusern oder unter der Erde befinden können, gibt es auch den Höhenparameter
    • Die Mindesthöhe beträgt -100.000 m
    • Die Maximalhöhe beträgt 42.849.672 m, also ein Bereich, der auch für geostationäre Satelliten ausreicht

where-is-the-iss.dedyn.io

  • where-is-the-iss.dedyn.io ist eine Domain, die erstellt wurde, um die ungefähre Position der ISS per DNS-Abfrage abzurufen
  • Diese Domain ist keine Website, sie lässt sich auch nicht anpingen und bietet außer DNS keine andere Form der Interaktion
  • Linux- und Mac-Nutzer können den LOC-Record mit folgendem Befehl abfragen
dig where-is-the-iss.dedyn.io LOC
  • Die Antwort liefert Breiten- und Längengrad sowie die Höhe der ISS im LOC-Format zurück
;; 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
  • Die DNS-Records werden alle 15 Minuten im Best-Effort-Verfahren aktualisiert
  • Für Windows in PowerShell oder der Eingabeaufforderung scheint sich keine einfache Möglichkeit zu finden, LOC-Records abzufragen

Positionsdaten abrufen

  • N2YO bietet eine Website zur Verfolgung verschiedener Objekte im Orbit sowie eine API mit einer großzügigen kostenlosen Stufe
  • Die ISS wird in der N2YO-API über die Satelliten-ID 25544 abgefragt
  • Die API-Antwort enthält Felder wie satlatitude, satlongitude, sataltitude, timestamp und 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
        }
    ]
}
  • Die Höhe in der N2YO-Antwort ist in km angegeben, das LOC-Format verlangt jedoch Meter
  • Breiten- und Längengrad kommen als Dezimalzahlen zurück und müssen für einen LOC-Record in das Grad-Minuten-Sekunden-Format (Degrees, Minutes, Seconds) umgewandelt werden

LOC-Records mit deSEC aktualisieren

  • Es gab nicht viele kostenlose Domain-Anbieter mit einer API zum Aktualisieren von LOC-Records, daher fiel die Wahl auf deSEC, eine gemeinnützige Organisation aus Berlin
  • deSEC stellt eine API-Dokumentation bereit
  • Der initiale LOC-Record wird per curl an den Endpunkt rrsets hinzugefügt
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}'
  • Das Aktualisieren des Records ist etwas komplizierter: Ein HTTP PATCH muss an eine andere URL gesendet werden
  • Die PATCH-Anfrage muss nur die geänderten Daten enthalten
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"]}'

Aktualisierungsintervall und Grenzen

  • Die TTL ist auf 900 Sekunden gesetzt
  • Der Code läuft alle 15 Minuten und aktualisiert den DNS-Record
  • Dieses Intervall bleibt innerhalb der API-Limits von N2YO und deSEC
  • Man könnte auch den Zeitpunkt der letzten Aktualisierung oder andere unstrukturierte Daten in einem TXT-Record speichern, aber für diese Demo reicht ein schneller Proof of Concept aus
  • Über DNS-TXT-Records verteilte Daten könnten auch wie eine API ohne nennenswerte Request-Limits genutzt werden und eignen sich besser für statische oder selten veränderte Daten

Ungewöhnliche Daten, die sich in DNS speichern lassen

  • Diese Demo zeigt auf komplexe und verspielte Weise, dass DNS auch unerwartete Record-Typen aufnehmen kann
  • So wie hier die ISS-Koordinaten als LOC-Record dargestellt werden, kann man sich auch fragen, wie sich die Koordinaten eines Mars Rover ausdrücken ließen
  • Verwandte DNS-Artikel sind BIMI - SVG in DNS TXT WTF?! und Why you can't dig Switzerland

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-07
Kommentare auf Hacker News

  • Ein anderer Record, der Naming Authority Pointer (NAPTR), enthält die Telefonnummer des Johnson Space Center in Houston.
    Mit dig where-is-the-iss.dedyn.io NAPTR sieht man E2U+voice:tel und tel:+12814830123.

  • Ich verstehe die API-Beschränkungen, aber für ein Objekt, das die Erde in 90 Minuten einmal umrundet, wirkt ein Aktualisierungsintervall von 15 Minuten ziemlich lang.
    Im Mittel kann die Position um etwa 1/12 des Erdumfangs abweichen, grob die Entfernung zwischen Lissabon und Istanbul.

    • Stimmt. Wie im Artikel gesagt: Man sollte das nicht für Docking-Manöver verwenden.
      Wenn jemand eine DNS-Update-Methode kennt, die kostenlos Aktualisierungen im Minutentakt erlaubt, würde ich gern umziehen.
    • Die Bahngeschwindigkeit der ISS beträgt etwa 7,66 km/s, also legt sie in 15 Minuten rund 6.900 km zurück.
      Für präzises Positionstracking ist das definitiv ein großer Fehler.

  • Ich habe den ersten Satz als „I love DNS erotica“ gelesen; das ist wohl ein Zeichen, dass ich zu lange drinnen war und spazieren gehen sollte.

    • Es mag überraschen, aber ich glaube, es gibt ziemlich viele Leute, die sich in so etwas vertiefen würden.
    • Ich habe es zuerst auch so gelesen; gut zu wissen, dass ich nicht der einzige Seltsame bin.
      Ich gehe jetzt spazieren.
    • Ich dachte, genau darum ginge es.
      Eine kalte Dusche wäre wohl auch nötig.
    • Der Satz „Es ist immer DNS“ bekommt damit eine völlig neue Bedeutung.

  • Ziemlich cool. Ich habe es gerade auch zu dns.toys hinzugefügt.
    dig iss.sky +short @dns.toys
    [1] https://dns.toys

    • Wirklich sauber. Ich frage mich, ob die Tools alle TXT-Records verwenden oder auch Dinge wie LOC und NAPTR.
    • Beim Wetter gibt es einen Bug. In Bratislava kann es im Hochsommer kaum unter null Grad Celsius haben, und Tallinn lag ebenfalls um etwa 17 °C daneben.

  • Großartig. Clever und zugleich lehrreich. Ich habe mich sofort gefragt, ob man Ähnliches auch für das JWST machen könnte.
    Leider hat der DNS-LOC-Record ein Limit von etwa 42 Millionen Metern, also rund 42.000 km Höhe; das JWST ist mit ungefähr 1,5 Millionen km etwa 38-mal weiter entfernt.
    Daher lässt sich seine Position nicht über das Höhenfeld von LOC darstellen. Mit Hubble könnte es vielleicht gehen.

    • Das JWST umkreist den zweiten Lagrange-Punkt, daher weiß ich nicht genau, wie das funktionieren würde.
      Es ist ein bisschen so, als würde man nach den GPS-Koordinaten des Mondes fragen. Die NASA hat 2023 zwar mit LRO den Empfang schwacher GPS-Signale auf dem Mond getestet, aber für Navigation ist das noch nicht nützlich.
      Der Grund, warum diese Methode für die ISS passt, ist, dass es einen Subsatellitenpunkt auf der Erdoberfläche gibt. Unabhängig von der Höhe kann man GPS-Signale empfangen.
      Außerdem gelten TLEs für die ISS als Objekt in einer Erdumlaufbahn. TLEs sind dafür ausgelegt, Position und Geschwindigkeit von Satelliten in Erdumlaufbahnen als Bahnelemente zu definieren, die Modelle wie SGP4 auswerten.
    • Wahrscheinlich liegt es daran, dass die geostationäre Umlaufbahn (GSO) ungefähr in dieser Höhe liegt.

  • „RFC 1876 ist ein experimenteller Standard“ – ein wirklich langlebiges Experiment.
    University of Warwick, Januar 1996
    [1] https://datatracker.ietf.org/doc/html/rfc1876

  • Weiteres Material zu DNS-LOC-Records: <https://www.ckdhr.com/dns-loc/>

  • Eine etwas komplexere, aber viel reaktionsschnellere Methode wäre, den NS-Record von where-is-the-iss.shkspr.mobi auf die IP des eigenen VPS zeigen zu lassen.
    Danach lässt man ein Programm auf UDP/53 und TCP/53 lauschen und DNS-Pakete zurückgeben, bei denen sich nur der LOC-Record und die Message-ID dynamisch ändern.
    Das würde der DNS-Spezifikation nicht vollständig entsprechen, wäre für diesen Zweck aber ausreichend. Die API-Antworten kann man cachen, um Rate Limits zu vermeiden.

    • Der entscheidende Punkt ist, dass man keinen Server betreiben möchte. Stattdessen kann man ein weltweit verteiltes System zweckentfremden.
    • Dieses Vorgehen entspricht vollständig der DNS-Spezifikation.
      Ich betreibe selbst so einen Dienst; man kann ihn mit 2+2.op.dyn.bortzmeyer.fr/TXT oder paris.now.weather.dyn.bortzmeyer.fr/TXT testen.

  • DNS ist ein föderierter, leseoptimierter, geografisch replizierter Key-Value-Store mit Eventual Consistency.

  • Selbst im RFC steht nicht, warum das gebraucht wurde.
    Ich frage mich, ob es 1996 Gründe im Zusammenhang mit Universitäts- oder Rechenzentrumslogistik gab.

    • In Abschnitt 5.1 „Suggested Uses“ gibt es zumindest ein paar vage Anwendungsbeispiele.
      Dort heißt es, ein LOC RR könne für Karten der USENET-Backbone-Flüsse, für eine „visuelle traceroute“, die den geografischen Pfad von IP-Paketen zeigt, sowie für Netzwerkmanagement-Anwendungen genutzt werden, die Karten der verwalteten Hosts und Router erzeugen.
    • Meiner Erfahrung nach beschreiben RFCs das Problem, das sie lösen wollen, meistens eher vage.
      Es gibt auch keinen Grund, warum das nicht eine für Menschen lesbare Zeichenkette wie „42 Wallaby Way, Sidney“ sein könnte.