Make aliases that don't transfer?

[Mark Andrews]

> Either I didn't understand your last line or I didn't explain the setup
> here correctly.   There is only one zone file for the aliases.  It
> doesn't matter if any of the subsequent transfers are OK from that
> standpoint because it doesn't create multiple zone files even though it
> shows multiple transfers.  It is a single zone file and that is only
> that single zone file that transfers even if it transfers it multiple
> times.
> 
> Perhaps by RFC it "should" be individual zone files.   However since it
> has been running this way for a few years it's obvious that there no
> "must" to it.  I'm not truly averse to creating multiple zone files if
> that is truly required - as noted though I'd like to know (other than
> not meeting RFCs) what the downside to having it this way is.

	You mean you havn't seen the down side.  named detects the
	error and re-transfers the zone on restart.  It has to do
	this for every (bar 1) slave zone that is using the common
	file.  This defeats the purpose of writing the contents to
	disk which is to allow slave zones to be loaded even when
	the master is unreachable.

	The reason for that is that named writes the $ORIGIN into
	the zone file.

	The reason that you can share the master file is that there
	isn't a $ORIGIN in it.

 
> -----Original Message-----
> From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org] 
> Sent: Tuesday, April 03, 2007 9:09 AM
> To: Jeff Lightner
> Cc: Kevin Darcy; bind-users at isc.org
> Subject: Re: Make aliases that don't transfer? 
> 
> 
> > 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
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org