More information in the DNS load balancing saga.

I thought everything would be simple if I just did it the Google way. But looks can be deceiving. Due to an ambiguity in RFC 2821, MX and CNAME records should not be mixed for the same FQDN in production. Oh well. So how does google do it? Watch this and remember my CNAME example from the previous post:

google.com.		6919	IN	MX	10 smtp1.google.com.
google.com.		6919	IN	MX	10 smtp2.google.com.
google.com.		6919	IN	MX	10 smtp3.google.com.
google.com.		6919	IN	MX	10 smtp4.google.com.

Four MX records for google. But IIRC, I can type http://google.com into my browser and I will not reach an email server, will I? Of course not. So what's going on? Check it:

google.com.		240	IN	A	209.85.171.100
google.com.		240	IN	A	74.125.45.100
google.com.		240	IN	A	74.125.67.100

Okay, so google has three A records for their top level. Cool, that makes sense. But diffing that against the query for www.google.com returns different results. Let's open up that browser again, this time reading HTTP headers.

HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Wed, 28 Jan 2009 22:41:49 GMT
Expires: Fri, 27 Feb 2009 22:41:49 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219

Booya! Google's running a little cluster of HTTP redirect servers at the top level and forcing everyone to land on www.google.com, which is aliased to the larger cluster and load balanced with a CNAME. Whew, that was exhausting.


Written on 2009-01-28 19:47:20 UTC

Back

comments powered by Disqus

I am a hacker and systems architect specializing in data analytics and human computer interfaces.



Photos

Music

lazzarello's Profile Page

  • Login