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

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

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

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

  dig iss.sky +short @dns.toys

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?

> 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.

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

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

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...)