Could a name server resolve IP addresses dynamically based on some strategy?
We have registered some name servers for DNS resolving for our website which is deployed in several data centers.
Our current strategy of DNS resolve is that based on the different client IP addresses, the name server will return different IP addresses for the same domain. For example, if the client IP address is from North America, the name server will return an IP address which is the IP address of our North America data center.
But the client IP address sometimes is not the real IP address of the users. It may be an IP address of DNS which belongs to an ISP or a proxy server. On the other hand, if one of our data centers is down, we want our name server exclude that IP address which belongs to the crashed data center. So we hope that we can get a more dynamic strategy for our DNS resolve. Is there a solution for that?
networking domain-name-system
|
show 4 more comments
We have registered some name servers for DNS resolving for our website which is deployed in several data centers.
Our current strategy of DNS resolve is that based on the different client IP addresses, the name server will return different IP addresses for the same domain. For example, if the client IP address is from North America, the name server will return an IP address which is the IP address of our North America data center.
But the client IP address sometimes is not the real IP address of the users. It may be an IP address of DNS which belongs to an ISP or a proxy server. On the other hand, if one of our data centers is down, we want our name server exclude that IP address which belongs to the crashed data center. So we hope that we can get a more dynamic strategy for our DNS resolve. Is there a solution for that?
networking domain-name-system
This sounds like a case for anycast.
– Ron Maupin
Nov 25 '18 at 2:59
1
@RonMaupin It should be pointed out that to do anycast one has to have a Provider Independent address block allocation and more importantly run BGP to advertise the prefixes from each datacentre. That's a whole new level of operations and not something many "content oriented" companies would have experience with. DNS-based solution looks much easier.
– I-P-X
Nov 25 '18 at 20:35
@I-P-X, I would imagine that a company with data centers around the world, as it seems in the question, will have provider-independent addressing and its own AS number. With that, anycast is free and easy.
– Ron Maupin
Nov 25 '18 at 20:37
1
@RonMaupin if the OP's company was actually operating multiple datacentres around the world then yes, but then they would probably not be asking a relatively simple question over here. I bet they simply co-locate their own or hired HW in several commercial datacentres and don't really do/care about advanced network ops. That's what I've seen many medium-sized companies do for redundancy. If that's the case DNS is the answer, not routing.
– I-P-X
Nov 25 '18 at 20:44
@I-P-X, what I glean from the question is that the company has data centers around the world, and if one data center crashes, the traffic directed should be directed to a different data center ("if one of our data centers is down..."). I simply answered the question as asked, rather than trying to guess about third-party hosting, and we do some of that, too, but still have our own provider independent addressing and AS number used to peer with ISPs. That allows negotiation of contracts and changing ISPs without network disruption of readdressing.
– Ron Maupin
Nov 25 '18 at 20:59
|
show 4 more comments
We have registered some name servers for DNS resolving for our website which is deployed in several data centers.
Our current strategy of DNS resolve is that based on the different client IP addresses, the name server will return different IP addresses for the same domain. For example, if the client IP address is from North America, the name server will return an IP address which is the IP address of our North America data center.
But the client IP address sometimes is not the real IP address of the users. It may be an IP address of DNS which belongs to an ISP or a proxy server. On the other hand, if one of our data centers is down, we want our name server exclude that IP address which belongs to the crashed data center. So we hope that we can get a more dynamic strategy for our DNS resolve. Is there a solution for that?
networking domain-name-system
We have registered some name servers for DNS resolving for our website which is deployed in several data centers.
Our current strategy of DNS resolve is that based on the different client IP addresses, the name server will return different IP addresses for the same domain. For example, if the client IP address is from North America, the name server will return an IP address which is the IP address of our North America data center.
But the client IP address sometimes is not the real IP address of the users. It may be an IP address of DNS which belongs to an ISP or a proxy server. On the other hand, if one of our data centers is down, we want our name server exclude that IP address which belongs to the crashed data center. So we hope that we can get a more dynamic strategy for our DNS resolve. Is there a solution for that?
networking domain-name-system
networking domain-name-system
edited Nov 29 '18 at 12:30
kasperd
26.3k115099
26.3k115099
asked Nov 25 '18 at 2:57
yifanyifan
575
575
This sounds like a case for anycast.
– Ron Maupin
Nov 25 '18 at 2:59
1
@RonMaupin It should be pointed out that to do anycast one has to have a Provider Independent address block allocation and more importantly run BGP to advertise the prefixes from each datacentre. That's a whole new level of operations and not something many "content oriented" companies would have experience with. DNS-based solution looks much easier.
– I-P-X
Nov 25 '18 at 20:35
@I-P-X, I would imagine that a company with data centers around the world, as it seems in the question, will have provider-independent addressing and its own AS number. With that, anycast is free and easy.
– Ron Maupin
Nov 25 '18 at 20:37
1
@RonMaupin if the OP's company was actually operating multiple datacentres around the world then yes, but then they would probably not be asking a relatively simple question over here. I bet they simply co-locate their own or hired HW in several commercial datacentres and don't really do/care about advanced network ops. That's what I've seen many medium-sized companies do for redundancy. If that's the case DNS is the answer, not routing.
– I-P-X
Nov 25 '18 at 20:44
@I-P-X, what I glean from the question is that the company has data centers around the world, and if one data center crashes, the traffic directed should be directed to a different data center ("if one of our data centers is down..."). I simply answered the question as asked, rather than trying to guess about third-party hosting, and we do some of that, too, but still have our own provider independent addressing and AS number used to peer with ISPs. That allows negotiation of contracts and changing ISPs without network disruption of readdressing.
– Ron Maupin
Nov 25 '18 at 20:59
|
show 4 more comments
This sounds like a case for anycast.
– Ron Maupin
Nov 25 '18 at 2:59
1
@RonMaupin It should be pointed out that to do anycast one has to have a Provider Independent address block allocation and more importantly run BGP to advertise the prefixes from each datacentre. That's a whole new level of operations and not something many "content oriented" companies would have experience with. DNS-based solution looks much easier.
– I-P-X
Nov 25 '18 at 20:35
@I-P-X, I would imagine that a company with data centers around the world, as it seems in the question, will have provider-independent addressing and its own AS number. With that, anycast is free and easy.
– Ron Maupin
Nov 25 '18 at 20:37
1
@RonMaupin if the OP's company was actually operating multiple datacentres around the world then yes, but then they would probably not be asking a relatively simple question over here. I bet they simply co-locate their own or hired HW in several commercial datacentres and don't really do/care about advanced network ops. That's what I've seen many medium-sized companies do for redundancy. If that's the case DNS is the answer, not routing.
– I-P-X
Nov 25 '18 at 20:44
@I-P-X, what I glean from the question is that the company has data centers around the world, and if one data center crashes, the traffic directed should be directed to a different data center ("if one of our data centers is down..."). I simply answered the question as asked, rather than trying to guess about third-party hosting, and we do some of that, too, but still have our own provider independent addressing and AS number used to peer with ISPs. That allows negotiation of contracts and changing ISPs without network disruption of readdressing.
– Ron Maupin
Nov 25 '18 at 20:59
This sounds like a case for anycast.
– Ron Maupin
Nov 25 '18 at 2:59
This sounds like a case for anycast.
– Ron Maupin
Nov 25 '18 at 2:59
1
1
@RonMaupin It should be pointed out that to do anycast one has to have a Provider Independent address block allocation and more importantly run BGP to advertise the prefixes from each datacentre. That's a whole new level of operations and not something many "content oriented" companies would have experience with. DNS-based solution looks much easier.
– I-P-X
Nov 25 '18 at 20:35
@RonMaupin It should be pointed out that to do anycast one has to have a Provider Independent address block allocation and more importantly run BGP to advertise the prefixes from each datacentre. That's a whole new level of operations and not something many "content oriented" companies would have experience with. DNS-based solution looks much easier.
– I-P-X
Nov 25 '18 at 20:35
@I-P-X, I would imagine that a company with data centers around the world, as it seems in the question, will have provider-independent addressing and its own AS number. With that, anycast is free and easy.
– Ron Maupin
Nov 25 '18 at 20:37
@I-P-X, I would imagine that a company with data centers around the world, as it seems in the question, will have provider-independent addressing and its own AS number. With that, anycast is free and easy.
– Ron Maupin
Nov 25 '18 at 20:37
1
1
@RonMaupin if the OP's company was actually operating multiple datacentres around the world then yes, but then they would probably not be asking a relatively simple question over here. I bet they simply co-locate their own or hired HW in several commercial datacentres and don't really do/care about advanced network ops. That's what I've seen many medium-sized companies do for redundancy. If that's the case DNS is the answer, not routing.
– I-P-X
Nov 25 '18 at 20:44
@RonMaupin if the OP's company was actually operating multiple datacentres around the world then yes, but then they would probably not be asking a relatively simple question over here. I bet they simply co-locate their own or hired HW in several commercial datacentres and don't really do/care about advanced network ops. That's what I've seen many medium-sized companies do for redundancy. If that's the case DNS is the answer, not routing.
– I-P-X
Nov 25 '18 at 20:44
@I-P-X, what I glean from the question is that the company has data centers around the world, and if one data center crashes, the traffic directed should be directed to a different data center ("if one of our data centers is down..."). I simply answered the question as asked, rather than trying to guess about third-party hosting, and we do some of that, too, but still have our own provider independent addressing and AS number used to peer with ISPs. That allows negotiation of contracts and changing ISPs without network disruption of readdressing.
– Ron Maupin
Nov 25 '18 at 20:59
@I-P-X, what I glean from the question is that the company has data centers around the world, and if one data center crashes, the traffic directed should be directed to a different data center ("if one of our data centers is down..."). I simply answered the question as asked, rather than trying to guess about third-party hosting, and we do some of that, too, but still have our own provider independent addressing and AS number used to peer with ISPs. That allows negotiation of contracts and changing ISPs without network disruption of readdressing.
– Ron Maupin
Nov 25 '18 at 20:59
|
show 4 more comments
4 Answers
4
active
oldest
votes
It sounds like you want anycast. That is the type of thing that sites like Google use. You have a single address (resolved by DNS) for all your web sites, and you let the Internet routing protocol (BGP) direct the users to the nearest (by the routing protocol) site. If a site goes down, the next closest site is placed in the Internet routing table automatically by BGP.
The classic example is 8.8.8.8
for DNS. It resolves to different locations around the globe, and if one location goes down, then it goes to the next closest location.
The answer is not DNS, it is routing.
2
Anycast is normally not useful for TCP-based protocols, because packets belonging to the same connection can go to different servers.
– Paŭlo Ebermann
Nov 25 '18 at 11:39
2
@PaŭloEbermann that is not an issue when you do it with BGP routing, as the routes usually don't change when announced (only minor changes)
– Ferrybig
Nov 25 '18 at 14:23
2
@PaŭloEbermann You can do anycast across DSR based load balancers as long as long as all of your load balancers agree on how to choose backends.
– kasperd
Nov 25 '18 at 15:49
3
@PaŭloEbermann, that is a misconception. All the traffic from one host will go to one server, unless that server goes down, then the traffic will be directed to a different server. Yes, that would break the TCP connection, but that would be the case whenever the server to which you are connected goes down. Anycast is not a round-robin type of thing. Routing is deterministic, so anycast is deterministic.
– Ron Maupin
Nov 25 '18 at 16:48
2
@RonMaupin Anycast routing is not as stable as you are implying. And Google doesn't use anycast the way you are saying. If you want to know how Google actually does this take a look on page 227 in The Site Reliability Workbook published by Google. In short the load balancing layer behind anycast routing compensate for the inevitable changes in routing which would otherwise break TCP connections.
– kasperd
Nov 26 '18 at 21:32
|
show 3 more comments
What you need is exactly what Amazon Route53 DNS service offers:
Latency based routing - Route end users to the AWS region that provides the lowest possible latency.
Geo DNS - Route end users to a particular endpoint that you specify based on the end user’s geographic location.
Health Checks and Failover - Amazon Route 53 can monitor the health and performance of your application as well as your web servers and other resources.
... and many more advanced DNS features.
You don't have to host your website on AWS to be able to use Route53, it will happily work with services deployed across private datacentres.
Unless you're a Facebook or Google pricing shouldn't be an issue either, starting from $0.40 per million requests (see pricing details).
Hope that helps :)
Have you ever used any non-Amazon products for this?
– chicks
Nov 27 '18 at 18:24
@chicks nope I haven't. I always tend to use the best tool for the job and Route53 fits the bill in most cases. However if you google something like "geo dns service" you'll get some options. I quickly looked at a few but they seem quite expensive (around $50/month - far more than you'd probably spend with AWS Route53).
– MLu
Nov 27 '18 at 20:49
2
I would broaden my perspective a bit more before calling the first tool I found the best tool for most cases. Route53 could be the best for everybody, but how would you know if you haven't tried anything else?
– chicks
Nov 30 '18 at 23:22
add a comment |
I had this idea and had began to code it but never finished as the need evaporated first.
The DNS server has the host names and MAC addresses of all the machines on its LAN and a way to reach them. When it receives a request for a machine it knows, it sends a reverse ARP for the IP address given the MAC address and uses the response to construct the DNS answer.
This is nothing to do with what you are trying to do, but it illustrates the point. A DNS server can in theory be coded to carry out whatever novel scheme you want to resolve names to IP addresses.
The actual question appears to be how to get the customer's IP address to decide where to send them. This is a small bit of an XY problem. What you really want is the customer's ISP to geolocate on, and you can get that by doing it directly off the IP address making the request, assuming it isn't 8.8.4.4 or some other DNS redirecting service. To my mind, the best solution to the DNS redirectors is to ignore the problem and do a self-relative geolocation (that is, from the DNS server try to locate the calling IP address) and redirect appropriately. See here for how to geolocate: https://stackoverflow.com/questions/2574542/location-detecting-techniques-for-ip-addresses
You really really don't want anycast here but something more sane. Anycast has the annoying property is it can reroute packets in the middle of your TCP stream causing mass confusion.
Ron Maupin claims that anycast is route-reliable for TCP. Here is the traceroute showing otherwise:
3 cr1-rhe-a-be153.bb.as11404.net (174.127.183.14) 20.657 ms 20.763 ms 19.660 ms
4 cr1-che-b-be-2.as11404.net (192.175.29.161) 22.550 ms 23.562 ms 23.538 ms
5 * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108) 24.409 ms 38.083 ms
6 72.14.222.146 (72.14.222.146) 40.038 ms 39.106 ms 39.125 ms
7 108.170.242.225 (108.170.242.225) 37.930 ms 108.170.243.1 (108.170.243.1) 35.434 ms 108.170.242.225 (108.170.242.225) 33.694 ms
8 209.85.240.249 (209.85.240.249) 33.476 ms 108.170.232.65 (108.170.232.65) 31.683 ms 108.170.234.155 (108.170.234.155) 30.754 ms
9 google-public-dns-b.google.com (8.8.4.4) 30.491 ms 28.644 ms 25.718 ms
If you try to geolocate the upstream IP addresses the obvious way you get they're both in Wichita. This is not correct by which a simple demonstration of physics will suffice.
The range to 8.8.4.4 is measured at 30ms of which the first 18ms is the local penalty (hop 3 is my ISP's local router). My distance to Wichita is 1297 miles. The minimum round trip time is therefore (1297 * 2 miles / 225,000 kilometers per second (speed of light in glass)) which is 18.55ms. Therefore I should get no response back faster than 28ms but I got one back in 25ms.
The packets are arriving at Google by two different BGP routes. BGP did not pick the closest.
Let us continue this discussion in chat.
– yifan
Nov 26 '18 at 4:01
Comments are not for extended discussion; this conversation has been moved to chat.
– Ward♦
Nov 26 '18 at 4:40
I've moved all the comments to chat, but because there were so many and some were automatically moved, I'm not sure if the later chat has them all. In any case, further discussion about the validity of this answer and how routers work, etc., shouldn't be in comments, keep it in one of the chat rooms. Any further comments here will be deleted.
– Ward♦
Nov 26 '18 at 4:44
add a comment |
What you need could be achieved with some combination of DNS anycast and RFC-7871.
1
More detail would improve your answer
– Dave M
Nov 26 '18 at 13:08
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f941506%2fcould-a-name-server-resolve-ip-addresses-dynamically-based-on-some-strategy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
It sounds like you want anycast. That is the type of thing that sites like Google use. You have a single address (resolved by DNS) for all your web sites, and you let the Internet routing protocol (BGP) direct the users to the nearest (by the routing protocol) site. If a site goes down, the next closest site is placed in the Internet routing table automatically by BGP.
The classic example is 8.8.8.8
for DNS. It resolves to different locations around the globe, and if one location goes down, then it goes to the next closest location.
The answer is not DNS, it is routing.
2
Anycast is normally not useful for TCP-based protocols, because packets belonging to the same connection can go to different servers.
– Paŭlo Ebermann
Nov 25 '18 at 11:39
2
@PaŭloEbermann that is not an issue when you do it with BGP routing, as the routes usually don't change when announced (only minor changes)
– Ferrybig
Nov 25 '18 at 14:23
2
@PaŭloEbermann You can do anycast across DSR based load balancers as long as long as all of your load balancers agree on how to choose backends.
– kasperd
Nov 25 '18 at 15:49
3
@PaŭloEbermann, that is a misconception. All the traffic from one host will go to one server, unless that server goes down, then the traffic will be directed to a different server. Yes, that would break the TCP connection, but that would be the case whenever the server to which you are connected goes down. Anycast is not a round-robin type of thing. Routing is deterministic, so anycast is deterministic.
– Ron Maupin
Nov 25 '18 at 16:48
2
@RonMaupin Anycast routing is not as stable as you are implying. And Google doesn't use anycast the way you are saying. If you want to know how Google actually does this take a look on page 227 in The Site Reliability Workbook published by Google. In short the load balancing layer behind anycast routing compensate for the inevitable changes in routing which would otherwise break TCP connections.
– kasperd
Nov 26 '18 at 21:32
|
show 3 more comments
It sounds like you want anycast. That is the type of thing that sites like Google use. You have a single address (resolved by DNS) for all your web sites, and you let the Internet routing protocol (BGP) direct the users to the nearest (by the routing protocol) site. If a site goes down, the next closest site is placed in the Internet routing table automatically by BGP.
The classic example is 8.8.8.8
for DNS. It resolves to different locations around the globe, and if one location goes down, then it goes to the next closest location.
The answer is not DNS, it is routing.
2
Anycast is normally not useful for TCP-based protocols, because packets belonging to the same connection can go to different servers.
– Paŭlo Ebermann
Nov 25 '18 at 11:39
2
@PaŭloEbermann that is not an issue when you do it with BGP routing, as the routes usually don't change when announced (only minor changes)
– Ferrybig
Nov 25 '18 at 14:23
2
@PaŭloEbermann You can do anycast across DSR based load balancers as long as long as all of your load balancers agree on how to choose backends.
– kasperd
Nov 25 '18 at 15:49
3
@PaŭloEbermann, that is a misconception. All the traffic from one host will go to one server, unless that server goes down, then the traffic will be directed to a different server. Yes, that would break the TCP connection, but that would be the case whenever the server to which you are connected goes down. Anycast is not a round-robin type of thing. Routing is deterministic, so anycast is deterministic.
– Ron Maupin
Nov 25 '18 at 16:48
2
@RonMaupin Anycast routing is not as stable as you are implying. And Google doesn't use anycast the way you are saying. If you want to know how Google actually does this take a look on page 227 in The Site Reliability Workbook published by Google. In short the load balancing layer behind anycast routing compensate for the inevitable changes in routing which would otherwise break TCP connections.
– kasperd
Nov 26 '18 at 21:32
|
show 3 more comments
It sounds like you want anycast. That is the type of thing that sites like Google use. You have a single address (resolved by DNS) for all your web sites, and you let the Internet routing protocol (BGP) direct the users to the nearest (by the routing protocol) site. If a site goes down, the next closest site is placed in the Internet routing table automatically by BGP.
The classic example is 8.8.8.8
for DNS. It resolves to different locations around the globe, and if one location goes down, then it goes to the next closest location.
The answer is not DNS, it is routing.
It sounds like you want anycast. That is the type of thing that sites like Google use. You have a single address (resolved by DNS) for all your web sites, and you let the Internet routing protocol (BGP) direct the users to the nearest (by the routing protocol) site. If a site goes down, the next closest site is placed in the Internet routing table automatically by BGP.
The classic example is 8.8.8.8
for DNS. It resolves to different locations around the globe, and if one location goes down, then it goes to the next closest location.
The answer is not DNS, it is routing.
answered Nov 25 '18 at 3:21
Ron MaupinRon Maupin
2,2481613
2,2481613
2
Anycast is normally not useful for TCP-based protocols, because packets belonging to the same connection can go to different servers.
– Paŭlo Ebermann
Nov 25 '18 at 11:39
2
@PaŭloEbermann that is not an issue when you do it with BGP routing, as the routes usually don't change when announced (only minor changes)
– Ferrybig
Nov 25 '18 at 14:23
2
@PaŭloEbermann You can do anycast across DSR based load balancers as long as long as all of your load balancers agree on how to choose backends.
– kasperd
Nov 25 '18 at 15:49
3
@PaŭloEbermann, that is a misconception. All the traffic from one host will go to one server, unless that server goes down, then the traffic will be directed to a different server. Yes, that would break the TCP connection, but that would be the case whenever the server to which you are connected goes down. Anycast is not a round-robin type of thing. Routing is deterministic, so anycast is deterministic.
– Ron Maupin
Nov 25 '18 at 16:48
2
@RonMaupin Anycast routing is not as stable as you are implying. And Google doesn't use anycast the way you are saying. If you want to know how Google actually does this take a look on page 227 in The Site Reliability Workbook published by Google. In short the load balancing layer behind anycast routing compensate for the inevitable changes in routing which would otherwise break TCP connections.
– kasperd
Nov 26 '18 at 21:32
|
show 3 more comments
2
Anycast is normally not useful for TCP-based protocols, because packets belonging to the same connection can go to different servers.
– Paŭlo Ebermann
Nov 25 '18 at 11:39
2
@PaŭloEbermann that is not an issue when you do it with BGP routing, as the routes usually don't change when announced (only minor changes)
– Ferrybig
Nov 25 '18 at 14:23
2
@PaŭloEbermann You can do anycast across DSR based load balancers as long as long as all of your load balancers agree on how to choose backends.
– kasperd
Nov 25 '18 at 15:49
3
@PaŭloEbermann, that is a misconception. All the traffic from one host will go to one server, unless that server goes down, then the traffic will be directed to a different server. Yes, that would break the TCP connection, but that would be the case whenever the server to which you are connected goes down. Anycast is not a round-robin type of thing. Routing is deterministic, so anycast is deterministic.
– Ron Maupin
Nov 25 '18 at 16:48
2
@RonMaupin Anycast routing is not as stable as you are implying. And Google doesn't use anycast the way you are saying. If you want to know how Google actually does this take a look on page 227 in The Site Reliability Workbook published by Google. In short the load balancing layer behind anycast routing compensate for the inevitable changes in routing which would otherwise break TCP connections.
– kasperd
Nov 26 '18 at 21:32
2
2
Anycast is normally not useful for TCP-based protocols, because packets belonging to the same connection can go to different servers.
– Paŭlo Ebermann
Nov 25 '18 at 11:39
Anycast is normally not useful for TCP-based protocols, because packets belonging to the same connection can go to different servers.
– Paŭlo Ebermann
Nov 25 '18 at 11:39
2
2
@PaŭloEbermann that is not an issue when you do it with BGP routing, as the routes usually don't change when announced (only minor changes)
– Ferrybig
Nov 25 '18 at 14:23
@PaŭloEbermann that is not an issue when you do it with BGP routing, as the routes usually don't change when announced (only minor changes)
– Ferrybig
Nov 25 '18 at 14:23
2
2
@PaŭloEbermann You can do anycast across DSR based load balancers as long as long as all of your load balancers agree on how to choose backends.
– kasperd
Nov 25 '18 at 15:49
@PaŭloEbermann You can do anycast across DSR based load balancers as long as long as all of your load balancers agree on how to choose backends.
– kasperd
Nov 25 '18 at 15:49
3
3
@PaŭloEbermann, that is a misconception. All the traffic from one host will go to one server, unless that server goes down, then the traffic will be directed to a different server. Yes, that would break the TCP connection, but that would be the case whenever the server to which you are connected goes down. Anycast is not a round-robin type of thing. Routing is deterministic, so anycast is deterministic.
– Ron Maupin
Nov 25 '18 at 16:48
@PaŭloEbermann, that is a misconception. All the traffic from one host will go to one server, unless that server goes down, then the traffic will be directed to a different server. Yes, that would break the TCP connection, but that would be the case whenever the server to which you are connected goes down. Anycast is not a round-robin type of thing. Routing is deterministic, so anycast is deterministic.
– Ron Maupin
Nov 25 '18 at 16:48
2
2
@RonMaupin Anycast routing is not as stable as you are implying. And Google doesn't use anycast the way you are saying. If you want to know how Google actually does this take a look on page 227 in The Site Reliability Workbook published by Google. In short the load balancing layer behind anycast routing compensate for the inevitable changes in routing which would otherwise break TCP connections.
– kasperd
Nov 26 '18 at 21:32
@RonMaupin Anycast routing is not as stable as you are implying. And Google doesn't use anycast the way you are saying. If you want to know how Google actually does this take a look on page 227 in The Site Reliability Workbook published by Google. In short the load balancing layer behind anycast routing compensate for the inevitable changes in routing which would otherwise break TCP connections.
– kasperd
Nov 26 '18 at 21:32
|
show 3 more comments
What you need is exactly what Amazon Route53 DNS service offers:
Latency based routing - Route end users to the AWS region that provides the lowest possible latency.
Geo DNS - Route end users to a particular endpoint that you specify based on the end user’s geographic location.
Health Checks and Failover - Amazon Route 53 can monitor the health and performance of your application as well as your web servers and other resources.
... and many more advanced DNS features.
You don't have to host your website on AWS to be able to use Route53, it will happily work with services deployed across private datacentres.
Unless you're a Facebook or Google pricing shouldn't be an issue either, starting from $0.40 per million requests (see pricing details).
Hope that helps :)
Have you ever used any non-Amazon products for this?
– chicks
Nov 27 '18 at 18:24
@chicks nope I haven't. I always tend to use the best tool for the job and Route53 fits the bill in most cases. However if you google something like "geo dns service" you'll get some options. I quickly looked at a few but they seem quite expensive (around $50/month - far more than you'd probably spend with AWS Route53).
– MLu
Nov 27 '18 at 20:49
2
I would broaden my perspective a bit more before calling the first tool I found the best tool for most cases. Route53 could be the best for everybody, but how would you know if you haven't tried anything else?
– chicks
Nov 30 '18 at 23:22
add a comment |
What you need is exactly what Amazon Route53 DNS service offers:
Latency based routing - Route end users to the AWS region that provides the lowest possible latency.
Geo DNS - Route end users to a particular endpoint that you specify based on the end user’s geographic location.
Health Checks and Failover - Amazon Route 53 can monitor the health and performance of your application as well as your web servers and other resources.
... and many more advanced DNS features.
You don't have to host your website on AWS to be able to use Route53, it will happily work with services deployed across private datacentres.
Unless you're a Facebook or Google pricing shouldn't be an issue either, starting from $0.40 per million requests (see pricing details).
Hope that helps :)
Have you ever used any non-Amazon products for this?
– chicks
Nov 27 '18 at 18:24
@chicks nope I haven't. I always tend to use the best tool for the job and Route53 fits the bill in most cases. However if you google something like "geo dns service" you'll get some options. I quickly looked at a few but they seem quite expensive (around $50/month - far more than you'd probably spend with AWS Route53).
– MLu
Nov 27 '18 at 20:49
2
I would broaden my perspective a bit more before calling the first tool I found the best tool for most cases. Route53 could be the best for everybody, but how would you know if you haven't tried anything else?
– chicks
Nov 30 '18 at 23:22
add a comment |
What you need is exactly what Amazon Route53 DNS service offers:
Latency based routing - Route end users to the AWS region that provides the lowest possible latency.
Geo DNS - Route end users to a particular endpoint that you specify based on the end user’s geographic location.
Health Checks and Failover - Amazon Route 53 can monitor the health and performance of your application as well as your web servers and other resources.
... and many more advanced DNS features.
You don't have to host your website on AWS to be able to use Route53, it will happily work with services deployed across private datacentres.
Unless you're a Facebook or Google pricing shouldn't be an issue either, starting from $0.40 per million requests (see pricing details).
Hope that helps :)
What you need is exactly what Amazon Route53 DNS service offers:
Latency based routing - Route end users to the AWS region that provides the lowest possible latency.
Geo DNS - Route end users to a particular endpoint that you specify based on the end user’s geographic location.
Health Checks and Failover - Amazon Route 53 can monitor the health and performance of your application as well as your web servers and other resources.
... and many more advanced DNS features.
You don't have to host your website on AWS to be able to use Route53, it will happily work with services deployed across private datacentres.
Unless you're a Facebook or Google pricing shouldn't be an issue either, starting from $0.40 per million requests (see pricing details).
Hope that helps :)
edited Nov 25 '18 at 4:16
answered Nov 25 '18 at 4:06
MLuMLu
7,32212040
7,32212040
Have you ever used any non-Amazon products for this?
– chicks
Nov 27 '18 at 18:24
@chicks nope I haven't. I always tend to use the best tool for the job and Route53 fits the bill in most cases. However if you google something like "geo dns service" you'll get some options. I quickly looked at a few but they seem quite expensive (around $50/month - far more than you'd probably spend with AWS Route53).
– MLu
Nov 27 '18 at 20:49
2
I would broaden my perspective a bit more before calling the first tool I found the best tool for most cases. Route53 could be the best for everybody, but how would you know if you haven't tried anything else?
– chicks
Nov 30 '18 at 23:22
add a comment |
Have you ever used any non-Amazon products for this?
– chicks
Nov 27 '18 at 18:24
@chicks nope I haven't. I always tend to use the best tool for the job and Route53 fits the bill in most cases. However if you google something like "geo dns service" you'll get some options. I quickly looked at a few but they seem quite expensive (around $50/month - far more than you'd probably spend with AWS Route53).
– MLu
Nov 27 '18 at 20:49
2
I would broaden my perspective a bit more before calling the first tool I found the best tool for most cases. Route53 could be the best for everybody, but how would you know if you haven't tried anything else?
– chicks
Nov 30 '18 at 23:22
Have you ever used any non-Amazon products for this?
– chicks
Nov 27 '18 at 18:24
Have you ever used any non-Amazon products for this?
– chicks
Nov 27 '18 at 18:24
@chicks nope I haven't. I always tend to use the best tool for the job and Route53 fits the bill in most cases. However if you google something like "geo dns service" you'll get some options. I quickly looked at a few but they seem quite expensive (around $50/month - far more than you'd probably spend with AWS Route53).
– MLu
Nov 27 '18 at 20:49
@chicks nope I haven't. I always tend to use the best tool for the job and Route53 fits the bill in most cases. However if you google something like "geo dns service" you'll get some options. I quickly looked at a few but they seem quite expensive (around $50/month - far more than you'd probably spend with AWS Route53).
– MLu
Nov 27 '18 at 20:49
2
2
I would broaden my perspective a bit more before calling the first tool I found the best tool for most cases. Route53 could be the best for everybody, but how would you know if you haven't tried anything else?
– chicks
Nov 30 '18 at 23:22
I would broaden my perspective a bit more before calling the first tool I found the best tool for most cases. Route53 could be the best for everybody, but how would you know if you haven't tried anything else?
– chicks
Nov 30 '18 at 23:22
add a comment |
I had this idea and had began to code it but never finished as the need evaporated first.
The DNS server has the host names and MAC addresses of all the machines on its LAN and a way to reach them. When it receives a request for a machine it knows, it sends a reverse ARP for the IP address given the MAC address and uses the response to construct the DNS answer.
This is nothing to do with what you are trying to do, but it illustrates the point. A DNS server can in theory be coded to carry out whatever novel scheme you want to resolve names to IP addresses.
The actual question appears to be how to get the customer's IP address to decide where to send them. This is a small bit of an XY problem. What you really want is the customer's ISP to geolocate on, and you can get that by doing it directly off the IP address making the request, assuming it isn't 8.8.4.4 or some other DNS redirecting service. To my mind, the best solution to the DNS redirectors is to ignore the problem and do a self-relative geolocation (that is, from the DNS server try to locate the calling IP address) and redirect appropriately. See here for how to geolocate: https://stackoverflow.com/questions/2574542/location-detecting-techniques-for-ip-addresses
You really really don't want anycast here but something more sane. Anycast has the annoying property is it can reroute packets in the middle of your TCP stream causing mass confusion.
Ron Maupin claims that anycast is route-reliable for TCP. Here is the traceroute showing otherwise:
3 cr1-rhe-a-be153.bb.as11404.net (174.127.183.14) 20.657 ms 20.763 ms 19.660 ms
4 cr1-che-b-be-2.as11404.net (192.175.29.161) 22.550 ms 23.562 ms 23.538 ms
5 * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108) 24.409 ms 38.083 ms
6 72.14.222.146 (72.14.222.146) 40.038 ms 39.106 ms 39.125 ms
7 108.170.242.225 (108.170.242.225) 37.930 ms 108.170.243.1 (108.170.243.1) 35.434 ms 108.170.242.225 (108.170.242.225) 33.694 ms
8 209.85.240.249 (209.85.240.249) 33.476 ms 108.170.232.65 (108.170.232.65) 31.683 ms 108.170.234.155 (108.170.234.155) 30.754 ms
9 google-public-dns-b.google.com (8.8.4.4) 30.491 ms 28.644 ms 25.718 ms
If you try to geolocate the upstream IP addresses the obvious way you get they're both in Wichita. This is not correct by which a simple demonstration of physics will suffice.
The range to 8.8.4.4 is measured at 30ms of which the first 18ms is the local penalty (hop 3 is my ISP's local router). My distance to Wichita is 1297 miles. The minimum round trip time is therefore (1297 * 2 miles / 225,000 kilometers per second (speed of light in glass)) which is 18.55ms. Therefore I should get no response back faster than 28ms but I got one back in 25ms.
The packets are arriving at Google by two different BGP routes. BGP did not pick the closest.
Let us continue this discussion in chat.
– yifan
Nov 26 '18 at 4:01
Comments are not for extended discussion; this conversation has been moved to chat.
– Ward♦
Nov 26 '18 at 4:40
I've moved all the comments to chat, but because there were so many and some were automatically moved, I'm not sure if the later chat has them all. In any case, further discussion about the validity of this answer and how routers work, etc., shouldn't be in comments, keep it in one of the chat rooms. Any further comments here will be deleted.
– Ward♦
Nov 26 '18 at 4:44
add a comment |
I had this idea and had began to code it but never finished as the need evaporated first.
The DNS server has the host names and MAC addresses of all the machines on its LAN and a way to reach them. When it receives a request for a machine it knows, it sends a reverse ARP for the IP address given the MAC address and uses the response to construct the DNS answer.
This is nothing to do with what you are trying to do, but it illustrates the point. A DNS server can in theory be coded to carry out whatever novel scheme you want to resolve names to IP addresses.
The actual question appears to be how to get the customer's IP address to decide where to send them. This is a small bit of an XY problem. What you really want is the customer's ISP to geolocate on, and you can get that by doing it directly off the IP address making the request, assuming it isn't 8.8.4.4 or some other DNS redirecting service. To my mind, the best solution to the DNS redirectors is to ignore the problem and do a self-relative geolocation (that is, from the DNS server try to locate the calling IP address) and redirect appropriately. See here for how to geolocate: https://stackoverflow.com/questions/2574542/location-detecting-techniques-for-ip-addresses
You really really don't want anycast here but something more sane. Anycast has the annoying property is it can reroute packets in the middle of your TCP stream causing mass confusion.
Ron Maupin claims that anycast is route-reliable for TCP. Here is the traceroute showing otherwise:
3 cr1-rhe-a-be153.bb.as11404.net (174.127.183.14) 20.657 ms 20.763 ms 19.660 ms
4 cr1-che-b-be-2.as11404.net (192.175.29.161) 22.550 ms 23.562 ms 23.538 ms
5 * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108) 24.409 ms 38.083 ms
6 72.14.222.146 (72.14.222.146) 40.038 ms 39.106 ms 39.125 ms
7 108.170.242.225 (108.170.242.225) 37.930 ms 108.170.243.1 (108.170.243.1) 35.434 ms 108.170.242.225 (108.170.242.225) 33.694 ms
8 209.85.240.249 (209.85.240.249) 33.476 ms 108.170.232.65 (108.170.232.65) 31.683 ms 108.170.234.155 (108.170.234.155) 30.754 ms
9 google-public-dns-b.google.com (8.8.4.4) 30.491 ms 28.644 ms 25.718 ms
If you try to geolocate the upstream IP addresses the obvious way you get they're both in Wichita. This is not correct by which a simple demonstration of physics will suffice.
The range to 8.8.4.4 is measured at 30ms of which the first 18ms is the local penalty (hop 3 is my ISP's local router). My distance to Wichita is 1297 miles. The minimum round trip time is therefore (1297 * 2 miles / 225,000 kilometers per second (speed of light in glass)) which is 18.55ms. Therefore I should get no response back faster than 28ms but I got one back in 25ms.
The packets are arriving at Google by two different BGP routes. BGP did not pick the closest.
Let us continue this discussion in chat.
– yifan
Nov 26 '18 at 4:01
Comments are not for extended discussion; this conversation has been moved to chat.
– Ward♦
Nov 26 '18 at 4:40
I've moved all the comments to chat, but because there were so many and some were automatically moved, I'm not sure if the later chat has them all. In any case, further discussion about the validity of this answer and how routers work, etc., shouldn't be in comments, keep it in one of the chat rooms. Any further comments here will be deleted.
– Ward♦
Nov 26 '18 at 4:44
add a comment |
I had this idea and had began to code it but never finished as the need evaporated first.
The DNS server has the host names and MAC addresses of all the machines on its LAN and a way to reach them. When it receives a request for a machine it knows, it sends a reverse ARP for the IP address given the MAC address and uses the response to construct the DNS answer.
This is nothing to do with what you are trying to do, but it illustrates the point. A DNS server can in theory be coded to carry out whatever novel scheme you want to resolve names to IP addresses.
The actual question appears to be how to get the customer's IP address to decide where to send them. This is a small bit of an XY problem. What you really want is the customer's ISP to geolocate on, and you can get that by doing it directly off the IP address making the request, assuming it isn't 8.8.4.4 or some other DNS redirecting service. To my mind, the best solution to the DNS redirectors is to ignore the problem and do a self-relative geolocation (that is, from the DNS server try to locate the calling IP address) and redirect appropriately. See here for how to geolocate: https://stackoverflow.com/questions/2574542/location-detecting-techniques-for-ip-addresses
You really really don't want anycast here but something more sane. Anycast has the annoying property is it can reroute packets in the middle of your TCP stream causing mass confusion.
Ron Maupin claims that anycast is route-reliable for TCP. Here is the traceroute showing otherwise:
3 cr1-rhe-a-be153.bb.as11404.net (174.127.183.14) 20.657 ms 20.763 ms 19.660 ms
4 cr1-che-b-be-2.as11404.net (192.175.29.161) 22.550 ms 23.562 ms 23.538 ms
5 * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108) 24.409 ms 38.083 ms
6 72.14.222.146 (72.14.222.146) 40.038 ms 39.106 ms 39.125 ms
7 108.170.242.225 (108.170.242.225) 37.930 ms 108.170.243.1 (108.170.243.1) 35.434 ms 108.170.242.225 (108.170.242.225) 33.694 ms
8 209.85.240.249 (209.85.240.249) 33.476 ms 108.170.232.65 (108.170.232.65) 31.683 ms 108.170.234.155 (108.170.234.155) 30.754 ms
9 google-public-dns-b.google.com (8.8.4.4) 30.491 ms 28.644 ms 25.718 ms
If you try to geolocate the upstream IP addresses the obvious way you get they're both in Wichita. This is not correct by which a simple demonstration of physics will suffice.
The range to 8.8.4.4 is measured at 30ms of which the first 18ms is the local penalty (hop 3 is my ISP's local router). My distance to Wichita is 1297 miles. The minimum round trip time is therefore (1297 * 2 miles / 225,000 kilometers per second (speed of light in glass)) which is 18.55ms. Therefore I should get no response back faster than 28ms but I got one back in 25ms.
The packets are arriving at Google by two different BGP routes. BGP did not pick the closest.
I had this idea and had began to code it but never finished as the need evaporated first.
The DNS server has the host names and MAC addresses of all the machines on its LAN and a way to reach them. When it receives a request for a machine it knows, it sends a reverse ARP for the IP address given the MAC address and uses the response to construct the DNS answer.
This is nothing to do with what you are trying to do, but it illustrates the point. A DNS server can in theory be coded to carry out whatever novel scheme you want to resolve names to IP addresses.
The actual question appears to be how to get the customer's IP address to decide where to send them. This is a small bit of an XY problem. What you really want is the customer's ISP to geolocate on, and you can get that by doing it directly off the IP address making the request, assuming it isn't 8.8.4.4 or some other DNS redirecting service. To my mind, the best solution to the DNS redirectors is to ignore the problem and do a self-relative geolocation (that is, from the DNS server try to locate the calling IP address) and redirect appropriately. See here for how to geolocate: https://stackoverflow.com/questions/2574542/location-detecting-techniques-for-ip-addresses
You really really don't want anycast here but something more sane. Anycast has the annoying property is it can reroute packets in the middle of your TCP stream causing mass confusion.
Ron Maupin claims that anycast is route-reliable for TCP. Here is the traceroute showing otherwise:
3 cr1-rhe-a-be153.bb.as11404.net (174.127.183.14) 20.657 ms 20.763 ms 19.660 ms
4 cr1-che-b-be-2.as11404.net (192.175.29.161) 22.550 ms 23.562 ms 23.538 ms
5 * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108) 24.409 ms 38.083 ms
6 72.14.222.146 (72.14.222.146) 40.038 ms 39.106 ms 39.125 ms
7 108.170.242.225 (108.170.242.225) 37.930 ms 108.170.243.1 (108.170.243.1) 35.434 ms 108.170.242.225 (108.170.242.225) 33.694 ms
8 209.85.240.249 (209.85.240.249) 33.476 ms 108.170.232.65 (108.170.232.65) 31.683 ms 108.170.234.155 (108.170.234.155) 30.754 ms
9 google-public-dns-b.google.com (8.8.4.4) 30.491 ms 28.644 ms 25.718 ms
If you try to geolocate the upstream IP addresses the obvious way you get they're both in Wichita. This is not correct by which a simple demonstration of physics will suffice.
The range to 8.8.4.4 is measured at 30ms of which the first 18ms is the local penalty (hop 3 is my ISP's local router). My distance to Wichita is 1297 miles. The minimum round trip time is therefore (1297 * 2 miles / 225,000 kilometers per second (speed of light in glass)) which is 18.55ms. Therefore I should get no response back faster than 28ms but I got one back in 25ms.
The packets are arriving at Google by two different BGP routes. BGP did not pick the closest.
edited Nov 26 '18 at 4:01
answered Nov 26 '18 at 2:14
joshudsonjoshudson
349210
349210
Let us continue this discussion in chat.
– yifan
Nov 26 '18 at 4:01
Comments are not for extended discussion; this conversation has been moved to chat.
– Ward♦
Nov 26 '18 at 4:40
I've moved all the comments to chat, but because there were so many and some were automatically moved, I'm not sure if the later chat has them all. In any case, further discussion about the validity of this answer and how routers work, etc., shouldn't be in comments, keep it in one of the chat rooms. Any further comments here will be deleted.
– Ward♦
Nov 26 '18 at 4:44
add a comment |
Let us continue this discussion in chat.
– yifan
Nov 26 '18 at 4:01
Comments are not for extended discussion; this conversation has been moved to chat.
– Ward♦
Nov 26 '18 at 4:40
I've moved all the comments to chat, but because there were so many and some were automatically moved, I'm not sure if the later chat has them all. In any case, further discussion about the validity of this answer and how routers work, etc., shouldn't be in comments, keep it in one of the chat rooms. Any further comments here will be deleted.
– Ward♦
Nov 26 '18 at 4:44
Let us continue this discussion in chat.
– yifan
Nov 26 '18 at 4:01
Let us continue this discussion in chat.
– yifan
Nov 26 '18 at 4:01
Comments are not for extended discussion; this conversation has been moved to chat.
– Ward♦
Nov 26 '18 at 4:40
Comments are not for extended discussion; this conversation has been moved to chat.
– Ward♦
Nov 26 '18 at 4:40
I've moved all the comments to chat, but because there were so many and some were automatically moved, I'm not sure if the later chat has them all. In any case, further discussion about the validity of this answer and how routers work, etc., shouldn't be in comments, keep it in one of the chat rooms. Any further comments here will be deleted.
– Ward♦
Nov 26 '18 at 4:44
I've moved all the comments to chat, but because there were so many and some were automatically moved, I'm not sure if the later chat has them all. In any case, further discussion about the validity of this answer and how routers work, etc., shouldn't be in comments, keep it in one of the chat rooms. Any further comments here will be deleted.
– Ward♦
Nov 26 '18 at 4:44
add a comment |
What you need could be achieved with some combination of DNS anycast and RFC-7871.
1
More detail would improve your answer
– Dave M
Nov 26 '18 at 13:08
add a comment |
What you need could be achieved with some combination of DNS anycast and RFC-7871.
1
More detail would improve your answer
– Dave M
Nov 26 '18 at 13:08
add a comment |
What you need could be achieved with some combination of DNS anycast and RFC-7871.
What you need could be achieved with some combination of DNS anycast and RFC-7871.
answered Nov 26 '18 at 10:52
EdheldilEdheldil
1271
1271
1
More detail would improve your answer
– Dave M
Nov 26 '18 at 13:08
add a comment |
1
More detail would improve your answer
– Dave M
Nov 26 '18 at 13:08
1
1
More detail would improve your answer
– Dave M
Nov 26 '18 at 13:08
More detail would improve your answer
– Dave M
Nov 26 '18 at 13:08
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f941506%2fcould-a-name-server-resolve-ip-addresses-dynamically-based-on-some-strategy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
This sounds like a case for anycast.
– Ron Maupin
Nov 25 '18 at 2:59
1
@RonMaupin It should be pointed out that to do anycast one has to have a Provider Independent address block allocation and more importantly run BGP to advertise the prefixes from each datacentre. That's a whole new level of operations and not something many "content oriented" companies would have experience with. DNS-based solution looks much easier.
– I-P-X
Nov 25 '18 at 20:35
@I-P-X, I would imagine that a company with data centers around the world, as it seems in the question, will have provider-independent addressing and its own AS number. With that, anycast is free and easy.
– Ron Maupin
Nov 25 '18 at 20:37
1
@RonMaupin if the OP's company was actually operating multiple datacentres around the world then yes, but then they would probably not be asking a relatively simple question over here. I bet they simply co-locate their own or hired HW in several commercial datacentres and don't really do/care about advanced network ops. That's what I've seen many medium-sized companies do for redundancy. If that's the case DNS is the answer, not routing.
– I-P-X
Nov 25 '18 at 20:44
@I-P-X, what I glean from the question is that the company has data centers around the world, and if one data center crashes, the traffic directed should be directed to a different data center ("if one of our data centers is down..."). I simply answered the question as asked, rather than trying to guess about third-party hosting, and we do some of that, too, but still have our own provider independent addressing and AS number used to peer with ISPs. That allows negotiation of contracts and changing ISPs without network disruption of readdressing.
– Ron Maupin
Nov 25 '18 at 20:59