cname quick question

[Tal Dayan]

Hi Jim,

Thanks for responding to my call.

There are two aspects for this CNAME issue. One is the need and the other is
the technical challenge to find a solution without breaking the existing
system.

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

As for the technical side of the solution, this is not my area f experties
and I don't try to advocate this technical solution or another. What I am
trying to do is to challenge the smart people of this list, and I am sure
you are one of them, to try to look for a creative solution that will work
well rather than to give it up so quickly.

At minimum, the solution should allow to run a modified BIND server (e.g. by
enabling an optional configuration switch) that when working alone or with
modified secondary backup servers, does not break the resolution of the DNS
servers/clients.

It is that simple. Just a need and a desire for a solution. Same thing when
our users comes to us when they face a need with our services.

Tal



> -----Original Message-----
> From: Jim Reid [mailto:jim at rfc1035.com]
> Sent: Tuesday, February 27, 2001 4:36 PM
> To: Tal Dayan
> Cc: bind-users at isc.org
> Subject: Re: cname quick question
>
>
> >>>>> "Tal" == Tal Dayan <tal at zapta.com> writes:
>
>     Tal> Hi Cricket.
>
>     Tal> If I understand it correctly, the change itself is
>     Tal> technically feasible and the standards can be modified, but
>     Tal> the main trick is to find a modification that will be
>     Tal> interoperability with the existing DNS servers (whether BIND
>     Tal> or others).
>
> Indeed. But Cricket was being nice by just explaining what needed to be
> done. Presumably he hoped you'd realise the enormity of what you were
> advocating. I don't think you have any idea of the amount of work your
> proposal would entail assuming you could convince anyone to take it
> seriously. Even getting a simple non-controversial protocol change
> through IETF and adopted as a standard is non-trivial. Then there's
> the question of implementation and deployment. [How many sites still
> run BIND4 years after it was declared dead?] And not breaking anything
> in the tens of millions of hosts and applications with working DNS
> software that are on the net right now. You probably have a better
> chance of success at meeting Elvis.
>
>     Tal> So here is a challenge for you and the other DNS gurus on
>     Tal> this list. Can you come with a creative idea how to modify
>     Tal> BIND (and the standards) such that new servers will allow a
>     Tal> CNAME for domain names without breaking interoperability with
>     Tal> existing servers.
>
> I'm going to be brutally blunt. This is like hoping someone would
> teach an elephant to ballet-dance. It theoretically could be done, but
> what's the point? What practical purpose does it serve in the real
> world? Why should anyone care?
>
> IIUC, your request for changing RFC1034 - which has been a cornerstone
> of the DNS since it was written in 1987 - was for the flimsiest of
> reasons. You wanted to have a CNAME for your domain name which points
> at the host providing your web server. There are other ways of
> achieving the same end result in the DNS which do not involve having a
> CNAME. These have been explained many times in this list. Consult the
> archives. [Hint: you can have A records for your domain name.] If this
> is your only motivation for changing the CNAME and other data rule, I
> suggest you don't waste any more time on the idea and do what the rest
> of the world does when they want a URL like http://somedomain.com to
> end up directing some browser to the web server for somedomain.com.
>
> There's no need to turn the world upside down for something so
> trivial. RFC1034 is not broken. It does not need fixing. If it did, it
> would have been superseded long before now. The fact that it hasn't
> should tell you something.
>