Die Position der ISS per DNS abrufen

 (shkspr.mobi)
3 Punkte von GN⁺ 2025-07-07 | 1 Kommentare | Auf WhatsApp teilen
  • Mit einem DNS-LOC-Record lassen sich Echtzeit-Positionsdaten der Internationalen Raumstation (ISS) abfragen
  • LOC-Records speichern Breiten-, Längen- und Höhenangaben und eignen sich damit gut für die Positionsverfolgung von Satelliten
  • Bei einer DNS-Abfrage der Beispiel-Domain where-is-the-iss.dedyn.io wird die aktuelle Position der ISS zurückgegeben
  • Über die N2YO API werden Positionsdaten abgerufen, und der LOC-Record wird alle 15 Minuten automatisch aktualisiert
  • Mit Domain-Diensten mit API-Unterstützung wie deSEC lassen sich LOC-Informationen effizient aktualisieren

Überblick

  • Ausgehend vom Interesse an den esoterischen Seiten von DNS lässt sich mit DNS-LOC-Records reale physische Positionsinformation weltweit verteilen
  • Normalerweise sind Domain-Namen mit dem physischen Standort von Servern verbunden; per LOC-Record lässt sich aber nicht nur der Standort von Servern, sondern auch der ungewöhnlicher Geräte festhalten

Was ist ein DNS-LOC-Record?

  • Ein in RFC 1876 definierter experimenteller Standard, mit dem sich Breiten-, Längen- und Höhenangaben eines Servers in DNS eintragen lassen
  • Minimale Höhe: -100.000 m (zur Darstellung unterirdischer Orte wie Bunker), maximale Höhe: 42.849.672 m (bis hin zu geostationären Satelliten)
  • Bietet die Möglichkeit, Positionsdaten verschiedenster Geräte einschließlich Satelliten per DNS zu übermitteln

Umsetzung eines Dienstes zur Abfrage der ISS-Position

  • Erstellung der Domain where-is-the-iss.dedyn.io, die ausschließlich über DNS-Abfragen funktioniert, ganz ohne separate Website, Ping oder sonstige allgemeine Interaktion

  • Unter Linux und Mac lässt sich die ISS-Position mit folgendem Befehl abfragen

    dig where-is-the-iss.dedyn.io LOC

  • Beispiel einer Rückgabe: Breiten-/Längen-/Höhenangaben werden im LOC-Format geliefert

    where-is-the-iss.dedyn.io. 1066 IN  LOC 47 24 53.500 N 66 12 12.070 W 430520m 10000m 10000m 10000m

  • Alle 15 Minuten wird mit den neuesten Positionsdaten aktualisiert (best effort)

Beschaffung und Umwandlung der Positionsdaten

  • Über die Website und API von N2YO lassen sich verschiedene Objekte im Orbit verfolgen; es gibt auch einen API-Free-Tier

  • Mit dem Beispiel-API-Aufruf lassen sich aktuelle Satellitenpositionen (Breitengrad, Längengrad, Höhe usw.) im JSON-Format abrufen

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

  • Die zurückgegebenen Breiten- und Längengrade liegen im Dezimalformat vor, die Höhe in km → für die Umwandlung in einen LOC-Record ist eine Konvertierung in Grad/Minuten/Sekunden (DMS) sowie Meter (m) erforderlich

Automatisierung der LOC-Record-Aktualisierung

  • Über die API von deSEC (gemeinnützige Organisation mit Sitz in Berlin) lassen sich LOC-Records initial anlegen und aktualisieren
  • Beispiel für die erste Registrierung eines LOC-Records 
    curl https://desec.io/api/v1/domains/where-is-the-iss.dedyn.io/rrsets/ ... --data '{"type": "LOC", "records": ["..."], "ttl": 900}'
  • Für Aktualisierungen wird HTTP PATCH verwendet, sodass nur geänderte Informationen übertragen werden
  • Mit TTL (900 Sekunden, 15 Minuten) konfiguriert, führt der Code alle 15 Minuten automatisch eine Aktualisierung durch
  • So lassen sich API-Nutzungslimits einhalten und zugleich aktuelle Daten effizient bereitstellen
  • Zusätzlich sind Erweiterungen wie das Protokollieren des Aktualisierungszeitpunkts über TXT-Records möglich

Fazit

  • Dieser Versuch ist eine technische Demonstration, die die ungewöhnlichen Einsatzmöglichkeiten von DNS zeigt
  • Künftig könnten auch die Positionen weiterer Raumobjekte wie eines Mars Rovers über DNS-LOC-Records dargestellt werden
  • Als originelles Anwendungsbeispiel für DNS bietet es Erweiterungspotenzial für die Automatisierung von Infrastruktur-/IT-Aufgaben und das Management von Positionsdaten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-07
