cname quick question

[Tal Dayan]

Hi Jim

Thanks for clarifying your point.

On the need side, I respectfully disagree with you that CNAME records are a
'stupid but unnecessary trick'. Luckily enough, the Founding Fathers of DNS
did recognize the usefulness of aliasing and provided us with CNAME records.

As for the solution side, I understand that you already gave up on finding a
creative solution that will remove the singular restriction of 'no CNAME for
an host whose name is the domain itself' that will be fully compatible with
existing DNS servers.

I hope that other DNS gurus on this list will take this not as an attack on
a great software which BIND is but as an intellectual challenge to provide
DNS users around the world with an even better tool.

Tal

> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
> Behalf Of Jim Reid
> Sent: Wednesday, February 28, 2001 12:21 AM
> To: Tal Dayan
> Cc: bind-users at isc.org
> Subject: Re: cname quick question
>
>
> >>>>> "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."
>
>