I don't believe anyone is either. We looked at it as well and after reviewing logs from our authoritative DNS server responsible for our in-addr.arpa zones, we saw zero queries for LOC records.
Ray On Fri, Sep 25, 2015 at 10:43:13AM -0400, Clay Curtis wrote: > 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 <l...@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. > > > > >
