I'd like internal clients to be able to resolve example.com to www.example.com (our externally served web site).
A maneira como isso geralmente é feito é criar um registro A
para example.com
e tornar www.example.com
a CNAME
que aponta para esse registro A
.
Também é aceitável fazer com que ambos os registros A
apontem para o mesmo endereço IP.
Se você tiver uma versão Interna e Externa da zona example.com
, deverá duplicar os endereços externos em seu arquivo de zona interno (ou apontar esses registros para seus endereços IP internos / privados).
Note que você não pode CNAME
do domínio base ( example.com
), por RFC 1912 :
2.4 CNAME records
A CNAME record is not allowed to coexist with any other data. In
other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
can't also have an MX record for suzy.podunk.edu, or an A record, or
even a TXT record. Especially do not try to combine CNAMEs and NS
records like this!:
podunk.xx. IN NS ns1
IN NS ns2
IN CNAME mary
mary IN A 1.2.3.4
This is often attempted by inexperienced administrators as an obvious
way to allow your domain name to also be a host. However, DNS
servers like BIND will see the CNAME and refuse to add any other
resources for that name. Since no other records are allowed to
coexist with a CNAME, the NS entries are ignored. Therefore all the
hosts in the podunk.xx domain are ignored as well!
If you want to have your domain also be a host, do the following:
podunk.xx. IN NS ns1
IN NS ns2
IN A 1.2.3.4
mary IN A 1.2.3.4
Don't go overboard with CNAMEs. Use them when renaming hosts, but
plan to get rid of them (and inform your users). However CNAMEs are
useful (and encouraged) for generalized names for servers -- 'ftp'
for your ftp server, 'www' for your Web server, 'gopher' for your
Gopher server, 'news' for your Usenet news server, etc.
Don't forget to delete the CNAMEs associated with a host if you
delete the host it is an alias for. Such "stale CNAMEs" are a waste
of resources.