1

Consider a company that wants to provide HTTP services regionally from a dynamic data center of their choice for a given set of users or IP addresses (e.g. for latency management purposes) under a given domain that they own (e.g. google.com).

My understanding is that when a client (a user) makes an HTTP request (e.g. GET), this request may resolve to an IP address that may have been provided by an ISP DNS server and not by the company in question (putting aside whether or not this was cached in /etc/hosts, etc).

Thus this IP address may not be the one that the company wants to route traffic to. E.g. it could be a bad data center e.g. in a bad region for that user / location at that moment for whatever reason, which could lead to, say, long routing times for IP traffic (e.g. serving UK HTTP requests from the US).

How can the HTTP services company control programmatically in practice, even if only statistically and not immediately, what IP addresses the HTTP traffic for a given user (IP or location) should go to?

Josh
  • 125
  • 5

1 Answers1

3

Not resolving to any service IP of the hosting provider is a huge problem, users cannot reach them.

An ISP DNS resolver that does unwanted mangling of results runs the risk of being replaced by other services. Or be locked out of the traffic by DNSSEC or DNS over HTTP encryption.

For performance, can go pretty far even when hosted in a single geographic region. Pretty sure this very Stack Exchange network is one location (with a remote disaster recovery site). Highly connected locations, say New York City to London, have relatively low latency. But beware, try to minimize the number of round trips. Separating a database server and the associated web server by an ocean is not going to perform well.

A typical workaround to static IP address, but needing to be in multiple locations, is anycast. Many content delivery networks have anycast POPs all over. This actually has less control over where traffic goes, but in theory requests will go to the closest by IP routing.

You mentioned Google. Google has invested in all of the above: anycast IP addresses from their own address space, POPs everywhere, encrypting DNS, even owning their own transit networks. You can rent some of this infrastructure via GCP.

Google isn't comparable to most enterprises, as their operations are inherently in multiple locations. Resolve google.com. The 1e100.net address will contain an airport code relatively close to you.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Thanks John, but just for clarity, from what I gather here, the only answer that you mention to the actual question is anycast, correct? And if so, wouldn't that mean that the domain company would **not** have control over what datacenter serves what users? (IIUC anycast relies on BGP, so they wouldn't really be able to control what data center receives what packets). Also, I think anycast only works well for connectionless traffic (e.g. UDP), i.e. it would **not** work well for HTTP traffic (my Q). Thus, technically speaking anycast isn't a solution here Or did I get it wrong? – Josh Jun 28 '20 at 21:45
  • 1
    You'd be surprised at how much CDN type traffic is anycast. But it is not the only solution. Can change the IP addresses, but when the user agents are out of your control, DNS will be cached for quite a while. Routing protocols other than BGP exist, but on your networks, not between Internet AS. – John Mahowald Jun 30 '20 at 02:57