New netblock Geolocate wrong (Google)
richard.barnes at gmail.com
Tue Jan 19 12:29:04 UTC 2010
Just to be fair here, I appreciate that there's some additional
complexity here (not much -- I implemented a client for this yesterday
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
On Tue, Jan 19, 2010 at 7:23 AM, Randy Bush <randy at 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.
>> 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  where
>> an interested client can ask for the location of a specific IP address
>> . (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,
> 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.
More information about the NANOG