Hacker-News-Kommentare
  • Ein weiterer Record, der Name Authority Pointer (NAPTR), liefert die Telefonnummer des Johnson Space Center in Houston. 
    > 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
  • Es wird eingeräumt, dass es API-Beschränkungen gibt, aber ein Update-Intervall von 15 Minuten für ein Objekt, das die Erde in 90 Minuten umrundet, sei schon ziemlich groß; im Durchschnitt entspreche das etwa 1/12 des Erdumfangs, was einen Fehler in der Größenordnung der Strecke zwischen Lissabon und Istanbul verursachen könne.
    • Dem wird zugestimmt; im Beitrag stehe auch, dass man es nicht für Docking-Manöver verwenden solle. Wenn es ein kostenloses DNS mit Updates im Minutentakt gäbe, würde man sofort darauf umsteigen.
  • Jemand erzählt, den ersten Satz fälschlich als „I love DNS erotica“ gelesen zu haben, und habe dabei erkannt, wohl zu lange drinnen gewesen zu sein und dringend einen Spaziergang zu brauchen.
    • Vielleicht überraschend, aber viele Menschen würden so etwas wahrscheinlich wirklich interessant finden.
    • Der Witz folgt, dass dieses Projekt doch genau diese DNS-Erotik sei und vielleicht eine kalte Dusche nötig werde.
    • Es wird darum gebeten, sich zurückzuhalten, da man keine Karriere als OnlyFans-Creator anstrebe.
    • Außerdem der Scherz, dass das Meme „It's always DNS“ damit eine neue Bedeutung bekomme.
  • Das Projekt wird als extrem cool gelobt und direkt zu dns.toys hinzugefügt. 
    dig iss.sky +short @dns.toys
    • Begeisterung darüber, wie praktisch und faszinierend das sei, verbunden mit einem Dankeschön und der Frage, ob alle Tools nur TXT-Records nutzen oder auch LOC und NAPTR einsetzen.
  • Viel Lob dafür, wie originell und lehrreich die Idee sei; sofort kommt die Frage auf, ob sich etwas Ähnliches auch für das JWST umsetzen ließe. Leider unterstützen DNS-LOC-Records nur bis etwa 42 Millionen Meter (42.000 km), und das JWST ist 38-mal weiter entfernt, wodurch die Positionsdarstellung an Grenzen stößt; beim Hubble könnte es vielleicht funktionieren.
    • Das JWST umkreist den zweiten Lagrange-Punkt, weshalb sich GPS-Koordinaten nicht einfach angeben lassen; das sei ungefähr so, als würde man GPS-Koordinaten für den Mond verlangen. 2023 testete die NASA mit dem LRO zwar den Empfang schwacher GPS-Signale am Mond, für die Navigation sei das aber nicht praktikabel. Die ISS kann neben ihrem Subsatellitenpunkt unabhängig von ihrer Höhe über dem Boden GPS-Signale empfangen. TLEs (Two-Line Elements) lassen sich auf Satelliten in niedriger Erdumlaufbahn wie die ISS anwenden, um mit Modellen wie SGP4 Position und Geschwindigkeit zu berechnen.
    • Die Anmerkung folgt, dass die Höhe von GSOs (geostationären Satelliten) fast genau mit der Obergrenze von LOC-Records übereinstimmt.
  • Es wird argumentiert, dass neben hartkodierten Caches auch die TTL-Werte der DNS-Infrastruktur selbst beim Caching helfen sollten, insbesondere angesichts großer öffentlicher DNS-Resolver wie Cloudflare 1.1.1.1 und Google 8.8.8.8. DNS wird als global konsistent funktionierende Datenbank beschrieben, geeignet für temporäre Datenspeicherung und als naives Protokoll, das sich leicht durch Firewalls schleusen lässt, auch wenn es in der Praxis oft abgefangen wird.
  • Eine weitere Ressource namens OpenNotify wird vorgestellt, wenn auch mit eingeschränktem Funktionsumfang und weniger Glanz.
    http://open-notify.org/
  • Es wird auf ausführliche Informationen zu DNS-LOC-Records hingewiesen.
    https://www.ckdhr.com/dns-loc/
  • Beim Blick in das RFC wird angemerkt, dass dort nicht erklärt werde, warum diese Funktion überhaupt nötig war; vermutet wird ein Zusammenhang mit Hochschulen oder der Logistik von Rechenzentren im Jahr 1996.
    • Abschnitt 5.1 des RFC (Suggested Uses) deute zumindest vage mögliche Anwendungen an, etwa Karten für den Fluss des USENET-Backbones, visuelle traceroute-Apps zur Darstellung geografischer Wege von IP-Paketen oder Netzwerkmanagement-Apps zur Erstellung von Host- und Router-Karten.
    • In RFCs werde das zu lösende Problem oft nicht klar definiert; außerdem die Meinung, dass beim LOC-Record statt Koordinaten eigentlich auch eine menschenlesbare Adresszeichenfolge ausgereicht hätte.
  • DNS wird zusammenfassend als föderierter, leseoptimierter, geografisch replizierter Key-Value-Store mit eventual consistency beschrieben.