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