CNAMES across zones

Kevin Darcy kcd at daimlerchrysler.com
Thu Oct 26 02:47:10 UTC 2000


Alexander Ottl wrote:

> I'm so glad somebody brought this up. Kevin does mention the restriction
> that the same organization should control both zones. Now I do have a
> CNAME record in my name server where that is not the case.
> www.some.domain.             IN      CNAME   www.someother.domain.
>
> Lo and behold I get this message in the name servers log file:
> 25-Oct-2000 19:16:30.982 unapproved recursive query from
> [194.246.96.81].53 for www.someother.domain
>
> That's because my name server is an authoritative server for the CNAMEs
> zone but not for the CNAMEs targets zone and it doesn't allow recursive
> queries except from customers. But I wonder: Do my name servers really
> receive explicitly recursive queries from other name servers or is this
> because of special treatment of CNAMEs that somehow turns a
> non-recursive query into a recursive one?

I think some crappy nameserver implementations *always* send recursive queries.
Anti-social, if you ask me.

It almost makes me wish there was a way to *refuse* recursive queries selectively
in BIND. If this became common practice, then maybe those implementations would
get fixed.

> Now before I start a holy war on CNAMEs I should mention that this CNAME
> is there for a reason. The IP address of the target is about to change
> but of course the A record is not under my control and a synchronized
> change would be nice.
>
> My question is this. Is there a way out of this dilemma? Will resolvers
> fail to get the IP address?

A nameserver will go and query the target of the CNAME if it needs to.

If a stub resolver is pointed to your nameserver without permission... well, they
get what they deserve.


- Kevin

> Kevin Darcy wrote:
> >
> > If different organizations own the CNAME's zone versus the CNAME target's
> > zone, then there is a bit of a co-ordination issue in order to avoid dangling
> > CNAMEs, chained CNAMEs or looped CNAMEs. Also, if a server has a CNAME entry
> > in its cache or authoritative data, but no entry for the CNAME's target, then
> > it will have to perform at least one extra query of its own to resolve the
> > query for its recursive clients, which can be slightly inefficient.
> >
> > But in a reasonably-configured environment, where the same organization
> > controls both zones, or has maintenance tools which perform sanity checks to
> > avoid CNAME loops and/or chains, or dangling CNAMEs, and where all of the
> > authoritative servers for the CNAMEs' zones are also authoritative for the
> > CNAMEs' targets' zones, cross-zone CNAMEs shouldn't be a problem at all. And,
> > in almost all infrastructures, the benefit of having only 1 A record to
> > change instead of potentially dozens or even hundreds, greatly outweighs the
> > cost.
> >
> > - Kevin
> >
> > josephc at etards.net wrote:
> >
> > > OK, I have somehow managed to start a holy war between sysadmins here
> > > regarding CNAMES across zones.
> > >
> > > On the oneside you have people that believe that is a terrible thing to
> > > do,
> > > and others that see nothing wrong with it.
> > >
> > > For example: (assuming this is fubars zone file)
> > >
> > > www.fubar.net.          IN      CNAME   www.fubar.com.
> > >
> > > The best example would be if a company had fubar.com, fubar.net, and
> > > fubar.org as well as 100 other domains that they all wanted to point to
> > > the
> > > same host.
> > >
> > > While 'a' records pointint to x.x.x.x would work, should that IP ever
> > > change, or if it changes often, it would be a pain to update every zone
> > > with the new IP. But if say fubar.com was the only domain that pointed www
> > > to the IP via an 'a' record, then all the other domains could CNAME www
> > > to
> > > www.fubar.com. There would be no CNAME's pointing to other CNAME's.
> > >
> > > The only consequence I can see is a higher load on the DNS server. Are
> > > there any other known porblems with this setup?
> > >
> > > thanks
> > >
> > > -joe






More information about the bind-users mailing list