Pro/Cons for CNAME records.
infernix
We are having a discussion on why not to use CNAME records. Paul Vixie
himself recommends not to use them, but I haven't found much rock-solid
evidence on why not to.
I came up with the following reasons:
1) CNAME records cause confusion. Example: www.eric.com is a cname to
www.jake.com, which is an A to some ip. Apache has 2 differen vhost entries
with different site content, both for www.eric.com and www.jake.com. A
client which accesses www.eric.com will pass this through to Apache, which
will not show www.jake.com to the user but www.eric.com.
2) CNAME records cause more traffic. Example: resolving www.eric.com returns
the CNAME www.jake.com, which in turn has to be resolved too. If
www.eric.com were to be an A record, this would result in less traffic.
I am looking for more pro/con reasons, so fire it up already ;) Also, if you
think that these reasons are incorrect or incomplete, please don't hesitate
to update me!
Thanks in advance. I'm looking forward to some more reasons (particulary
Paul Vixens original reason)
Regards,
infernix
Don Stokes
>1) CNAME records cause confusion. Example: www.eric.com is a cname to
>www.jake.com, which is an A to some ip. Apache has 2 differen vhost entries
>with different site content, both for www.eric.com and www.jake.com. A
>client which accesses www.eric.com will pass this through to Apache, which
>will not show www.jake.com to the user but www.eric.com.
Using CNAMEs or A records does not affect the contents of the Host: header
which is used by Apache and friends for determining which vhost to use.
The Host: header comes straight from the URL; the resolution to an IP
address to contact comes after that.
>I am looking for more pro/con reasons, so fire it up already ;) Also, if you
>think that these reasons are incorrect or incomplete, please don't hesitate
>to update me!
Well, my rule of thumb is not to use CNAMEs within your own management
domain. That is, if the name points to an IP address that you control,
use an A record. If the name points to a server whose IP address you
don't control, use a CNAME pointing to the server's canonical name. That
way, if the operator of the server changes provider or rearranges their
network, you don't have to do anything in your DNS to keep your service
running.
It's true that by doing this you'll generate a wee bit more traffic, but
it's pretty miniscule. You're more likely to have problems due to
dangling A records. It's a management argument, not a technical one.
That said, it's true that maintaining CNAMEs within your own management
domain can be a pain, and in practice, CNAMEs served by the same server
as the target of the CNAME don't incur significant overhead (there's the
CNAME RR included in the response as well as the A or whatever, but it's
all the same packet). If you change the address of a server, you need
to update all A records, whereas you only need to update the canonical
A record if you use CNAMEs. Personally, I think that if this is a
problem, it's probably time to consider automating your zone file
production, since one doesn't expect to be changing IP addresses too
regularly.
-- don