cname quick question

[Mark.Andrews at nominum.com]

	Eric,
	      "CNAME at top of zone" is a subset of "CNAME and other data".

	Mark

> Mark, it should be made clear here that "CNAME and other data" is not the
> issue in question.  It is CNAME's at the zone top.
> 
>             - Erik
> ----- Original Message -----
> From: <Mark.Andrews at nominum.com>
> To: "Erik Aronesty" <erik at primedata.org>
> Cc: "Tim Maestas" <tmaestas at dnsconsultants.com>; <bind-users at isc.org>
> Sent: Wednesday, February 28, 2001 7:43 PM
> Subject: Re: cname quick question
> 
> 
> >
> > >
> > > Tim,
> > >
> > > 1 - All the resolvers on the planet already support this feature - if
> they
> > > follow the RFC.  Also, the feature is "backward compatible" - so you
> don't
> > > have to make changes to servers - if you don't want to.  Finally, BIND
> > > versions 4 though 8.2.2 supported this feature - so most servers already
> > > support it anyway.
> >
> > ISC has NEVER supported "CNAME and other data".  It was logged
> > as a error in the BIND 4.8 code and all version that ISC released.
> > The error condition has slowly got stronger over the years.
> >
> >  8.2-T1A
> >
> >  428.   [bug]           CNAME and other data is now a hard error.
> >
> >  i.e. the server stops answering authoratatively and refuses to transfer
> >  the zone.
> >
> >  8.2.3
> >
> > 1068.   [bug]           purge the zone from memory if an error is detected
> >                         on loading.
> >
> > There is no version of named shipped by any vendor ever that
> > did not complain about "CNAME and other data".  It just took
> > stopping serving the zone for you to wakeup and see that you
> > had a problem.
> >
> > >
> > > 2 - No you can't expect companies with real network infrastructures to
> 'tell
> > > you' when their IP addresses change.  That's ridiculous.  Especially if
> the
> > > firm has 10,000+ users.
> >
> > Since we are talking about host companies providing a
> > service to another company and that said host companies
> > should know that the only way there customers can legally
> > redirect taffic to there servers is by adding A records
> > (they are aware of the virtual hostnames and are aware or
> > should be aware of the registry restictions) yes I can and
> > do expect them to inform their customers when the address
> > changes.  I also expect them to perform the change such
> > that there is not a flag day where all the DNS entries must
> > be changed but for there to be a period of overlap.
> >
> > >
> > > 3- I have resorted to creating a "com." zone on my authoritative only
> > > servers, and then placing the CNAMEs in the "com." zone.  This works,
> but
> > > it's a horrible hack.
> >
> > Which doesn't work other than not issuing a error message.
> >
> > >
> > > 4- ISC changed the functionality of their system in a maintenance
> release.
> > > They did not provide a workable alternative - and did not consider the
> > > change with mentioning on their web site.
> >
> > All 8.2.3 did was stop serving the zone that it had detected
> > errors for.  It was already detecting and reporting the
> > error.
> >
> > Do you want to know why BIND 8.2.3 refuses to serve the
> > zone?
> >
> > The reason is that there were too many DNS administators
> > failing to correct the reported errors thereby creating
> > lame servers which cause problems for everybody else.
> >
> > You obviously didn't care about the problems you were
> > causing your clients or else you would have fixed your
> > zone before this.
> >
> > >
> > > 5- They could have waited 1 or two revs, at least until DNAME's were
> ready,
> > > to make such a impacting change.
> > >
> > > 6- There is absolutely no semantic reason to restrict CNAMEs from a
> > > particular "node" in a tree of recursive information because of the
> > > structure of some "file on disk".  IE: DNS is not BIND.  If the resolver
> > > algorithm supports the feature - then it was probably a failure in the
> RFC
> > > to elucidate a special case.
> > >
> > >             - Erik
> > >
> > >
> > > ----- Original Message -----
> > > From: "Tim Maestas" <tmaestas at dnsconsultants.com>
> > > To: <bind-users at isc.org>
> > > Sent: Wednesday, February 28, 2001 12:33 AM
> > > Subject: RE: cname quick question
> > >
> > >
> > > >
> > > >
> > > > > 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.
> > > >
> > > > In my opinion, if you have outsourced to a company that
> > > > doesn't have the common courtesy to inform you that
> > > > the server that is hosting your site is being re-addressed,
> > > > then you are being ripped off, whatever you are paying.  It
> > > > seems to me that it is *far* less work to insure that you
> > > > have an agreement with your hosting providor that states
> > > > that you will be notified of any IP changes to the server
> > > > hosting your site than to modify all of the DNS servers on the
> > > > internet and re-write the RFC's.
> > > >
> > > > Any issues that make it impractical to use an A record on
> > > > the zone name, in my opinion, are procedure/vendor-relationship
> > > > based, rather than strictly technical.
> > > >
> > > > -Tim
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > --
> > Mark Andrews, Nominum Inc.
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com
> >
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com