It seems odd to me that someone back in '96 went to the hassle of implementing DNS LOC but didn't explicitly specify which reference ellipsoid should be used. Nor does the protocol provide a mechanism, on a per-record basis, to specify which ellipsoid has actually been used.
RFC1876 says WGS84 in several places, including one of the parts quoted in the Cloudflare article. I don't spot an explicit statement that lat/lon are WGS84 (only altitude, p. 3), but it's the only datum mentioned and assuming that alt is WGS84 and lat/lon something else seems perverse.
I'm really surprised that LOC records aren't being more heavily used. If you need to publicly publish position data, DNS gives you a worldwide distribution method.
The .tel TLD was established for the purpose of publishing contact/location and other meta info at the DNS level, but it hasn't yet caught on unfortunately.
The lack of success of .tel is largely because Telnic has implemented the TLD in such a way that it can only be used to publish contact information - every .tel domain must have its nameservers set to Telnic's DNS servers, which in turn will only serve records pointing to Telnic's web servers, which will only serve pages listing contact information.
You're right, but had it not been so restrictive would people have used it for its core purpose? There are a bunch of other reasons it hasn't caught on. But at this stage I think their best move would be to ask ICANN whether they can liberalise the extension.. I imagine the community would back it.
Should we interpret this as meaning that RRDNS never correctly served LOC records? They did most of the work to implement this and then didn't test it at all?
My guess is they didn't test correctly. They likely set up their tests to check that the string being returned was the same as the string that was stored without realizing that the value served was supposed to be transformed.
