Slaves and views

Joseph S D Yao jsdy at tux.org
Fri Mar 4 23:54:41 UTC 2011


On Fri, Mar 04, 2011 at 11:46:05AM -0500, John Wobus wrote:
...
> Can a zone file a slave in one view and the same zone file
> be served by another view?
...


I assume you mean something like this:

view "here" {
	match-clients { "here"; };
	zone "example.us" {
		type slave;
		file "data/zone.example.us";
		masters { 20.20.20.20; 30.30.30.30; };
	};
};
view "rest" {
	match-clients { any; };
	zone "example.us" {
		type master;
		file "data/zone.example.us";
	}
};

I've tried this - unsuccessfully.  The basic problem is, if you declare
both "slaves", then the second view tries to update it around the same
time as the first, and the file gets munged.  If you declare one
"slave" and the other "master", how does the "slave" view let the
"master" view know when the zone is updated?  Nothing like serving stale
data!

view "here" {
	match-clients { "here"; };
	zone "example.us" {
		type slave;
		file "data/here/zone.example.us";
		masters { 20.20.20.20; 30.30.30.30; };
	};
};
view "rest" {
	match-clients { any; };
	zone "example.us" {
		type slave;
		file "data/rest/zone.example.us";
		masters { 20.20.20.20; 30.30.30.30; };
	}
};

The above does two zone transfers, which is a waste [but not a big one,
one hopes!].  But I couldn't figure out any syntax - without using the
extra IP addresses that you also wish to avoid - for doing this.  Using
extra IP addresses, of course, each view listens on a different IP
address, the second view slaves its copy from the slaved copy on the
first, and the first view NOTIFYes the second when it transfers the
master copy "out there" to its slaved copy.  Still two zone transfers,
but one is internal.

To do what you want, one would have to separately abstract the zone
transfer mechanism and the serving mechanism.  Which would not be a bad
idea at all:

// NOTE: the following is ramblings of my feverish mind and not anything
// supported by any existing parser or other software

view "here" { match-clients { "here"; }; allow-query { "here"; }; };
view "rest" { match-clients { any; }; };

zone "static.us" {
	// sourced once
	// served by all views
	type master;
	file "data/zone.static.us";
}
zone "example.us"
	// sourced once
	// served by all views
	type slave;
	file "slaved/zone.example.us";
	masters { 20.20.20.20; 30.30.30.30; };
	// if it were served differently in another view
	// or sourced differently in a third view
	// we would have that info in a 'view' statement.
}
zone "split.us" {
	// sourced and served differently in two views
	view "here" {
		match-clients { !ext-tsig-key; int-tsig-key; "here"; };
		allow-transfer { int-tsig-key; };
		type slave;
		file "slaved/here/zone.example.us";
		masters { 10.10.10.10; 10.20.30.40; };
	}
	view "rest" {
		match-clients { !int-tsig-key; ext-tsig-key; any; };
		allow-transfer { ext-tsig-key; };
		type slave;
		file "slaved/rest/zone.example.us";
		masters { 20.20.20.20; 30.30.30.30; };
	}
}
zone "internal.us" {
	// sourced and served only in one view
	view "here" {
		type master;
		file "data/internal.us";
	}
}


--
/*********************************************************************\
**
** Joe Yao				jsdy at tux.org - Joseph S. D. Yao
**
\*********************************************************************/



More information about the bind-users mailing list