Why are there no GeoDNS solutions anywhere in sight?
Dear NANOG@, Not every operator has the ability to setup their own anycast. Not every operator is big enough to be paying 25 USD/month for a managed GeoDNS solution, just to get their hands on GeoDNS. (Hey, for 25$/mo, I might as well have an extra POP or two!) Why so many years after the concept has been introduced and has been found useful, can one not setup GeoDNS in under 5 minutes on one's own infrastructure, or use GeoDNS from any of the plentiful free or complementary DNS solutions that are offered by providers like he.net, xname.org, linode.com and others? I'm an NSD3 user and have a POP in Europe and NA, and, frankly, the easiest (and only) solution I see right now is, on both servers, running two copies of `nsd` on distinct sockets, and redirecting incoming DNS traffic through a firewall based on IPv4 /8 address allocation (RIPE and AfriNIC -- to an `nsd` instance with zone files with an `A` record of a POP in Europe; ARIN, APNIC, LACNIC and the rest of /8 allocations -- an `A` record for NA), with zone replication managed through git. Yeap, it's rough, and quite ugly, and unmaintainable, and will give optimal results only in 80 to 95 per cent of actual cases, and will not benefit from the extra webapp redundancy one otherwise might have had, but what other alternatives could be configured in 5 or 15 minutes? Any plans to make DNS itself GeoDNS-friendly? When editing a zone file in `emacs`, why can one not say that one has 3 web servers -- Europe, NA, Asia -- and have the dns infrastructure and/or the web-browser figure out the rest? Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy. It should be possible to say that you have a server in Fremont, CA and Toronto, ON or Beauharnois, QC, and automatically have all East Coast users go to Toronto, and West Coast to Fremont. Why is there no way to do any of this? Cheers, Constantine.
On Wed, Mar 20, 2013 at 08:28:23PM -0700, Constantine A. Murenin wrote:
Any plans to make DNS itself GeoDNS-friendly?
No. And I say this as someone working for a vendor that provides that service. Any sort of "Geo" DNS is what protocol people would call a "stupid DNS trick". It works in particular, narrowly-scoped ways because of the loose coherence of the DNS. But as a matter of protocol, you can't really standardize it, because it's actually taking advantage of certain flexibilities in the DNS and its interaction with the routing system. Turning that operational fact into a protocol feature would be a bad idea. A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
On 20 March 2013 20:43, Andrew Sullivan <asullivan@dyn.com> wrote:
On Wed, Mar 20, 2013 at 08:28:23PM -0700, Constantine A. Murenin wrote:
Any plans to make DNS itself GeoDNS-friendly?
No. And I say this as someone working for a vendor that provides that service.
Any sort of "Geo" DNS is what protocol people would call a "stupid DNS trick". It works in particular, narrowly-scoped ways because of the loose coherence of the DNS. But as a matter of protocol, you can't really standardize it, because it's actually taking advantage of certain flexibilities in the DNS and its interaction with the routing system. Turning that operational fact into a protocol feature would be a bad idea.
You are coming to this from the perspective of the existing conventions, and the current way that GeoDNS is done through a Split-Horizon DNS hack. But this is not what I want. What I want is an ability to specify multiple A and AAAA records, and their locations, and make it possible for the web-browser to automatically select the best location based on the presumed location of the user. Browsers might have a couple of rules, e.g. that Europe and parts of Asia are currently not directly connected to Asia, but NA is, and such rules would influence browser's decision to choose a Quebec server for a user in Japan, since it'll likely be much closer than the one in Moscow. Does it sound too complicated and pointy? Yes, it's not exactly trivial, and not as good as BGP, but better than having 300ms latency from a simple round-robin. C.
On Wed, Mar 20, 2013 at 11:55:41PM -0700, Constantine A. Murenin wrote:
On 20 March 2013 20:43, Andrew Sullivan <asullivan@dyn.com> wrote:
On Wed, Mar 20, 2013 at 08:28:23PM -0700, Constantine A. Murenin wrote:
Any plans to make DNS itself GeoDNS-friendly?
No. And I say this as someone working for a vendor that provides that service.
Any sort of "Geo" DNS is what protocol people would call a "stupid DNS trick". It works in particular, narrowly-scoped ways because of the loose coherence of the DNS. But as a matter of protocol, you can't really standardize it, because it's actually taking advantage of certain flexibilities in the DNS and its interaction with the routing system. Turning that operational fact into a protocol feature would be a bad idea.
You are coming to this from the perspective of the existing conventions, and the current way that GeoDNS is done through a Split-Horizon DNS hack.
But this is not what I want.
What I want is an ability to specify multiple A and AAAA records, and their locations, and make it possible for the web-browser to automatically select the best location based on the presumed location of the user. Browsers might have a couple of rules, e.g. that Europe and parts of Asia are currently not directly connected to Asia, but NA is, and such rules would influence browser's decision to choose a Quebec server for a user in Japan, since it'll likely be much closer than the one in Moscow.
Does it sound too complicated and pointy? Yes, it's not exactly trivial, and not as good as BGP, but better than having 300ms latency from a simple round-robin.
C.
peice of cake. add loc records to your rrset. /bill
bmanning@vacation.karoshi.com <bmanning@vacation.karoshi.com> wrote:
peice of cake. add loc records to your rrset.
You need something more sophisticated than that because for a single domain name you can't say which LOC records correspond to which address records. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
On 2013-03-21, at 02:55, Constantine A. Murenin <mureninc@gmail.com> wrote:
What I want is an ability to specify multiple A and AAAA records, and their locations, and make it possible for the web-browser to automatically select the best location based on the presumed location of the user.
I understand that you want a packaged solution in your authoritative DNS software, but with a little work you can get close without any knowledge of global topology or address distribution (i.e. no need for a geo-IP database). You need some unused address space to burn on anycast advertisements, though. Here's an approach using anycast DNS: $ORIGIN example.com. ... www CNAME www.geo.example.com. ... ; number any1 and any2 using addresses that ; are anycast between our service locations any1 A ... AAAA .... any2 A ... AAAA ... ... geo NS any1 NS any2 ; serve this version of geo.example.com ; in Asia on any1/any2, make www ; something sensible for Asian clients $ORIGIN geo.example.com. ... www A .... AAAA ... ; serve this version of geo.example.com ; in Europe on any1/any2, make www ; something sensible for European clients $ORIGIN geo.example.com. ...0 www A .... AAAA .... ; etc No reason that all the variants of the geo.example.com. zone can't be signed with the same keypair, and a suitable DS RRSet installed in example.com; this doesn't break DNSSEC. Two nameservers in the example above; this gives no site diversity for the geo.example.com zone but perhaps it's useful to incorporate server diversity within the site (if not, use one). You need to be able to advertise an anycast route to the world from each location, and you need spare numbers to be able to make those advertisements. For v4 that means an unpolluted /24; for v6 that probably means an unpolluted /56 or /48. Anycast of a single service is not a friend of efficient address utilisation. As with any other use of anycast, "European client" means "client whose path to any1/any2 lands in the European service location" and doesn't actually say anything about the location of the user. But if the selected exits along the path for some client land in Europe for resolving names in geo.example.com, maybe that's a good way to send the HTTP traffic. Another approach is to anycast the HTTP server serving www.example.com, and have that server return a 3xx redirect to www.asia.example.com or www.europe.example.com, which preserves the ability for the user of making a manual choice for one or the other at the expense of making your web people all flappy about the longer URL and the potential for particular content to be bookmarked with no future potential for geo-distribution. People get animated when you suggest you anycast a TCP service, but there is no shortage of examples of this working (and the redirect transaction is brief, which is generally nerve-settling). Lots of ways to skin this cat. Joe
On 3/21/13, Constantine A. Murenin <mureninc@gmail.com> wrote:
Does it sound too complicated and pointy? Yes, it's not exactly trivial, and not as good as BGP, but better than having 300ms latency from a simple round-robin.
It sounds like you are asking about Geolocation, when what you really want is latency-based selection. Latency is more complicated, and influenced by factors other than purely Geographic location. Furthermore, distance doesn't work all that well as a measure of latency: it only defines the latency, in the best case scenario for a link between the geo locations. Why not just have the browser send a SYN packet to every IP in the A/AAAA RRSET? Whichever webserver's response to the connection handshake is received first wins (lowest RTT latency); the other two or three connections are just dropped, so there is some minor waste, in exchange for picking the lowest RTT destination. Now another alternative would be for the local network operator to offer some sort of "latency lookup service"; Based on implementing packet inspection, and gathering statistical information RTT and average throughput and retransmit rates experienced during network users' TCP handshakes to remote prefixes, aggregated at an AS level. So the browser could query the latency lookup service for the hostname, and receive a DNS reply annotated with an estimated historical average latency, drop rate, throughput for the IP prefix inquired about. Or in fact... have the lookup service re-order or filter the query result, so the responses with higher than a certain cutoff latency are placed last in the response, or filtered/deleted from the response, when there are at least 3 better choices.
C. -- -JH
Constantine A. Murenin wrote:
Why so many years after the concept has been introduced and has been found useful, can one not setup GeoDNS in under 5 minutes on one's own infrastructure, or use GeoDNS from any of the plentiful free or complementary DNS solutions that are offered by providers like he.net, xname.org, linode.com and others?
Because we are mobile and want to use our IP addresses and domain names regardless of our current locations. Masataka Ohta
The first hit on Google for "dns geolocation" results in http://backreference.org/2010/02/01/geolocation-aware-dns-with-bind/, or the first hit for "dns geolocation patch" leads you to http://www.caraytech.com/geodns/ -----Original Message----- From: Constantine A. Murenin [mailto:mureninc@gmail.com] Sent: March-20-13 11:28 PM To: North American Network Operators' Group Subject: Why are there no GeoDNS solutions anywhere in sight? Dear NANOG@, Not every operator has the ability to setup their own anycast. Not every operator is big enough to be paying 25 USD/month for a managed GeoDNS solution, just to get their hands on GeoDNS. (Hey, for 25$/mo, I might as well have an extra POP or two!) Why so many years after the concept has been introduced and has been found useful, can one not setup GeoDNS in under 5 minutes on one's own infrastructure, or use GeoDNS from any of the plentiful free or complementary DNS solutions that are offered by providers like he.net, xname.org, linode.com and others? I'm an NSD3 user and have a POP in Europe and NA, and, frankly, the easiest (and only) solution I see right now is, on both servers, running two copies of `nsd` on distinct sockets, and redirecting incoming DNS traffic through a firewall based on IPv4 /8 address allocation (RIPE and AfriNIC -- to an `nsd` instance with zone files with an `A` record of a POP in Europe; ARIN, APNIC, LACNIC and the rest of /8 allocations -- an `A` record for NA), with zone replication managed through git. Yeap, it's rough, and quite ugly, and unmaintainable, and will give optimal results only in 80 to 95 per cent of actual cases, and will not benefit from the extra webapp redundancy one otherwise might have had, but what other alternatives could be configured in 5 or 15 minutes? Any plans to make DNS itself GeoDNS-friendly? When editing a zone file in `emacs`, why can one not say that one has 3 web servers -- Europe, NA, Asia -- and have the dns infrastructure and/or the web-browser figure out the rest? Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy. It should be possible to say that you have a server in Fremont, CA and Toronto, ON or Beauharnois, QC, and automatically have all East Coast users go to Toronto, and West Coast to Fremont. Why is there no way to do any of this? Cheers, Constantine.
On 3/20/13 8:28 PM, Constantine A. Murenin wrote:
Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy. It should be possible to say that you have a server in Fremont, CA and Toronto, ON or Beauharnois, QC, and automatically have all East Coast users go to Toronto, and West Coast to Fremont. Why is there no way to do any of this?
I guess there could be with LOC records. ~Seth
On 20 March 2013 20:57, Seth Mattinen <sethm@rollernet.us> wrote:
On 3/20/13 8:28 PM, Constantine A. Murenin wrote:
Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy. It should be possible to say that you have a server in Fremont, CA and Toronto, ON or Beauharnois, QC, and automatically have all East Coast users go to Toronto, and West Coast to Fremont. Why is there no way to do any of this?
I guess there could be with LOC records.
~Seth
Apart from not being supported by anyone, it's also broken by design in regards to the "Searching by Network or Subnet" section (e.g. the party who controls 0.0.0.88.in-addr.arpa is not at all related to the party that has 88.198.0.0/16), and also has no IPv6 support: http://tools.ietf.org/html/rfc1876#section-5.2.2 C.
You can set up GeoDNS without anycast with PowerDNS and Bind easily enough (I found PowerDNS easier to setup). If you are using Bind you can use the geoip patch or use views which is a quick hacky way. http://doc.powerdns.com/html/geo.html I can't comment on either solution if it supports getting the real remote IP address (PowerDNS does for the PipeBackend if its enabled so I assume it may be available) rather than the address of the resolver. For management I would lean towards PowerDNS of the two, you can stick on any of the available web interfaces if you want and use the SQL backend (replication can be used here to update records on slaves). The country management would still need to be done out of files though the records themselves would be edited/served out of the database. I don't run Bind any more but if you want a copy of the configs for PowerDNS or other details email me offlist and I am happy to help. On 21/03/2013 11:28 AM, Constantine A. Murenin wrote:
Dear NANOG@,
Not every operator has the ability to setup their own anycast.
Not every operator is big enough to be paying 25 USD/month for a managed GeoDNS solution, just to get their hands on GeoDNS. (Hey, for 25$/mo, I might as well have an extra POP or two!)
Why so many years after the concept has been introduced and has been found useful, can one not setup GeoDNS in under 5 minutes on one's own infrastructure, or use GeoDNS from any of the plentiful free or complementary DNS solutions that are offered by providers like he.net, xname.org, linode.com and others?
I'm an NSD3 user and have a POP in Europe and NA, and, frankly, the easiest (and only) solution I see right now is, on both servers, running two copies of `nsd` on distinct sockets, and redirecting incoming DNS traffic through a firewall based on IPv4 /8 address allocation (RIPE and AfriNIC -- to an `nsd` instance with zone files with an `A` record of a POP in Europe; ARIN, APNIC, LACNIC and the rest of /8 allocations -- an `A` record for NA), with zone replication managed through git. Yeap, it's rough, and quite ugly, and unmaintainable, and will give optimal results only in 80 to 95 per cent of actual cases, and will not benefit from the extra webapp redundancy one otherwise might have had, but what other alternatives could be configured in 5 or 15 minutes?
Any plans to make DNS itself GeoDNS-friendly?
When editing a zone file in `emacs`, why can one not say that one has 3 web servers -- Europe, NA, Asia -- and have the dns infrastructure and/or the web-browser figure out the rest?
Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy. It should be possible to say that you have a server in Fremont, CA and Toronto, ON or Beauharnois, QC, and automatically have all East Coast users go to Toronto, and West Coast to Fremont. Why is there no way to do any of this?
Cheers, Constantine.
Constantine A. Murenin wrote:
Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy.
If you think mobile, they don't, especially because "often" is not at all "enough times".
Why is there no way to do any of this?
Because it is impractical to assume an IP address can be mapped uniquely to a geolocation. Masataka Ohta
On 20 March 2013 21:29, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Constantine A. Murenin wrote:
Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy.
If you think mobile, they don't, especially because "often" is not at all "enough times".
Are you suggesting that geolocation is inaccurate enough to misplace Europe with Asia?
Why is there no way to do any of this?
Because it is impractical to assume an IP address can be mapped uniquely to a geolocation.
Why is it impractical? If I have a server in Germany and in Quebec, why would it be impractical to have the logic in place such that European visitors would be contacting the server in Germany, and visitors from US/Canada -- the one in Quebec? C.
On Thu, 21 Mar 2013, Constantine A. Murenin wrote:
Why is it impractical? If I have a server in Germany and in Quebec, why would it be impractical to have the logic in place such that European visitors would be contacting the server in Germany, and visitors from US/Canada -- the one in Quebec?
But what if the server in Quebec is a little VPS on a 10Mb/s link while the one in Germany is a rack of servers on a 10Gb/s link? What if I just want the server in Quebec to serve people from Canada and the one in Germany serves the rest of the world? What if it is 4am in Quebec but 9am in Germany? (it is right now) What if I have half a dozen pops worldwide? What if I have 20? 200? 2000? What is closer to a user in New Zealand, A Pop in Japan, Singapore or LA? The main thing with GSLB is: The little guys don't need it, The medium sized sites outsource, The big guys roll their own. Personally I outsource and it works very well. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
On Thu, Mar 21, 2013 at 12:23:02AM -0700, Constantine A. Murenin wrote:
On 20 March 2013 21:29, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Constantine A. Murenin wrote:
Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy.
If you think mobile, they don't, especially because "often" is not at all "enough times".
Are you suggesting that geolocation is inaccurate enough to misplace Europe with Asia?
last month, while in western australia, geoloc pegged me in utah. this morning, geoloc pegged me in Kansas, while resident in Maryland.
Why is there no way to do any of this?
Because it is impractical to assume an IP address can be mapped uniquely to a geolocation.
Why is it impractical? If I have a server in Germany and in Quebec, why would it be impractical to have the logic in place such that European visitors would be contacting the server in Germany, and visitors from US/Canada -- the one in Quebec?
C.
secure dynamic update works. waht is TWC's incentive to allow clients to update tjheir reverse DNS delegations, esp when clients are leaving them for T-Mobile? your sugesting the cretion and deployment of something that already exists in the LOC RR. Your rational is that LOC isn't used. If thats the case, why would your proposal be any more successful? /bill
On 21 March 2013 04:36, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Constantine A. Murenin wrote:
Are you suggesting that geolocation is inaccurate enough to misplace Europe with Asia?
Yes, of course.
Think mobile.
Why are you insisting that mobile will have wrong geolocation? Yes, there are cases when due to the portable WiFi hotspots the location may be wrong temporarily, but how is that much different from a suboptimal node selection through a plain round-robin DNS? C.
On 3/21/13 9:27 AM, Constantine A. Murenin wrote:
On 21 March 2013 04:36, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Constantine A. Murenin wrote:
Are you suggesting that geolocation is inaccurate enough to misplace Europe with Asia? Yes, of course.
Think mobile. Why are you insisting that mobile will have wrong geolocation? Because the GGSN is nowhere near the customer's location. Yes, there are cases when due to the portable WiFi hotspots the location may be wrong temporarily, but how is that much different from a suboptimal node selection through a plain round-robin DNS?
C.
Wasn't this problem solved by foursquare.com?! </joke> -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On 21/03/2013 09:23, Constantine A. Murenin wrote:
On 20 March 2013 21:29, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Constantine A. Murenin wrote:
Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy.
If you think mobile, they don't, especially because "often" is not at all "enough times".
Are you suggesting that geolocation is inaccurate enough to misplace Europe with Asia?
I don't think that it is even a suggestion. It is trivially achievable: I have a transit provider which is a US based company. They route a small slice of their IP space to us over the transit link... at their PoP in London... where I pick it up and route it to Johannesburg. All the while - geolocation is convinced those IPs reside in the hometown of my transit provider. I also know of many people who use VPNs to intentionally goelocate themselves somewhere other than their real location in order to get around certain content filtering. -- Graham Beneke
On 21 March 2013 05:23, Graham Beneke <graham@apolix.co.za> wrote:
On 21/03/2013 09:23, Constantine A. Murenin wrote:
On 20 March 2013 21:29, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Constantine A. Murenin wrote:
Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy.
If you think mobile, they don't, especially because "often" is not at all "enough times".
Are you suggesting that geolocation is inaccurate enough to misplace Europe with Asia?
I don't think that it is even a suggestion. It is trivially achievable:
I have a transit provider which is a US based company. They route a small slice of their IP space to us over the transit link... at their PoP in London... where I pick it up and route it to Johannesburg.
All the while - geolocation is convinced those IPs reside in the hometown of my transit provider.
I also know of many people who use VPNs to intentionally goelocate themselves somewhere other than their real location in order to get around certain content filtering.
Your two examples are quite the opposite of each other, I don't know if this was your intention. In the first case, when a US-based (and/or ARIN issued) address space is moved to Europe or Africa, a server-based geoloc would result in suboptimal results, but a client-based geoloc would very likely provide sought-after results. In the second, VPN case -- exactly the opposite -- server-based would work great, client based would be suboptimal. Does it show that geoloc is hard to get right? Yes. But what I don't understand is why everyone implies that the status quo with round-robin DNS is any better. C.
On 3/21/2013 12:39 PM, Constantine A. Murenin wrote:
But what I don't understand is why everyone implies that the status quo with round-robin DNS is any better. C.
Doesn't the Happy Eyeballs address selection algorithm work even when all the potential address are on the same network (be it IPv4 or v6)? As many have pointed out physical location and network location don't always quite correlate. Just recently I've made a change in colos that brought my servers both 400 miles closer to my house, and 30ms further away via the network, and the transit providers in all cases had "Time Warner" in the name. -- Dave
But what I don't understand is why everyone implies that the status quo with round-robin DNS is any better.
I don't think anyone believes round robin DNS records is better. It's that attempting to do better requires adding onto or changing standards that must maintain backwards compatibility and thus nearly useless until everyone adopts it, or hack jobs that have hilariously funny failure scenarios that are unavoidable because it comes down to "guess work".
On 21/03/2013 04:23, Constantine A. Murenin wrote:
Are you suggesting that geolocation is inaccurate enough to misplace Europe with Asia?
Yes, sometimes very inaccurate. Just go to an IETF meeting and you will be placed all around the globe. It is a corner case, but it shows some deficiencies in the current approach. .as
On Mar 21, 2013, at 12:23 AM, "Constantine A. Murenin" <mureninc@gmail.com> wrote:
Why is there no way to do any of this?
Because it is impractical to assume an IP address can be mapped uniquely to a geolocation.
Why is it impractical? If I have a server in Germany and in Quebec, why would it be impractical to have the logic in place such that European visitors would be contacting the server in Germany, and visitors from US/Canada -- the one in Quebec?
There is not "no way to do any of this." People do it all the time. They do it using anycast, which requires a certain amount of network build, or they do it using source-address databases, which have a certain amount of ridiculous FAIL. Are you actually asking why there's no way to do it perfectly at no cost? -Bill
On Mar 20, 2013, at 20:28, Constantine A. Murenin <mureninc@gmail.com> wrote:
[...] but what other alternatives could be configured in 5 or 15 minutes?
You got a lot of answers telling you to not even try, and I don't know that you can configure any of them in 5 minutes. That being said there are lots of options that might be "good enough": - PowerDNS has a Geo backend - http://doc.powerdns.com/html/geo.html - There are various patches for Bind - Gdnsd - https://github.com/blblack/gdnsd - GeoDNS - https://github.com/abh/geodns I use the latter for the www.pool.ntp.org service where it sends users to one of about 4000 local servers ("pops") in about 100 countries about 15 billion times a month. Ask
On Thu, Apr 11, 2013 at 01:53:49PM -0700, Ask Bjørn Hansen wrote:
That being said there are lots of options that might be "good enough":
- PowerDNS has a Geo backend - http://doc.powerdns.com/html/geo.html - There are various patches for Bind - Gdnsd - https://github.com/blblack/gdnsd - GeoDNS - https://github.com/abh/geodns
I use the latter for the www.pool.ntp.org service where it sends users to one of about 4000 local servers ("pops") in about 100 countries about 15 billion times a month.
I haven't done it yet but gdnsd appeared to be the one to use when I tested some stuff out. The idea was to deligate a geo.domainname.com zone to gdnsd and have it perform the GEO DNS lookups. The PowerDNS one, while testing it, gave me problems trying to figure out how to get the geographical data since the readme I was using was out of date and a lot of the information lead to non-existent links etc.
If this is for http and similar user-accessed (not machine accessed) traffic, you could do what some large manufacturers and shipping companies do: Provide a (relatively) low-bandwidth "Select where you are in the world" global landing page which then redirects to a different domain/subdomain for each region. This also lets them direct relatively localized content easily. For example, panasonic.com can list items sold mass-market for the US, panasonic.nl for the Netherlands, and panasonic.com.au for Australia. Yes, you may well run into times that a user in the US goes to the .au site because s/he wants to research an .au product that isn't detailed on the US page but this is not the bulk of your traffic (and, if through stats, you find it becomes so, you can work on your design so that it isn't). - Eric On Wed, Mar 20, 2013 at 11:28 PM, Constantine A. Murenin <mureninc@gmail.com
wrote:
Dear NANOG@,
Not every operator has the ability to setup their own anycast.
Not every operator is big enough to be paying 25 USD/month for a managed GeoDNS solution, just to get their hands on GeoDNS. (Hey, for 25$/mo, I might as well have an extra POP or two!)
Why so many years after the concept has been introduced and has been found useful, can one not setup GeoDNS in under 5 minutes on one's own infrastructure, or use GeoDNS from any of the plentiful free or complementary DNS solutions that are offered by providers like he.net, xname.org, linode.com and others?
I'm an NSD3 user and have a POP in Europe and NA, and, frankly, the easiest (and only) solution I see right now is, on both servers, running two copies of `nsd` on distinct sockets, and redirecting incoming DNS traffic through a firewall based on IPv4 /8 address allocation (RIPE and AfriNIC -- to an `nsd` instance with zone files with an `A` record of a POP in Europe; ARIN, APNIC, LACNIC and the rest of /8 allocations -- an `A` record for NA), with zone replication managed through git. Yeap, it's rough, and quite ugly, and unmaintainable, and will give optimal results only in 80 to 95 per cent of actual cases, and will not benefit from the extra webapp redundancy one otherwise might have had, but what other alternatives could be configured in 5 or 15 minutes?
Any plans to make DNS itself GeoDNS-friendly?
When editing a zone file in `emacs`, why can one not say that one has 3 web servers -- Europe, NA, Asia -- and have the dns infrastructure and/or the web-browser figure out the rest?
Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy. It should be possible to say that you have a server in Fremont, CA and Toronto, ON or Beauharnois, QC, and automatically have all East Coast users go to Toronto, and West Coast to Fremont. Why is there no way to do any of this?
Cheers, Constantine.
participants (21)
-
Andrew Sullivan -
Arturo Servin -
Ask Bjørn Hansen -
Barry Shein -
Bill Woodcock -
bmanning＠vacation.karoshi.com -
Constantine A. Murenin -
Dave Sparro -
Eric Adler -
Graham Beneke -
Jimmy Hess -
Joe Abley -
joel jaeggli -
Josh Hoppes -
Landon Stewart -
Masataka Ohta -
Peter Rocca -
Seth Mattinen -
shthead -
Simon Lyall -
Tony Finch