The server name is distinct from the domain part of the mail addresses it accepts email for, these need not even be in the same domain.
Typical small-scale setups would use a server name that is unrelated to its function and a CNAME
that maps from a name describing the function to the actual server name, plus a few extra DNS records describing the services.
So you'd end up with
. IN MX 10 mail
_sip._udp IN SRV 10 1 5060 sip
mail IN CNAME cute
www IN CNAME cute
sip IN CNAME cute
cute IN A 1.2.3.4
The mapping from service to host name is historically grown: for mail, a separate record type exists that maps the mail domain name to a set of hosts responsible. For the SIP telephony protocol (and a few others), the generic SRV record fulfills the same role. For web sites, no such lookup exists, and instead people use the convention to include a hostname "www" in the URL.
The CNAMEs then map the services to the actual hosts. This could be omitted and the mapping done directly (except for the "www" case), but it is good style to use a separate host name so you can refer to these in other situations (e.g. ssh mail.my.domain
will connect you to the mail server wherever it is).
The actual hosts are then configured normally, whether you give them cute names or functional ones depends on your environment.
For SSL certificates, it makes sense to use the host name that the client uses to address them. For mail servers, that is the name in the MX
record, i.e. the certificate would use the name mail.my.domain
. The CNAME
resolution is invisible to the client.