cname quick question

Jim Reid jim at rfc1035.com
Wed Feb 28 08:20:42 UTC 2001


>>>>> "Tal" == Tal Dayan <tal at zapta.com> writes:

    Tal> As a user I understand more on the need side and less on the
    Tal> solution side.  With the increasing trend of outsourcing,
    Tal> co-branding, and partnership on the Internet, it is more and
    Tal> more common that we, DNS users, need to specify domain name
    Tal> to a server that is not in our control. In many cases, we can
    Tal> solve this by using a CNAME record. However, when the
    Tal> aliasing is for the domain itself, we do have a problem. The
    Tal> simple 'solution' of using an A record works for a while
    Tal> until the other party changes their IP for one reason or
    Tal> another. When this happens, your service is practically down
    Tal> until you diagnose the problem, change the A record and let
    Tal> it propagate.

How does a having CNAME pointing at the wrong place (and cached by
other name servers) solve this problem? Please give one example where
having a CNAME for the domain name would offer an advantage that could
not be provided using an A record instead. Think before you
answer. And why are you using an outsourcing provider who can't (a)
provide a reliable service; (b) provide adequate change notification
to its customers; (c) meet an obvious demand that should be in the
simplest service level agreement? You do have SLAs with these
providers, right? They do specify change windows and notification
procedures, don't they? Doesn't this ring any alarm bells for you?

Don't you think it might be simpler and more effective to sort those
procedural and contractual problems - ie take you business elsewhere -
than force a global change to the DNS protocol which affects every
implementation is use right now? Doesn't the whole idea of this give
you a clue how ridiculous your suggestion is? "I use an unreliable
outsourcing provider with no SLA and it causes me problems. Let's
change a fundamental DNS RFC and break every DNS implementation that's
been deployed so I can use a stupid but unnecesary trick to work
around that provider's limitations. Even though I've been told there
are other perfectly effective work arounds that won't violate RFC1034
which could be used instead."


More information about the bind-users mailing list