Views / Split domains and secondary servers

James A Griffin agriffin at cpcug.org
Wed Feb 28 22:53:28 UTC 2001


"Robert E. Van Cleef" wrote:
> 
> Linolil from deja of com stated
> 
> Linolil> I have looked through the postings and really cannot find a concise
> Linolil> answer to how you would implement a split view of our domain, which
> Linolil> includes the use of private IP numbers.
> Linolil>
> Linolil> What seems to be the recommended solution is one primary, but separate
> Linolil> secondaries to keep from mingling the public/private IP numbers.
> Linolil>
> Linolil> Is that a correct summarization.
> 
> That is the way I read the postings.  Anyone able to clarify or point
> to some documentation on how to setup a split DNS domain with Views?
> One primary with separate secondaries for internal/external seems to
> be the easiest way to do it.
> 
> Bob
[SNIP]

Section 6.2.20 of the ARM (found in the ./doc/arm directory) says:

6.2.20. view Statement Definition and Usage

The view statement is a powerful new feature of BIND 9 that lets a name
server answer a DNS query differently depending on who is asking. It is
particularly useful for implementing split DNS setups without having to
run multiple servers.

Each view statement defines a view of the DNS namespace that will be
seen by those clients whose IP addresses match the address_match_list of
the view's match-clients clause. The order of the view statements is
significant-a client query will be resolved in the context of the first
view whose match-clients list matches the client's IP address.

Zones defined within a view statement will be only be accessible to
clients that match the view. By defining a zone of the same name in
multiple views, different zone data can be given to different clients,
for example, "internal" and "external" clients in a split DNS setup.

Many of the options given in the options statement can also be used
within a view statement, and then apply only when resolving queries with
that view. When no view-specific value is given, the value in the
options statement is used as a default. Also, zone options can have
default values specified in the view statement; these view-specific
defaults take precedence over those in the options statement. 

Views are class specific. If no class is given, class IN is assumed.
Note that all non-IN views must contain a hint zone, since only the IN
class has compiled-in default hints.

If there are no view statements in the config file, a default view that
matches any client is automatically created in class IN, and any zone
statements specified on the top level of the configuration file are
considered to be part of this default view. If any explicit view
statements are present, all zone statements must occur inside view
statements.

Here is an example of a typical split DNS setup implemented using view
statements.view "internal" {
               // This should match our internal networks.
      match-clients { 10.0.0.0/8; };
               // Provide recursive service to internal clients only.
      recursion yes;
               // Provide a complete view of the example.com zone
               // including addresses of internal hosts.
      zone "example.com" {
            type master;
            file "example-internal.db";
      };
};
view "external" {
      match-clients { any; };
               // Refuse recursive service to external clients.
      recursion no;
               // Provide a restricted view of the example.com zone
               // containing only publicly accessible hosts.
      zone "example.com" {
           type master;
           file "example-external.db";
      };
};

Regards,
Jim 

PS 'doc' on best.com reports "no errors or warning". Congratulations!


More information about the bind-users mailing list