cname quick question

Mark.Andrews at nominum.com Mark.Andrews at nominum.com
Thu Mar 1 00:43:39 UTC 2001


> 
> 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


More information about the bind-users mailing list