Just to be fair here, I appreciate that there's some additional complexity here (not much -- I implemented a client for this yesterday in ~80 lines of Javascript), but LOC records don't cover everything. They're fine for stationary stuff, but not so great for anything that moves with any frequency (unless you're willing to make the DNS really dynamic). --Richard On Tue, Jan 19, 2010 at 7:23 AM, Randy Bush <randy@psg.com> wrote:
Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like.
yes!
FWIW, there has been some work in the IETF on creating protocols to allow pretty rich location information to be published in reverse DNS. Basically, you publish a NAPTR pointer to a location server [1] where an interested client can ask for the location of a specific IP address [2][3]. (Publishing location in this way is a requirement in several systems for VoIP 9-1-1 around the world to allow first responders to ask networks for location. See for example the NENA i3 architecture in the US and a similar "Canadian i2" for Canada.)
The location representation these protocols use is a profile of the Geospatial Markup Language, so you can represent anything from a simple point to full GIS-like layers; you can also represent civic addresses (i.e., postal addresses) directly.
surely, with its vast talents, the ietf can make this more complex.
after all, look at the inflate-and-embellish stupidity that made the simple idea of bgp communities for data collecion, completely ueless, draft-meyer-collection-communities-00.txt
</sarcasm>
i just wanna deal with a cidr block for stupid simple thing, not boil the ocean. and we have LOC RRs. no brilliance or inventiveness needed.
randy