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