Tim wrote:
Paul Howarth:
They're useful as long as you know what you're doing :-)
Too bad too many people don't :-(
Derek Martin:
I don't really agree; they're totally redundant. You're better off
just using an A record. That will always behave intuitively and
completely avoids all the stupid problems associated with CNAMEs.
I was under the impression that CNAMEs were supposed to act as some sort
of redirecting instruction (this is the name that you should be using,
it's the one we consider canonical), so stop using the other domain name
you original tried to use. Though nothing appears to work that way.
e.g. For DNS records like this
print A 192.168.1.10
printer CNAME print
printers CNAME print
printing CNAME print
Where you're wanting people to use "print" (+ domain name) as the
address for your printer, but somewhere along the line people have been
using other addresses you'd like them to no-longer use, but don't want
to block from being used.
You can look at it that way, but the people using the "deprecated" names
never get any indication that the name they're using isn't the "right"
one, at least not via the DNS itself (a web-based service could use a
redirect when accessed with a deprecated hostname in HTTP 1.1).
Another traditional use was for providing named hosts for each service
and then providing all services on one host, e.g.
myserver A 10.0.0.1
ftp CNAME myserver
www CNAME myserver
rsync CNAME myserver
If the load became too high, each service could then be split off onto
separate machines:
myserver A 10.0.0.1
myserver2 A 10.0.0.2
myserver3 A 10.0.0.3
ftp CNAME myserver
www CNAME myserver2
rsync CNAME myserver3
This would all be transparent to people using the "ftp", "www", and
"rsync" aliases.
Paul.