Lets say I have a webserver, called 'www'. www.example.com resolves to the IP address of that machine. Then I wanna make some virtual hosts, and DNS records for them, like webmail.example.com.
For 'webmail', should I put in an A record with www's IP address, or should I do a CNAME to www?
What's 'cleaner?, more robust? better?
There are two alternate views of this question, and it's one that is ultimately going to be debated forever. I'm not going to give my opinion (because I'm torn myself), but the general arguments each way typically are:
You should define A records for your physical machines, and then CNAME services onto those machines. This does make it rather clear as to what is what, and in the event that you need to renumber there's not a lot of records to change -- just the machine records. On the other hand, it does increase your DNS lookup load somewhat, and "auxiliary" IPs (think SSL vhosts) don't fit neatly into this model.
The literal meaning of "canonical name" (CNAME) is to define strict aliases of the same name (think
mail
andsmtp
), and if you have multiple services running on the same machine they should all have A records, because it reduces load on DNS and some services (NS records and, to a lesser extent, MX records) really aren't impressed with dealing with CNAMEs, so if you have to handle those services differently anyway, we may as well do it for everything.Several relies here suggest that CNAMEs increase DNS load. This made me curious. I fired up wireshark, inspected a request for a CNAME, and at least in our environment the result was returned in one record. Which brings Knuth's aphorism to mind here: "premature optimization is the root of all evil".
I like CNAMEs, but mostly for their psychological effect. They encourage people (like me for instance) to uncouple server names from service names.
Our environment has several SSL certs attached to opaque server names (which we've quit doing). CNAMEs work much better here. In every place I've worked migrating services where the server name is tightly coupled to the service is a headache. CNAMEs give clear conceptual line of separation.
Using a CNAME effectively doubles the lookups on the DNS server. When a request maps to a CNAME, it needs to then look up the A record for the CNAME.
That said, there's a reason CNAME's exist. It makes your DNS so much easier to manage, and unless you're doing tens of thousands of resolutions a day it's not going to matter...
In my opinion, if the virtual hosts are www.someotherdomain.com, then I would treat them as a separate domain with there own set of DNS records (makes it easier later on if they need to be split out). If however its just blog.example.com, then I would use a CNAME.
Just my personal preference.
I would use CNAME because of the perspective of DNS, webmail is an alias to www.
CNAMEs increase load on the DNS system, not on your personal computer or internet connection. I think some people here didn't make that distinction when they replied.
Use A records for primary high-traffic records (@ and www), for example. Use CNAMEs for secondary records that will always map to the same IP of a primary record. For example, if you have a domain "member.site.com" that will always resolve to the same IP as "www.site.com", then you can use a CNAME here for convenience, but if you can use an A record, it would resolve faster.