Views and zone delegation

Kevin Darcy kcd at daimlerchrysler.com
Tue Jan 28 21:46:18 UTC 2003


Rusty Draper wrote:

> Hello,
>
> I recently had a tough time trying to re-configure a name server that provides forwarding for an internal domain, to use views.
>
> I wrapped up my internal zones and created acl's for the internal IP space and then wrapped up the external zone for public consumption, with match-clients set to "any";.
>
> The symptom was with the views enabled, all queries were deferred to my parent.  The parent delegates authority to the above mention server for the sub-domain it's trying to serve.
>
> With the "view" and "match-clients" statements commented out, the server worked, but internal IP space was visible externally, which is what I'm trying to avoid.
>
> I was successful in setting this type of bind configuration on a new domain.  The scenario described here is already established.
>
> ~R
>
> //
> // ACL's are used to restrict recursive access to the name
> // servers.  Our desire is to restrict recursive queries to
> // our internal systems only.
>
> //
> // Internal GEO-1 resolvers
> //
>
> acl "geo-1-prod-internal" {
>         // 10.135.16.0/24;
>         10.135.16.88;
> };
>
> //
> // External GEO-1 external IP space
> //
>
> acl "geo-1-prod-external" {
>         XX.XX.XX.128/26;
> };
>
> //
> // External GEO-1 staging IP space
> //
>
> acl "geo-1-staging-external" {
>         YY.YY.YY.0/27;
> };
>
> //
> // Future External Corporate IP space
> //
>
> acl "geo-1-corporate-external" {
>         ZZ.ZZ.ZZ.32/27;
> };
>
> options {
>                   directory  "/some-zone/prod/named";
>                   pid-file   "/var/named/named.pid";
>         //
>         // Listen only on our own interfaces
>         //
>         listen-on {
>                 127.0.0.1;
>                 10.135.16.88;
>                 // 10.135.16.17;
>                 YY.YY.YY.6;
>         };
>
>         allow-recursion {
>                 "geo-1-prod-internal";
>                 "geo-1-staging-external";
>                 10.135.16.18;
>         };
> };
>
> logging {
>         //
>         // Add some custom channels.
>         //
>         channel geo-1_syslog {
>                 syslog daemon;
>                 //
>                 // Debug messages will not be sent to syslog, so
>                 // there is no point to setting the severity to
>                 // debug or dynamic, use the lowest syslog level:  info.
>                 //
>                 severity info;
>         };
>         channel geo-1_logfile {
>                 //
>                 // This can be adjusted depending on what level
>                 // of logging is desired.  Right now we need
>                 // to see plenty as we are logging attempts
>                 // to update our DNS
>                 //
>                 file "/var/named/named.log" versions 30;
>                 severity dynamic;
>                 print-category yes;
>                 print-severity yes;
>                 print-time     yes;
>         };
>         channel geo-1_debug {
>         //
>         // Debugging channel
>         //
>                 file "/var/named/named.debug" versions 30;
>                 severity debug 3;
>                 print-category yes;
>                 print-severity yes;
>                 print-time     yes;
>         };
>
>         //
>         // Set up categories to use the channels created above
>         //
>         category security {
>                 geo-1_syslog;
>                 geo-1_logfile;
>                 // geo-1_debug;
>         };
>         //
>         // Turning off query logging.  Interested
>         // in security and zone transfers
>         //
>         category queries {
>                 geo-1_logfile;
>                 // geo-1_debug;
>         };
>
>         category notify {
>                 geo-1_logfile;
>         };
>         category xfer-out {
>                 geo-1_logfile;
>         };
>         category default {
>                 geo-1_syslog;
>                 geo-1_logfile;
>         };
>         category lame-servers {
>                 geo-1_logfile;
>         };
> };
>
> //
> // External View
> //
>
> // view "public-view" {
> //
> // Match clients
> //
>         // recursion no;
>         // match-clients {
>          //     any;
>         // };
>
>         zone "." in {
>                 type hint;
>                 file "root/named.root";
>         };
>
>         zone "0.0.127.in-addr.arpa" in {
>                 type master;
>                 file "master/reverse/db.127";
>          };
>
>         zone "barbaz.net" in {
>                 type master;
>                 file "master/forward/barbaz.net";
>                 allow-transfer {
>                         YY.YY.YY.3;
>                         XX.XX.XX.141;
>                 };
>         };
>
> // };
>
> //
> // Implementing internal view for GEO-1
> // All internal subnets and zones are represented here.
> // The match-clients statement locks down usage to the PCS VLAN
> // (Admin channel)
> //
> // red - 2003/01/21
>
> //
> // geo-1-internal for all private non-routable 10. IP space
> //
>
> // view "private-view" {
> //
> ////
> //// Match clients to our PCS VLAN.
> ////
> //      match-clients {
> //              geo-1-prod-internal;
> //              // 10.135.16.17;
> //              // 10.135.16.18;
> //              // 10.135.16.88;
> //      };
>
> //      allow-recursion {
> //              geo-1-prod-internal;
> //      };
>
> //      zone "." in {
> //              type hint;
> //              file "root/named.root";
> //      };
>
> //      zone "0.0.127.in-addr.arpa" in {
> //              type master;
> //              file "master/reverse/db.127";
> //      };
> //
> ////
> //// List out our zones.  Since we are keeping just private IP space
> //// here and we are not making the 'geo-1.prod.some-zone.com' zone visible
> //// externally, no need to keep separate zone files as in NRTJP.
> ////
> ////
> //
> //      zone "geo-1.prod.some-zone.com" in {
> //              type master;
> //              file "master/forward/geo-1.prod.some-zone.com";
> //      };
>
> //
> //// Test zone to figure out what's wrong
> ////
> //
>
> //      zone "test.prod.some-zone.com" in {
> //              type master;
> //              file "master/forward/test.prod.some-zone.com";
> //      };
>
> //
> ////
> //// PCS VLAN (Admin Channel)
> ////
> //
> //      zone "16.135.10.in-addr.arpa" in {
> //              type master;
> //              file "master/reverse/db.16.135.10";
> //      };
> //
> ////
> //// HACMP/AIX Clustering VLAN
> ////
> //
> //      zone "52.135.11.in-addr.arpa" in {
> //              type master;
> //              file "master/reverse/db.52.135.11";
> //      };
> //
> ////
> //// ?? VLAN
> ////
> //
> //      zone "52.135.10.in-addr.arpa" in {
> //              type master;
> //              file "master/reverse/db.52.135.10";
> //      };
> //};

Well, views are matched in order, and it looks like you have the "match-clients { any; };" view ahead of the other one, so basically the other view is never matched.

                                                                                                                                            - Kevin




More information about the bind-users mailing list