Toward faster international server selection using clever DNS.

[Roedy Green]

When you type google.com you get sent to google.ca if you live in
Canada. I presume this works by your request going to google.com in
the USA, where it then figures out you are from Canada and sends back
a redirect, then you resend your request to google.ca a server in
Canada. Is that correct?

blogger.com (owned by google) has just started doing this variable
suffix thing too. All kinds of large companies use this sort of
logic. Sometimes you must manually select your region. It strikes me
as inefficient. If the head office is in Taiwan, it is quite slow
(e.g. motherboard manufacturers).

What should happen is the DNS routers in Canada should direct
google.global requests to google.ca. and in the USA to google.com.
You should be able to bypass the country server selector with a
specific google.ca request.

Does it actually work roughly this way already? if not, why? It is
just the inertia holding back extending DNS software in all the
world's servers?

If it does not work this way, or when the server uses the redirect
method, it suggests I can be kind to my clients in my JSP (the Java
topic tie) by localising links to global enterprises in the generated
HTML so they go directly.

For example, on every page in the Java glossary is a link to google
that lets you find more information about the topic of the page. This
link could be localised if I were using JSP to dynamically generate
the page.

 

[Jeff Higgins]

When you type google.com you get sent to google.ca if you live in
Canada. I presume this works by your request going to google.com in
the USA, where it then figures out you are from Canada and sends back
a redirect, then you resend your request to google.ca a server in
Canada. Is that correct?

blogger.com (owned by google) has just started doing this variable
suffix thing too. All kinds of large companies use this sort of
logic. Sometimes you must manually select your region. It strikes me
as inefficient. If the head office is in Taiwan, it is quite slow
(e.g. motherboard manufacturers).

What should happen is the DNS routers in Canada should direct
google.global requests to google.ca. and in the USA to google.com.
You should be able to bypass the country server selector with a
specific google.ca request.

Does it actually work roughly this way already? if not, why? It is
just the inertia holding back extending DNS software in all the
world's servers?

<http://www.zytrax.com/books/dns/>

 

[Roedy Green]

For example, on every page in the Java glossary is a link to google
that lets you find more information about the topic of the page. This
link could be localised if I were using JSP to dynamically generate
the page.

I have developed this idea further at
http://mindprod.com/project/routing.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
It is almost impossible to keep things in synch manually. Instead:
-Keep each fact in only one central database (not necessarily SQL),
and access it as needed. Since there is only one copy of each fact,
there is nothing to get out of synch.
-Use some automated tool so that if you change a fact is one place,
it automatically updates the others.
-Write a sanity checker you run periodically to ensure all is consistent.
This is the strategy compilers use.
-Document the procedures needed to keep all in synch if you change
something and rigidly and mechanically follow them.

 

[Joshua Cranmer]

When you type google.com you get sent to google.ca if you live in
Canada. I presume this works by your request going to google.com in
the USA, where it then figures out you are from Canada and sends back
a redirect, then you resend your request to google.ca a server in
Canada. Is that correct?

No. Most servers probably do the global domain name switching via a
vhost-based similar on their webservers; they otherwise go to the same
computer(s). The point of server selection is to do appropriate
regionalization based on the user's preferences, which often has nothing
to do with the physical location of a user.

What should happen is the DNS routers in Canada should direct
google.global requests to google.ca. and in the USA to google.com.
You should be able to bypass the country server selector with a
specific google.ca request.

Note that people already use DNS to point you to the closest physical
servers you have access to, along with load balancing tricks. Basically,
the problem you are trying to solve is already more or less solved.

 

[Roedy Green]

Note that people already use DNS to point you to the closest physical
servers you have access to, along with load balancing tricks. Basically,
the problem you are trying to solve is already more or less solved.

Oddly though, Google does not do this. I watched it with Wireshark.
So there still might be value is localising Google links in your JSP.
--
Roedy Green Canadian Mind Products
http://mindprod.com
It is almost impossible to keep things in synch manually. Instead:
-Keep each fact in only one central database (not necessarily SQL),
and access it as needed. Since there is only one copy of each fact,
there is nothing to get out of synch.
-Use some automated tool so that if you change a fact is one place,
it automatically updates the others.
-Write a sanity checker you run periodically to ensure all is consistent.
This is the strategy compilers use.
-Document the procedures needed to keep all in synch if you change
something and rigidly and mechanically follow them.

 

[Joshua Cranmer]

Oddly though, Google does not do this. I watched it with Wireshark.
So there still might be value is localising Google links in your JSP.

What do you mean by this? If, for example, I do a traceroute to
google.co.at and another to google.com, the route is exactly the same
except for the final server. Judging from whois data, the servers for
both domains are located in Wisconsin, whereas the host computer I
queried from is in Illinois. Given the politics of how ISPs connect to
each other, this is not an unreasonable result (the traffic is forwarded
via what appear to be primarily academic transit links, so I presume
that the amount of money that changes hands for the bandwidth in
question is exactly $0).

Repeating a traceroute from a computer located in another state for the
same domain name produced a different IP address, accessed via a
different set of intermediate hops. I can't map these to physical server
locations, but knowing a little about ISP infrastructures, I suspect
that the server is likely within 20 miles of my location (I happen to be
geographically close to a cluster of major internet exchanges--over half
of the DNS root nameservers have a home in the area).

 

[RedGrittyBrick]

Oddly though, Google does not do this. I watched it with Wireshark.
So there still might be value is localising Google links in your JSP.

I'm not sure how Roedy's idea is an improvement over what firms like
Akamai have been doing for nearly fifteen years?

http://en.wikipedia.org/wiki/Akamai_Technologies#Content_delivery_to_a_user

 

[Arne Vajhøj]

I have developed this idea further at
http://mindprod.com/project/routing.html

You are mixing up two problems:
1) delivering localized content
2) route traffic to server that is close network wise

Problem #1 has standard solutions in most web technologies.

Problem #2 was solved in 1998 by Akamai (they do not use a
special domain just the company's main domain).

Arne