Restricting access & keeping identical data across views
Jon A.
continualuse2u at gmail.com
Wed Mar 28 01:16:57 UTC 2012
I'm looking for a best practice to keep zone data across multiple views on
multiple servers sync ... Right now I'm struggling with updates making it
to some zones, and not others. Any and all help welcome. I realize this
isn't a simple configuration so even partial answers may help me get things
fixed. I'm greatful for any help!
Questions, given configuration information below:
1) Is there a better practice to serve 100% the same authoritative data
in two views, but block recursion, cache use, and out of zone data?
-- eg, can i eliminate one of my views (mypublicboxes and others)
below and match the functionality?
2) What's the best way to keep zone data synced between zones on the
same box?
-- I am using the server line in one view to specify the key for
my other view when notifying (per faq)
-- should that second view's zones be defined as slaves, or can i
get away with using the same include and zone file, just using notify to
reload it (which seems to work)?
3) What's the best practice to keep an identical view set on a 100%
slave server?
-- I am using rndc addzone to add the zone to each view,
specifying the key that matches the zone in the masters definition
-- zone a.example.com {type slave; file
"slaves/myprivateboxes/a.example.com"; masters { xxx.xxx.xxx.xxx key
inside-key;}; };
-- zone a.example.com {type slave; file
"slaves/mypublicboxes/a.example.com"; masters { xxx.xxx.xxx.xxx key
outside-key;}; };
-- zone a.example.com {type slave; file "slaves/others/
a.example.com"; masters { xxx.xxx.xxx.xxx key others-key;}; };
Example Configuration
---------------------------------
* Given three views on one server as defined below
- All three views serve my public zones
- The first view serves some additional zones containing just rfc1918
addresses [not available to everyone lest i pollute dns]
- The only difference between the last two views (the two without
private addressing) is in what work we are willing to do/answer based on
the querying client
* Two servers exist, one with the master data as defined below, and one
that slaves *everything* off the master by way of notifies and the rndc
addzone lines above.
view "myprivateboxes" {
match-clients { key inside-key; pvt-nets; };
# Support delivering notifications to the mypublicboxes view
server x.x.x.x { keys notify-outside-key; }; // x.x.x.x is
MY ip, because i'm telling the second view on the same box
recursion yes; //
Allow recursive lookups
allow-query { my-networks; localhost; }; // All my
networks can query this view
allow-query-cache { my-networks; localhost; }; // All my networks
can query this view's cache
allow-transfer { authorized-nameservers; }; // allow
nameserver transfers as necessary
include "include/named.hint.zone"; // load root
zone hints
include "include/named.rfc1912.zones"; // load rfc1912
zones
include "include/myprivate.zones";
include "include/mypublic.zones";
}
view "mypublicboxes" {
match-clients { key outside-key; key notify-outside-key; pub-nets;
};
recursion yes; //
Allow recursive lookups
allow-query { my-networks; localhost; }; // All my
networks can query this view
allow-query-cache { my-networks; localhost; }; // All my networks
can query this view's cache
allow-transfer { authorized-nameservers; }; // allow
nameserver transfers as necessary
include "include/named.hint.zone"; // load root
zone hints
include "include/named.rfc1912.zones"; // load rfc1912
zones
include "include/mypublic.zones";
}
view "others" {
match-clients { any; key others-key; }; // Any client
that didn't match other views ends up here
recursion no; //
No recursion
allow-query { any; }; // Any
client can do individual query requests
allow-query-cache { none; }; // No
external client can use our cache
allow-transfer { authorized-nameservers; }; // allow
nameserver transfers as necessary
# No out of zone data
additional-from-auth no;
additional-from-cache no;
include "include/mypublic.zones";
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120327/560e3bbf/attachment.html>
More information about the bind-users
mailing list