where-is-the-iss.dedyn.io n’est pas un site web, mais une expérience ludique qui renvoie la position approximative de la Station spatiale internationale (ISS) uniquement via un enregistrement DNS LOC- DNS LOC est un standard expérimental défini par la RFC 1876, qui permet de stocker dans un enregistrement de domaine non seulement la latitude et la longitude, mais aussi l’altitude
- La plage d’altitude d’un enregistrement LOC va de -100 000 m à 42 849 672 m, ce qui permet de représenter aussi bien des installations souterraines que des satellites en orbite géostationnaire
- Les coordonnées de l’ISS proviennent de l’API N2YO ; pour les adapter au format LOC, l’altitude doit être convertie de km en m, et la latitude/longitude en degrés, minutes, secondes
- L’enregistrement est mis à jour via l’API deSEC avec un TTL fixé à 900 secondes, afin de refléter la position la plus récente toutes les 15 minutes, au mieux des possibilités (best-effort)
Stocker une position dans un enregistrement DNS LOC
- Un nom de domaine pointe généralement vers un serveur, mais un serveur reste au final une machine ayant une position physique dans un datacenter
- Un enregistrement DNS LOC est un enregistrement DNS qui permet de stocker latitude, longitude et altitude dans un domaine
- La RFC 1876 définit l’enregistrement LOC comme un standard expérimental
- Le paramètre d’altitude est inclus, car un datacenter peut se trouver dans un immeuble de grande hauteur ou en sous-sol
- L’altitude minimale est de -100 000 m
- L’altitude maximale est de 42 849 672 m, une plage utilisable même pour les satellites en orbite géostationnaire
where-is-the-iss.dedyn.io
where-is-the-iss.dedyn.io est un domaine créé pour obtenir la position approximative de l’ISS via une requête DNS- Ce domaine n’est pas un site web ; on ne peut pas non plus le pinguer, et il n’offre aucun mode d’interaction autre que DNS
- Les utilisateurs Linux et Mac peuvent interroger l’enregistrement LOC avec la commande suivante
dig where-is-the-iss.dedyn.io LOC
- La réponse renvoie la latitude, la longitude et l’altitude de l’ISS au format 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
- L’enregistrement DNS est mis à jour toutes les 15 minutes au mieux des possibilités
- Sous PowerShell ou Command Prompt de Windows, il semble difficile de trouver une méthode pour interroger les enregistrements LOC
Récupérer les données de position
- N2YO propose un site web permettant de suivre différents objets en orbite, ainsi qu’une API avec un niveau gratuit généreux
- L’ISS est consultée dans l’API N2YO avec l’ID de satellite 25544
- La réponse de l’API contient des champs comme
satlatitude, satlongitude, sataltitude, timestamp et 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
}
]
}
- L’altitude renvoyée par N2YO est en km, tandis que le format LOC exige des m
- Comme la latitude et la longitude arrivent en valeurs décimales, elles doivent être converties au format degrés, minutes, secondes (Degrees, Minutes, Seconds) pour être placées dans l’enregistrement LOC
Mettre à jour l’enregistrement LOC avec deSEC
- Peu de fournisseurs gratuits de noms de domaine proposaient une API de mise à jour des enregistrements LOC ; le choix s’est porté sur deSEC, une association caritative basée à Berlin
- deSEC fournit une documentation d’API
- L’enregistrement LOC initial est ajouté avec
curl via l’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}'
- La mise à jour de l’enregistrement est un peu plus délicate : il faut envoyer un HTTP PATCH vers une autre URL
- La requête PATCH n’a besoin de contenir que les données modifiées
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"]}'
Fréquence de mise à jour et limites
- Le TTL est fixé à 900 secondes
- Le code s’exécute toutes les 15 minutes pour mettre à jour l’enregistrement DNS
- Cette fréquence permet de rester dans les limites d’API de N2YO comme de deSEC
- Il serait aussi possible de placer l’heure de dernière mise à jour ou d’autres données non structurées dans un enregistrement TXT, mais pour cette démo, une preuve de concept rapide est considérée comme suffisante
- Distribuer des données dans des enregistrements DNS TXT peut aussi servir d’API pratiquement sans limite de requêtes, et convient davantage à des données statiques ou qui changent peu souvent
Des données inhabituelles dans DNS
- Cette démo est une manière complexe et ludique de montrer que DNS peut aussi contenir des enregistrements inattendus
- Comme les coordonnées de l’ISS sont représentées sous forme d’enregistrement LOC, on peut aussi imaginer comment représenter les coordonnées d’un Mars Rover
- Parmi les articles DNS liés, on trouve BIMI - SVG in DNS TXT WTF?! et Why you can't dig Switzerland
1 commentaires
Avis sur Hacker News
Un autre enregistrement, le Naming Authority Pointer (NAPTR), contient le numéro de téléphone du Johnson Space Center de Houston.
Avec
dig where-is-the-iss.dedyn.io NAPTR, on obtientE2U+voice:telettel:+12814830123.Je comprends les limites d’API, mais un intervalle de mise à jour de 15 minutes paraît assez long pour un objet qui fait le tour de la Terre en 90 minutes.
En moyenne, la position peut être décalée d’environ 1/12 de la circonférence terrestre, soit à peu près la distance entre Lisbonne et Istanbul.
Si quelqu’un connaît une méthode de mise à jour DNS gratuite permettant des mises à jour à la minute, je serais ravi de migrer.
Pour un suivi de position précis, c’est clairement une grosse erreur.
J’ai lu la première phrase comme “I love DNS erotica”, ce qui est sans doute le signe que je suis resté trop longtemps enfermé et que je devrais aller me promener.
Je vais maintenant aller me promener.
Une douche froide ne ferait sans doute pas de mal non plus.
Plutôt cool. Je viens aussi de l’ajouter à dns.toys.
dig iss.sky +short @dns.toys[1] https://dns.toys
Excellent. Astucieux et éducatif à la fois. Je me suis tout de suite demandé si on pouvait faire quelque chose de similaire avec le JWST.
Malheureusement, les enregistrements DNS LOC sont limités à environ 42 millions de mètres, soit autour de 42 000 km d’altitude, alors que le JWST se trouve environ 38 fois plus loin, à quelque 1,5 million de km.
Le champ d’altitude de LOC ne permet donc pas de représenter sa position. Pour Hubble, ce serait peut-être possible.
C’est un peu comme demander les coordonnées GPS de la Lune. La NASA a bien testé en 2023, avec LRO, la réception de faibles signaux GPS sur la Lune, mais ce n’est pas encore utile pour la navigation.
Si cette méthode convient à l’ISS, c’est parce qu’il existe un point subsatellite à la surface de la Terre. Elle peut recevoir des signaux GPS quelle que soit son altitude.
De plus, les TLE s’appliquent à l’ISS, qui est un objet en orbite terrestre. Les TLE sont conçus pour définir, sous forme d’éléments orbitaux, la position et la vitesse des satellites en orbite terrestre, que des modèles comme SGP4 interprètent ensuite.
“La RFC 1876 est une norme expérimentale” : voilà une expérience qui dure vraiment depuis longtemps.
University of Warwick, January 1996
[1] https://datatracker.ietf.org/doc/html/rfc1876
Ressource supplémentaire sur les enregistrements DNS LOC : <https://www.ckdhr.com/dns-loc/>
Une méthode un peu plus complexe, mais beaucoup plus réactive, consisterait à faire pointer l’enregistrement NS de
where-is-the-iss.shkspr.mobivers l’IP de son propre VPS.Ensuite, il suffit d’exécuter un programme qui écoute sur UDP/53 et TCP/53, et qui répond avec des paquets DNS où seuls l’enregistrement LOC et l’ID du message changent dynamiquement.
Ce ne serait pas totalement conforme à la spécification DNS, mais ce serait suffisant pour cet usage. Les réponses de l’API peuvent être mises en cache pour éviter les limites d’appels.
J’exploite moi-même un service de ce type, que l’on peut tester avec
2+2.op.dyn.bortzmeyer.fr/TXTouparis.now.weather.dyn.bortzmeyer.fr/TXT.DNS est un magasin clé-valeur fédéré, optimisé pour la lecture, géorépliqué et à cohérence éventuelle.
Même en lisant la RFC, on ne voit pas pourquoi cela était nécessaire.
Je me demande s’il y avait, en 1996, une raison liée à la logistique des universités ou des datacenters.
Elle dit que les LOC RR peuvent servir à des cartes de flux du backbone USENET, à un “traceroute visuel” montrant le chemin géographique des paquets IP, ou à des applications d’administration réseau générant des cartes des hôtes et routeurs gérés.
Il n’y a pas non plus de raison évidente pour que ce ne soit pas une chaîne lisible par un humain du type “42 Wallaby Way, Sidney”.