Serge Knystautas ha scritto: > Sorry for the offtopic post, but figured this group might have an > answer to this as much as any. > > I was recently told by someone who said they had built all their DNS > scripts around the notion that CNAMEs are deprecated. We would be > hosting a service offsite that would be a hostname/subdomain of their > domain... we've done CNAME with most other customers and haven't had > too many issues. > > Anyway, don't mean to delve into the specifics, but just curious about > the CNAME deprecated theory. I'm googling and really not finding much > of anything about it.
AFAIK "abuse" of CNAME is strongly discouraged because they increase the DNS traffic Simple "use" of CNAME is instead discouraged because they might create subtle/weird problems with TTL/caching. There is no official deprecation and I think they are mainly discouraged because some DNS expert wrote some webpage arguing against CNAMEs. IIRC most of the problems where related to bugs related to caches and CNAMEs in (maybe old versions of) widely adopted DNS caches (e.g: bind). The interesting RFC is rfc1912 and here are some excerpt: -------------------------------------------------------------------- "Don't go overboard with CNAMEs. Use them when renaming hosts, but plan to get rid of them (and inform your users)" "Also, having chained records such as CNAMEs pointing to CNAMEs may make administration issues easier, but is known to tickle bugs in some resolvers that fail to check loops correctly. As a result some hosts may not be able to resolve such names." "Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR and NS. (PTR is an exception if you want to implement classless in-addr delegation.)" "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." "Having NS records pointing to a CNAME is bad and may conflict badly with current BIND servers. In fact, current BIND implementations will ignore such records, possibly leading to a lame delegation." --------------------------------------------------------------------- Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
