Get the location of the ISS using DNS (shkspr.mobi)

Brilliant! This is both clever and educational. I immediately wondered if it would be possible to do something similar for JWST.

Unfortunately LOC DNS records top out at ~42 million meters (42,000 km altitude) and JWST is 38x further out (~1.5 million km away). So you can’t represent its location with a LOC altitude field. Maybe Hubble?

Considering the ISS orbits in ~90 minutes, the 15 minute TTL is quite a long time.

I understand there are API limitations, but isn't 15 minutes a lot for an object that orbits around the entire Earth in 90 minutes? On average you're going to be off by about a twelfth of the circumference of the Earth, or roughly the distance between Lisbon and Istanbul

It's just an API that utilizes DNS, not that interesting imo.

Looking at the RFC it's never explained why this is needed. Or was needed back in 1996, perhaps something to go with universities and data center logistics back then?

[flagged]

Could you calculate the position from the Ephemeris data in realtime instead of using an API? This would allow you to return the current location on every request potentially.

Is there any service on the ISS that the public can interact with? Maybe you could use response times to figure out where it is that way.

Another record, Name Authority Pointer (NAPTR), has the telephone number of the 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

"~instantly! (...) every 15 minutes" - omg

I read the opening sentence as "I love DNS erotica" which indicates I've been inside too long and should go for a walk.

More about DNS LOC records: <https://www.ckdhr.com/dns-loc/>

This is quite cool! I just added this to dns.toys [1]

  dig iss.sky +short @dns.toys

[1] https://dns.toys

Great post, definitely something I can setup on my personal recursive DNS resolver. Yet another toy I can throw on to my rpi :)

[flagged]

TLDR; use an API

DNS is a federated, read-optimized, geo-replicated key-value store with eventual consistency.

OpenNotify is another (more limited, less fancy) resource: http://open-notify.org/

"dig" is the new "finger"

Besides the hard-coded cache, shouldn't DNS infrastructure already help with the caching just by the TTL value itself? Given quite many & large public DNS resolvers out there, like Cloudflare's 1.1.1.1 and Google's 8.8.8.8

I overall like the DNS, it is a global database with eventual consistency. Possible to store transient data. Usually not blocked by firewalls just by the sheer innocent nature. (Although gets intercepted quite a lot...)

> RFC 1876 is an experimental standard.

That has been a very long running experiment [1]:

> University of Warwick, January 1996

[1] https://datatracker.ietf.org/doc/html/rfc1876

A slightly more complex, but much more responsive way would be to set an NS record of `where-is-the-iss.shkspr.mobi` that points to the IP of your VPS.

Then run a program that listens to UDP/53 and TCP/53. Have it respond with a DNS packet that's only dynamic in the LOC record and message ID. Not fully compliant with the DNS spec, but good enough for this use case.

You could cache API response to combat rate limiting.

Remember, kids, you can only measure either the location, or the spin. If you do both, the ghost of Werner Heisenberg will come to haunt you.