Back in 2014 when I wrote this I said "CloudFlare handles millions of DNS records; of those just 743 are LOCs." I asked the team for an update and that number is now... 3,198.
A friend of mine passed away last year and I use a domain named after her as a small memorial, sally.pro. I just gave it a LOC record pointing to a bench in the park that we adopted for her.
Because people tend to have fallible memories whereas GPS is reasonably accurate.
If you've walked a costal path and taken a dozen photos, are you really going to remember where each one was?
Every phone for the last decade has geotagging built in to its camera app. Relying on EXIF is the easiest way for us to ensure the map is broadly accurate.
> Because people tend to have fallible memories whereas GPS is reasonably accurate.
GPS locations are simple to look up on, for example, Google Maps--I just click my mouse at the place where I know the bench I took a picture of is located. My memory of where it is is not at all fallible since it's a memorial bench for my parents just down the street from the house where they used to live. I could easily enter the GPS coordinates from Google Maps into your site if your site would allow me to.
> If you've walked a costal path and taken a dozen photos, are you really going to remember where each one was?
But your site is not for uploading random photos people take on walks. It is for uploading pictures of memorial benches. The locations of those are much more likely to be remembered by the people who want to upload the pictures, accurately enough to get GPS coordinates in the way I described above.
> Every phone for the last decade has geotagging built in to its camera app.
I've only had my phone a few years and the photos I have of the bench I wanted to upload are not geotagged. I know that because your site told me so when I tried to upload them.
In particular, it solves the discovery issue discussed in RFC 9092 (https://www.rfc-editor.org/rfc/rfc9092), allows real-time updates, and would make it easier for ISPs to delegate maintenance of geolocation records to customers.
I'd imagine that there are some sharp edge cases where a nearby straight-line distance is a suboptimal choice due to peculiarities of submarine cables or irregular point to point links of some other sort.
I put a LOC record on cam.ac.uk set to 10km in diameter, so it basically covers the official precincts of the university which require that students live within 3 miles of the centre of the city.
One of many strange features in DNS. I seem to recall a talk a few years ago where someone enumerated a variety of weird DNS capabilities and some interesting security consequences, but I don't remember the name of the talk or the speaker. Does anyone happen to know what I'm half-remembering?
This is interesting, but can anyone give me an example of using this for beyond just a simple easter egg? Presumably this had some real use to be added to the DNS spec.
Seems like a reasonable way to track the locations of named items; especially if the location of the items is public and amenable to caching. Especially if you assume network clients are capable of general networking, and not limited to typical browser stuff. May also need to assume typical recursive DNS servers won't mess up your lookups, because that's not always a reasonable assumption anymore.
For something modern like tracking a private fleet or your friends, you'd need to overlay access control or something. Something like how e164.arpa was conceptually going to be public, but ended up behind private networks so access control and cost accounting could be added.
DNS can contain all sorts of records that, at some point, someone thought was worth standardising.
In this case, I assume it used to be so common for a sub-domain to refer to a single physical box that there was utility in knowing exactly where in the world it was.
Possible use case from the RFC:
"Some uses for the LOC RR have already been suggested, including the
USENET backbone flow maps, a "visual traceroute" application showing
the geographical path of an IP packet, and network management
applications that could use LOC RRs to generate a map of hosts and
routers being managed."
There are plenty of track-side boxes in the rail industry which could benefit from this.
See also point-of-presence installations - if you have to drive 2 hours to flick a switch, it'd be nice to have the LOC properly configured for the dead box..
However having that data publicly visible might not be appreciated, and DNS might not be the best place to store the data compared with a normal instance of netbox etc with much finer grained access control.
I feel like you'd probably want some human review in there somewhere, otherwise that sounds ripe for abuse (and a subsequent headache that the OSM community probably doesn't want to deal with)
I don't think that exist, but you've nerdsniped me into trying to build it (or at least the collection side). Does anybody have better ideas than just trying a list of all known DNS names?
