cnames...

[Kevin Darcy]

Tal Dayan wrote:

> Hi Derek,
>
> DNS is a technology whose purpose is to serve users. Same
> goes to virtually any technology.
>
> The role of the users is to convey their needs. The challenge of the
> technology experts is to make sure the technology meets them the best.

Abrogating the "CNAME and other data" rule would make life *harder* for DNS
administrators, assuming they were to provide the same level of service to
their end-users. This is because, to provide reliable service, they would have
to keep two sets of data completely in synch for each CNAME. Also, the
additional load that such a change would place on caching servers would lead to
resource problems, having to purchase and maintain extra machines, etc.

Is all of this *really* worth the convenience of being able to create a
CNAME at the zone top? Even if the migration were painless (which obviously it
wouldn't be), I think the detriment outweighs the benefit, long-term. The issue
was already considered back when RFC 1034 was written, and it was decided to
institute the rule. Nothing has *qualitatively* changed that assessment. The
only thing that has changed is the sheer volume of domains and query traffic.
Which means that the detriments and benefits are simply magnified versions of
what they were in 1987. If we were to do it all over again, I'm confident that
either a) some creative alternative would be found to replace CNAMEs altogether
or b) the same rule would be re-instituted.

> So, before we dismiss the issue by
> 'if-it-is-not-there-than-don't-ask-for-it',
> let's first recognize that removing the
> 'CNAME-everywhere-except-for-domain-name'
> limitation will benifit users. Then we can move forward and look for ways to
> address it.

If by "users" you mean DNS admins in this context, I don't think there is any
net benefit, as I describe above.

As for "users", i.e. end-users, I doubt that they really care one way or the
other, as long as they can reliably use names to connect to services. So from
their point of view, the issue is rather moot...


- Kevin


> > -----Original Message-----
> > From: Derek J. Balling [mailto:dredd at megacity.org]
> > Sent: Sunday, March 04, 2001 11:42 AM
> > To: Tal Dayan
> > Cc: Brad Knowles; comp-protocols-dns-bind at moderators.isc.org
> > Subject: RE: cnames...
> >
> >
> > Fine, users may like it differently.
> >
> > However, since DNS is a TECHNICAL issue, and not a "market-driven" one, if
> > the users feel compelled to make it work that way, they must (a) learn the
> > technical issues, and then (b) address them, in order, and finally (c)
> > publish a standards-track RFC and hope for acceptance by others.
> >
> > D
> >
> > At 10:54 AM -0800 3/4/01, Tal Dayan wrote:
> > >Hi Brad,
> > >
> > >My main point is that the singular restriction of
> > >CNAME-everywhere-except-for-the-domain-itself of the standard
> > and/or BIND is
> > >not the prefered behavior from a user viewpoint but a result of some
> > >historic and technical issues.
> > >
> > >Let's recognize this first.
> > >
> > >Tal
> > >
> > >> -----Original Message-----
> > >> From: Brad Knowles [mailto:brad.knowles at skynet.be]
> > >> Sent: Sunday, March 04, 2001 2:49 AM
> > >> To: Tal Dayan; Kevin Darcy; comp-protocols-dns-bind at moderators.isc.org
> > >> Cc: erik at primedata.org
> > >> Subject: RE: cnames...
> > >>
> > >>
> > >> At 11:21 PM -0800 3/3/01, Tal Dayan wrote:
> > >>
> > >> >  Without getting to into the technical details of BIND and DNS
> > >> (which I am
> > >> >  not familiar with), I think the server should return a
> > >> response depending on
> > >> >  what the client looking for. It is that simple. If the client
> > >> wants to map a
> > >> >  name to an IP, it should return an A record (if any) or
> > will refer the
> > >> >  client to the right hand of the CNAME. If the client is looking for
> > >> >  information about the domain itself, it should return the soa,
> > >> ns etc. If
> > >> >  the client is looking for a mail server mapping, it should
> > >> return the MX
> > >> >  record.
> > >>
> > >>    No, it's not that simple.  The RFCs explicitly say that a CNAME
> > >> cannot occur with other data at that node, and anything else is an
> > >> error.  The problem is that not sufficiently enforcing this rule in
> > >> the past has gotten us into the situation we're in now, and we simply
> > >> cannot afford to do this any longer.  Indeed, we would all have been
> > >> much better off if this kind of behaviour was properly enforced long
> > >> ago.
> > >>
> > >>
> > >>    If you want to change this behaviour back, then I suggest you go
> > >> try to get the RFCs modified to suit.  When that happens, and your
> > >> modifications become the next "Recommended Standard" in this area,
> > >> then you can be pretty well assured that BIND will follow suit.
> > >>
> > >>    However, until then, don't try to argue something without
> > >> understanding the RFCs and the technical details involved.  A lawyer
> > >> that tried to argue a case in court by first openly stating their
> > >> ignorance of the law and then blatantly disregarding that law
> > >> wouldn't have any more success there than you will here by trying to
> > >> argue this matter using the methods you've attempted to use so far.
> > >>
> > >>    Understand the RFCs, understand the technical reasons behind the
> > >> RFCs, or don't bother trying to argue the point.  Otherwise, you're
> > >> just wasting your breath and everyone's time.
> > >>
> > >> --
> > >> ======================================================================
> > >> Brad Knowles, <brad.knowles at skynet.be>
> > >>
> >
> > --
> > +---------------------+-----------------------------------------+
> > | dredd at megacity.org  | "Conan! What is best in life?"          |
> > |  Derek J. Balling   | "To crush your enemies, see them        |
> > |                     |    driven before you, and to hear the   |
> > |                     |    lamentation of their women!"         |
> > +---------------------+-----------------------------------------+
> >