Re: DNS for hosting: A or CNAME?

From: Bryce Utting (butting_at_ihug.co.nz)
Date: 09/17/04 

Date: Fri, 17 Sep 2004 02:20:02 +0000 (UTC)

In article <414f939a.2044738268@msnews.microsoft.com>, Jeff Cochran wrote:
><butting@ihug.co.nz> wrote:
>>Our company website has just been moved from one provider (Apache,
>>stable for several years now) to another (IIS 5) to allow a
>>developer's ASP application to run on it.
>>
>>The migration left the new site offline for 23 hours. (!!!)
>
> Bad migration planning. :)

Yep. The plan was:

  1. The webmaster sets up his server to answer as the new host
  2. I make the DNS change
  3. Profit!

Unfortunately, my two-minute-involvement turned into about three
afternoons of "Oi! This isn't working!"

I coulda just left it that way, but...

>>I'm not dealing directly with the webhost (there's a tangled path
>>there involving the ASP developer), but my role came down to (a)
>>updating our domain's DNS to point to the new host and (b) trying to
>>sort out who was responsible for the foulup so I could get them to fix
>>it.
>
> Nobody really. The problem is you stopped one before the replacemtn
> was fully available. DNS takes time to propagate, often several days.

Well, yes, but according to the plan the old site would still be
responding to any requests that came its way. (Which is was, and is.)
Unfortunately the new site simply wasn't ready, with predictable
results.

>>Long story short, the hosting company kicked off by passing us an odd
>>request specifying that DNS needed to be by CNAME rather than A.
>
> So? It's neither odd nor affecting IIS or Apache. Web servers
> respond to an IP, not a name. How the name is resolved is a DNS
> decision.

Which was exactly how I saw it. But his "We want a CNAME, not an A"
*was* odd, and raised alarms with me that the webmaster couldn't tell
his arse from his elbow... which turned out to be the case.

>>Now,
>>I know for a fact that Apache doesn't care either way, and I'm at a
>>loss to see how IIS would know any difference either: TTBOMK *any* web
>>server simply checks the hostname requested against what it expects to
>>answer for that IP, and doesn't look into the origins of that name any
>>further. (Unlike, eg., mail servers, which frequently do rDNS
>>lookups.) Mind, I don't run a public-facing webserver of any breed,
>>so I happily accept I could well be wrong there.
>
> Except for the web server never checking anything, you're right. With
> the exception of using host headers, in which case the IIS config must
> account for the host name used.

Yep. I had Apache's HostnameLookups in the back of my mind, but (a)
that's only for logging, and (b) it doesn't attempt to resolve the
server's own hostname (or where--or how--it's defined).

>>Updating DNS to point to them (yes, via CNAME) left us with 23 hours
>>of "No web site is configured at this address."
>
> Yep. Happens that way.

... in fact, I'd set my local zonefile to point at them before
migration, gotten that error, alerted them to the fact, and got back
"the CNAME hasnt been added".

sigh.

>>My question is: *can* IIS tell any difference, or is this simply a
>>further indication that I should request that the tangled path
>>terminate with someone who actually knows what they're doing?
>
> IIS only knows about the IP, unless it uses host headers. In which
> case it still doesn't do any name resolution, DNS still handles that.

Bingo.

> But DNS changes aren't instant. Any responsible migration accounts
> for that effect. And every web host I've run into makes a point of
> mentioning that when tranferring sites.

Yep ditto: I knew *that* well in advance, although it occurs to me
that the (ahem) webmaster responsible mightn't have come across that
piece of clue either.

> Might also look at:
>
> DNS Basics for IIS Administrators:
> http://www.iisanswers.com/articles/dns_for_iis.htm

Ta. That site seems to be down for now, but Google's cached copy
looks like a useful resource. I might pass it on to our
arse-elbow-monkey.

thanks,
butting