Make aliases that don't transfer?

[Mark Andrews]

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

	The zone declaration tells name what namespaces it is serving.
	It also set the $ORIGIN when the master file is read in.  This
	allows @ to be expanded appropriately for each zone.

	Note.  You shouldn't use the same file for the slaves.  Each file
	*must* be unique.  When named re-starts there is not way to make
	sure the file contents match the 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; };
> > };
> >
> >
> >
> >
> >
> >   
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org