Domain names, like www.example.com usually resolve to servers. As much as we think of "the cloud" as being some intangible morass of ethereal Turing-machines floating in probability space, the more prosaic reality is that they're just boxen in data centres. They have a physical location.

Got a tricky machine which is playing silly-buggers? Wouldn't it be nice to know exactly where it is? That way you can visit and give it some percussive maintenance.

Enter the DNS LOC record!

The snappily titled RFC 1876 is an experimental standard. It allows you to create a DNS record which specifies the latitude and longitude of your server. Of course, some data-centres are very tall and some are underground. So it also contains an altitude parameter.

The standard allows for a minimum altitude of -100,000 metres - deep enough for any bunker! The maximum altitude is 42,849,672 metres which is high enough to allow it to be used on satellites in geostationary orbit.

So, as a bit of fun, I decided to create where-is-the-iss.dedyn.io

It isn't a website. You can't ping it. There's no way to interact with it except by using DNS. Yup! You can use a DNS query to get the (approximate) location of the International Space Station!

Linux and Mac users⁰ can run:

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

And receive back the latest position of the ISS:

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

The DNS records are updated every 15 minutes on a best-effort basis¹.

How

The lovely people at N2YO have a website which allows you to track loads of objects in orbit. They also have an easy to use API with a generous free tier.

Calling https://api.n2yo.com/rest/v1/satellite/positions/25544/0/0/0/1/&apiKey=_____ gets back the latest position:

{
    "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
        }
    ]
}

Note that the altitude is in Km, whereas the LOC format requires m.

The latitude and longitude are in decimal format - they need to be converted to Degrees, Minutes, and Seconds.

There were only a few free domain name providers who offer an API for updating LOC records. I went for deSEC a charity from Berlin. They have comprehensive API documentation.

Adding the initial LOC record is done with:

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}'

However, updating the record is a little trickier. it needs to be sent as an HTTP PATCH to a subtly different URl. The PATCH only needs to send the data which have changed.

curl -X PATCH https://desec.io/api/v1/domains/where-is-the-iss.dedyn.io/rrsets/@/LOC/ \
    --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"]}'

I set the Time To Live at 900 seconds. Every 15 minutes my code runs to update the record². That keeps me well within the API limits for both services. I could add TXT records showing when it was last updated, or other sorts of unstructured data, but I think this is enough for a quick proof-of-concept.

There you have it! A complex and silly way to demonstrate how DNS can be used to hold the most unlikely of records³. Say, I wonder how you'd represent the co-ordinates of the Mars Rover…?

Further Reading

For more DNS weirdness, please see my other posts:

• BIMI - SVG in DNS TXT WTF?!
• Why you can't dig Switzerland

The humble unix dig command allows you to query all sort of DNS information. For example, to see name server records for the BBC website, you can run:

dig bbc.co.uk NS

Which will get you:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35614
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 17

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 097db2ee4c92b84982083ecf62b5b5f2007906e616035113 (good)
;; QUESTION SECTION:
;bbc.co.uk.         IN  NS

;; ANSWER SECTION:
bbc.co.uk.      900 IN  NS  ddns1.bbc.com.
bbc.co.uk.      900 IN  NS  dns0.bbc.co.uk.
bbc.co.uk.      900 IN  NS  ddns1.bbc.co.uk.
...

And a whole lot more. But you can go further down the DNS tree. What are the nameservers for .co.uk?

dig co.uk NS

And you'll get your answer. You can go one further and see the nameservers for the Top Level Domain:

dig uk NS

Which replies with:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54061
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 17

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 880427eda8ff71de2ab4f43862b5b65f95e317d29cc10a8e (good)
;; QUESTION SECTION:
;uk.                IN  NS

;; ANSWER SECTION:
uk.         159692  IN  NS  nsc.nic.uk.
uk.         159692  IN  NS  dns1.nic.uk.
uk.         159692  IN  NS  nsd.nic.uk.
...

And that works with every TLD. Countries like de, generic names like museum, and internationalised domains like 在线. All of them work!

Except Switzerland.

Switzerland's country code is ch - after the name Confoederatio Helvetica. Let's run the dig on it: dig ch NS

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31910
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

We have been refused and warned. But why does this only happen with Switzerland?

The blame - as with most modern ills - lies in the mid-1970s. The Bee Gees were storming the charts with "Jive Talkin'", the Rocky Horror Picture Show was gathering a cult following, and MIT scientists were causing chaos. Literally.

Chaosnet was an early network protocol designed for local networks. It was technically very clever but, sadly, never really took off.

However, it found its way into DNS records. Let's go back to the answer to dig bbc.co.uk NS:

;; ANSWER SECTION:
bbc.co.uk.      900 IN  NS  ddns1.bbc.com.

OK, the first part is the domain name. The number is the TTL. The IN is the class. The NS says this is a nameserver record. And, finally, we get the domain of the nameserver.

But, in the class, what does IN stand for?

"Internet", obviously. Wait... Isn't the DNS on the Internet? Why do we need to specify that these DNS records are for Internet?

Well, isn't it obvious? Because you might want records of a different network. Like, for example, Chaosnet.

And if Internet is abbreviated to IN, what is Chaosnet shortened to? That's right! CH.

So, dig sees you enter ch for Switzerland, but thinks you're asking about CH for Chaosnet. And so it fails.

In order to query the records for ch we need to provide an absolutely fully-qualified domain name. It's as simple as sticking a dot at the end of the domain name:

dig ch. NS

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64932
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 11

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e19b9c23cdfa0f7bcf82750462b5c16b47744386c7974ffb (good)
;; QUESTION SECTION:
;ch.                IN  NS

;; ANSWER SECTION:
ch.         164894  IN  NS  e.nic.ch.
ch.         164894  IN  NS  a.nic.ch.
ch.         164894  IN  NS  f.nic.ch.

And there we go. A failed 1970s experiment like bell-bottoms and Betamax videos - but with much longer lasting consequences.

You can see some CH records by running like:

dig ch txt @f.root-servers.net version.bind

That will get you something like:

;; ANSWER SECTION:
version.bind.       86400   CH  TXT "cloudflare-f-root-20190930"

Of course, DNS doesn't only have IN and CH class records.

There's also Hesiod - HS. But you already knew that, right...?