I don't believe anyone is actually using the LOC RR, but maybe I'm wrong. This seems like the best way to store this type of data. I could see CDNs being able to leverage this along with edns-client-subnet to decrease page load times significantly. How is this still an issue? I mean, we have the means to fix this. Whoever a reverse zone is delegated to could easily update the LOC record to provide this info. They can make the LOC record as "fuzzy" as they feel comfortable by zeroing out the minutes and seconds, as the LOC record is just a set of GPS coordinates. Who better to report the physical location of a network than that network's operators. I think country code would be a nice addition to the LOC record though. Sincerely, Clay Curtis On Fri, Sep 25, 2015 at 6:36 AM, Stephen Satchell <list@satchell.net> wrote:
https://tools.ietf.org/html/rfc1876 (EXPERIMENTAL)
There appears to be a way of associating a subnet in the IN-ADDR.ARPA domain to a FQDN, which could then be queries for LOC data. For single addresses, the domain owner could opt to include location data for their domain. For subnets, the operator can include location data at their option.
Also, I would add one more field to the LOC RR: country code. This would be a two-byte value that is the standard two character ASCII country code. When missing, a value of binary zero would be returned on query.