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.
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
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
You will find that it takes years before every site out there updated their
copy of whatever geo database they are using.
Regards
Baldur
With a new block it took less than a week.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
How is knowing the physical location going to decrease page load times?
Hint: I live all of 3 miles from my office. But home is deep in Comcast
cable territory, while office is hanging off connections to Ashburn and
Atlanta. So from home to office, packets have to go 400 miles north or south,
then back. If Akamai decided to serve me a page at home out of the Akamai
servers at work because it's only 3 miles away, it just added 25ms to each
RTT it has to take.
Which is why Akamai (and any other *sane* CDN) make their decisions based
on network topology, not physical location....
You're example is one specific case. I'm not advocating that it works in
every case, or that geo-location should be used in routing decisions
exclusively. I have dealt with cases in which a CDN responded to a client
request with a resource on another continent, thus having to cross an ocean
and adding considerable latency, when there was a POP on that continent.
If the CDN could have LOC information that is more accurate/updated, it
could allow them to make a better decision and direct a client to a
resource that is physically closer. It's another piece of information.
Clearly Maxmind or whatever other current means there are to determine
physical location are not ideal.
Clay
exclusively. I have dealt with cases in which a CDN responded to a client
request with a resource on another continent, thus having to cross an ocean
and adding considerable latency, when there was a POP on that continent.
And what was the root cause for the CDN to misfire that badly?
I hereby submit the hypothesis that if a CDN's data tables are so dorked up
that they're serving the data from the wrong continent, adding physical
location probably won't help, and may make things even worse. (For instance,
consider a location in Alaska, where the *closest* CDN may be one in the
northwest part of Canada - specifically put there because the network is at the
wrong end of a satellite link. You almost certainly want to skip that one and
hit one in Seattle or someplace similar....)
If the CDN could have LOC information that is more accurate/updated, it could
allow them to make a better decision and direct a client to a resource that is
physically closer.
You don't want the one that's physically closest. You want the one that's
netwise closest.
Our original /22 block from RIPE has never had any geo IP issues. Everyone
seems to recognize the country correctly from day 1.
However our transferred blocks from Romania are still have issues a year
later. Every geo IP database knows the correct location. But nothing forces
customers of the database to actually keep their copy updated. So we keep
getting complaints that this or that site is reporting the wrong country.
Some of those sites are big sites that should know better.
It is impossible to hunt down every single e-commerce site out there and
force them to update their geo IP database. A lot of them have no clue what
you are talking about. They either bought a hosted solution, and the tech
guy you really want to talk to is somewhere else. Or they used contractors
to build the system and now it is on auto pilot. Or you simply can't get
through customer support to the tech people that know what geo IP actually
is.
At the end of the day, you are not going to waste too much time trying to
beat clue into the heads of people running some niche site specialising in
selling pink shoes, that refused to take the order from one customer
because their brain dead e-commerce solution believes the customer is
located in the wrong country.
Regards,
Baldur