where-is-the-iss.dedyn.io no es un sitio web, sino un experimento juguetón que devuelve la ubicación aproximada de la Estación Espacial Internacional (ISS) usando solo un registro DNS LOC- DNS LOC es un estándar experimental de la RFC 1876 que puede almacenar no solo latitud y longitud, sino también altitud en un registro de dominio
- El rango de altitud de un registro LOC va de -100,000 m a 42,849,672 m, por lo que puede representar desde instalaciones subterráneas hasta satélites en órbita geoestacionaria
- Las coordenadas de la ISS se obtienen desde la API de N2YO y, para ajustarlas al formato LOC, la altitud debe convertirse de km a m y la latitud/longitud deben transformarse a formato de grados, minutos y segundos
- Los registros se actualizan con la API de deSEC y un TTL de 900 segundos, reflejando la posición más reciente cada 15 minutos en modo de mejor esfuerzo (best-effort)
Guardar una ubicación en un registro DNS LOC
- Un nombre de dominio normalmente apunta a un servidor, pero un servidor al final también es un equipo con una ubicación física dentro de un centro de datos
- Un registro DNS LOC es un registro DNS que puede guardar latitud, longitud y altitud para un dominio
- RFC 1876 es el estándar experimental que define el registro LOC
- Un centro de datos puede estar en un edificio alto o bajo tierra, por eso también incluye el parámetro de altitud
- La altitud mínima es de -100,000 m
- La altitud máxima es de 42,849,672 m, un rango que también sirve para satélites en órbita geoestacionaria
where-is-the-iss.dedyn.io
where-is-the-iss.dedyn.io es un dominio creado para obtener la ubicación aproximada de la ISS mediante una consulta DNS- Este dominio no es un sitio web, no se puede hacer ping y no ofrece otra forma de interacción fuera de DNS
- Los usuarios de Linux y Mac pueden consultar el registro LOC con el siguiente comando
dig where-is-the-iss.dedyn.io LOC
- La respuesta devuelve la latitud, longitud y altitud de la ISS en formato 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
- El registro DNS se actualiza cada 15 minutos en modo de mejor esfuerzo
- En Windows PowerShell o Command Prompt parece difícil encontrar una forma de consultar registros LOC
Obtener los datos de ubicación
- N2YO ofrece un sitio web para rastrear varios objetos en órbita y una API con una capa gratuita bastante generosa
- La ISS se consulta en la API de N2YO con el ID de satélite 25544
- La respuesta de la API incluye campos como
satlatitude, satlongitude, sataltitude, timestamp y 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
}
]
}
- La altitud en la respuesta de N2YO está en km, pero el formato LOC requiere metros
- Como la latitud y la longitud vienen en decimal, hay que convertirlas al formato grados, minutos y segundos (Degrees, Minutes, Seconds) para guardarlas en el registro LOC
Actualizar el registro LOC con deSEC
- No había muchos proveedores gratuitos de nombres de dominio que ofrecieran una API para actualizar registros LOC, así que se eligió deSEC, una organización benéfica de Berlín
- deSEC ofrece documentación de API
- El registro LOC inicial se agrega con
curl al 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}'
- Actualizar el registro es un poco más complicado: hay que enviar un HTTP PATCH a otra URL
- En la solicitud PATCH solo hace falta incluir los datos que cambiaron
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"]}'
Intervalo de actualización y limitaciones
- El TTL está configurado en 900 segundos
- El código se ejecuta cada 15 minutos para actualizar el registro DNS
- Ese intervalo permite mantenerse dentro de los límites de API tanto de N2YO como de deSEC
- También se podría usar un registro TXT para guardar la hora de la última actualización u otros datos no estructurados, pero para esta demo se considera suficiente como una prueba de concepto rápida
- Al distribuir datos en un registro DNS TXT, incluso podría usarse como una API con prácticamente ningún límite de solicitudes, algo más apropiado para datos estáticos o que cambian poco
Datos curiosos que se pueden guardar en DNS
- Esta demo muestra, de una manera compleja y juguetona, que DNS puede guardar registros menos esperados
- Así como las coordenadas de la ISS se expresaron en un registro LOC, también da pie a imaginar cómo se podrían representar las coordenadas de un Mars Rover
- Algunos textos relacionados sobre DNS son BIMI - SVG in DNS TXT WTF?! y Why you can't dig Switzerland
1 comentarios
Opiniones en Hacker News
Otro registro, el Puntero de autoridad de nombres (NAPTR), contiene el número telefónico del Johnson Space Center en Houston
Al verlo con
dig where-is-the-iss.dedyn.io NAPTR, aparecenE2U+voice:telytel:+12814830123Entiendo las limitaciones de la API, pero un ciclo de actualización de 15 minutos parece bastante largo para un objeto que da una vuelta a la Tierra en 90 minutos
En promedio, la posición podría desviarse alrededor de 1/12 de la circunferencia de la Tierra, más o menos la distancia entre Lisboa y Estambul
Si alguien conoce una forma de actualizar DNS gratis con actualizaciones por minuto, con gusto me cambiaría
Sin duda es un error grande para rastreo de posición preciso
Leí la primera frase como “I love DNS erotica”, y parece una señal de que llevo demasiado tiempo encerrado y debería salir a caminar
Ahora voy a salir a caminar
Creo que también necesito una ducha fría
Bastante genial. Acabo de agregarlo también a dns.toys
dig iss.sky +short @dns.toys[1] https://dns.toys
Excelente. Ingenioso y educativo. De inmediato me pregunté si se podría hacer algo parecido con el JWST
Lamentablemente, el registro DNS LOC tiene un límite de unos 42 millones de metros, es decir, una altitud de alrededor de 42,000 km, mientras que el JWST está a unos 1.5 millones de km, unas 38 veces más lejos
Por eso no se puede representar su posición con el campo de altitud de LOC. Quizá con el Hubble sí se pueda
Es parecido a preguntar por las coordenadas GPS de la Luna. La NASA probó en 2023 recibir señales GPS débiles en la Luna con el LRO, pero todavía no es útil para navegación
La razón por la que este método tiene sentido para la ISS es que existe un punto subsatelital sobre la superficie terrestre. Puede recibir señales GPS sin importar la altitud
Además, los TLE aplican a la ISS como objeto en órbita terrestre. Los TLE están diseñados para definir la posición y velocidad de satélites en órbita terrestre mediante elementos orbitales, y para que modelos como SGP4 los interpreten
“RFC 1876 es un estándar experimental”; vaya experimento tan duradero
University of Warwick, January 1996
[1] https://datatracker.ietf.org/doc/html/rfc1876
Material adicional sobre los registros DNS LOC: <https://www.ckdhr.com/dns-loc/>
Una forma un poco más compleja, pero mucho más reactiva, sería apuntar el registro NS de
where-is-the-iss.shkspr.mobia la IP de tu propio VPSLuego ejecutas un programa que escuche en UDP/53 y TCP/53, y haces que responda paquetes DNS donde solo cambien dinámicamente el registro LOC y el ID del mensaje
No cumpliría por completo la especificación de DNS, pero sería suficiente para este uso. La respuesta de la API se puede cachear para evitar los límites de llamadas
Yo opero un servicio así, y puedes probarlo con
2+2.op.dyn.bortzmeyer.fr/TXToparis.now.weather.dyn.bortzmeyer.fr/TXTDNS es un almacén clave-valor federado, optimizado para lectura, con replicación geográfica y consistencia eventual
Incluso leyendo el RFC, no explica por qué hacía falta esto
Me pregunto si en 1996 habría alguna razón relacionada con la logística de universidades o centros de datos
Dice que el LOC RR puede usarse para mapas de flujo del backbone de USENET, un “traceroute visual” que muestre la ruta geográfica de paquetes IP, apps de administración de red que generen mapas de hosts y routers administrados, etc.
Tampoco hay motivo para que esto no pudiera ser una cadena legible por humanos como “42 Wallaby Way, Sidney”