Make aliases that don't transfer?

Jeffrey Reasoner jeff.reasoner at mail.hccanet.org
Tue Apr 3 13:31:53 UTC 2007


On Tue, 2007-04-03 at 08:45, Jeff Lightner wrote:
> It's "a hack" - ok I'll buy that though I inherited the setup.  Is it a
> bad idea though?  Should I really make separate zone files for every
> domain when all we really use is a single web site to service them all?

Probably not bad at all if you're not having problems with the current
setup. 

> 
> We have a single domain for email and all other purposes.   It is only
> because we have multiple business entities that we use separate domain
> names (essentially to insure people looking for us find our main web
> site).  What is the downside to using such "a hack"?   

If the other domains are used as you've described, the actual zone
contents are probably minimal and basically static. Assuming this it
true, and you really want to eliminate the transfers, you could
make each of your servers masters just for these 'other' zones, and
leave the master/slave config intact for the main domain.
Of course you'd then have to update these zones manually (or using rsync
as you mention below) on the new masters, so it wouldn't scale. I also
doubt that there would be much practical benefit in doing this. I
believe it would achieve what you're asking however.

> I can live with the multiple zone transfers (especially given that if I
> DID separate into individual zone files I'd still have multiple zone
> transfers) but was just curious if there was a way to configure named
> not to transfer a given zone file.   Doing rsync wouldn't turn off zone
> transfers.  I'd still want my main zone files (the unaliased ones) to
> transfer.   Are you implying it is all or nothing?  If so why do I need
> to configure each zone?
> 
> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> Behalf Of Kevin Darcy
> Sent: Monday, April 02, 2007 7:08 PM
> To: bind-users at isc.org
> Subject: Re: Make aliases that don't transfer?
> 
> Always remember that the use of a single file as the source data for 
> multiple zones is a *hack*. named loads that data as separate zones, and
> 
> that's the way they are viewed in protocol terms, including zone 
> transfers -- as separate zones. As John Wobus pointed out, if you want 
> to treat *files* as *files* instead of *zones*, you could use an 
> out-of-band mechanism, such as rsync, to replicate your data. Some 
> caveats of doing things that way:
> 1) If you care about security at all, you'd want to set up a trust 
> relationship so that no-one can spoof the data,
> 2) You might need to open up additional ports in your firewall(s), if
> any,
> 3) You'd need some way of getting the "slave" nameservers (defined as 
> "master" for the zone(s) in question) to reload/refresh the data 
> whenever it changes since, unlike with AXFR/IXFR, this is not automatic.
> 
>  
> 
>                            - Kevin
> 
> Jeff Lightner wrote:
> > We have multiple domains that are aliased to our main domain.   This
> > works fine.
> > I've noticed on doing zone updates and transfers from master to slave
> > that it essentially transfers the alias zone file for EACH aliased
> > domain.   This seems unnecessary since the zone file is a single one
> for
> > all these domains so it seems the transfer for the first alias should
> be
> > sufficient.   I was curious how I would insure it only transferred
> once.
> > Is there a type other than "master" or "slave" or should I just take
> out
> > the "allow transfer" line?   I don't want to delete the entry entirely
> > from the slave for obvious reasons.
> >
> > Example from my master:
> > zone "4waters.com" {
> >         type master;
> >         file "watercom-aliases";
> >         allow-transfer { watercom; };
> > };
> >
> > >From my slave:
> > zone "4waters.com" {
> >         type slave;
> >         file "watercom-aliases";
> >         masters { 10.0.21.21; };
> >         allow-transfer { watercom; };
> > };
> >
> >
> >
> >
> >
> >   
> 
> 
> 



More information about the bind-users mailing list