• 6.1.1 Zone File Naming Convention

6. DNS Sample BIND Configurations


This chapter provides a number of BIND configuration samples.


Running any DNS server that supports recursive queries for external users (an 
Open DNS) is a bad idea. While it may look like a friendly and neighbourly thing
to do it carries with it a possible threat from DDoS attacks and an increased 
risk of cache poisoning. The various configurations have been modified to 
reflect this.


6.1 Sample BIND Configuration Overview


This chapter provides sample configurations and descriptions for each of the DNS
types previously described. A BIND systems consists of the following parts:

A named.conf file describing the functionality of the BIND system. The 
entries in this file are fully described.
Depending on the configuration one or more zone files describing the domains
being managed. The entries in zone files are fully described. Zone files contain
Resource Records which are fully described.
Depending on the configuration one or more required zone files describing 
the 'localhost' and root name servers.

Many BIND/DNS configurations are schizophrenic in nature - they may be 'masters'
for some zones, 'slaves' for others, forward others and provide caching services
for all comers. Where possible we cover alternate configurations or at least 
note the alternate configurations.


There are many in the DNS world who say that mixing DNS functionality in a 
single instance of BIND is a Very Bad Idea™ and leads to increased security 
risks. Such folks tend to get especially vocal about mixing ANY master or slave
zones with caching (recursive) services. Such blanket advice overlooks pragmatic
considerations. In a high volume DNS scenario it is both crazy and dangerous to
run anything other than an authoritative only server (with no caching/recursive
support). When small or modest volume DNS servers are used, and provided that 
the DNS is CLOSED, the modest increase in security threat is usually more than 
offset by operational benefits.


All the configuration files are deliberately kept simple - links are provided to
the various sections that will describe more advanced parameters as appropriate.
Comments are included in the files to describe functionality. The configuration 
used throughout is:

Two name servers are used one internal (ns1) and one external (ns2) to the 
domain
The mail service is external to the domain (provided by a third party)
FTP and WWW services are provided by the same host
There are two hosts named bill and fred
The host address are all in the class C private (RFC 1918) address range 
192.168.0.0 (a slightly artificial case)



6.1.1 Zone File Naming Convention


Everyone has their own ideas on a good naming convention and thus something that
is supposed to be useful becomes contentious.

Here is a convention that is in daily use. Its sole merits are; it is a 
convention; it makes sense to its authors.
All zone files are placed in /etc/bind/ (for Windows users this would be 
%systemroot%\system32\drivers\etc). The base directory contains all the 
housekeeping zone files (e.g. localhost, reverse-mapping, root.servers etc.) 
with a subdirectory structure used as follows:
        
/etc/bind/master - master zone files
        
/etc/bind/slave - slave zones files
        
/etc/bind/views - where views are used 
    
master files are named master.example.com (or master.example.net etc.) 
if its a sub-domain it will be master.sub-domain.example.com etc.
    
slave zone files are named slave.example.com (or slave.example.ca etc.) 
if its a sub-domain it will be slave.sub-domain.example.com etc.
    
The root server zone file is called root.servers (typically called 
named.ca or named.root in BIND distributions).
    
The reverse mapping file name uses the subnet number and .rev, that is, 
if the zone is '23.168.192.IN-ADDR.ARPA' the file is called 192.168.23.rev to save
having to reverse the digits at 3AM in a blind panic.
    
The 'localhost' zone file is called master.localhost (typically called 
localhost.zone on BIND distributions). The reverse mapping file is called 
localhost.rev (typically called named.local in BIND distributions).


Note:
For most Linux distributions you have a small overhead at the beginning to
rename the supplied files but the author considers it worthwhile in the long 
run to avoid confusion.

Final point on this topic: Whatever your convention be rigorous in its 
application and don't get hung up on standard distribution file names, make them
useful to you. The names were not handed down on tablets of stone.



6.2 Master (Primary) DNS Server


The functionality of the master name server was previously described.


Master Name Server Configuration


The BIND DNS configuration provides the following functionality:

'master' DNS for example.com
provides 'caching' services for all other domains
provides recursive query services to local resolvers only (a closed DNS - 
note in configuration file shows how to Open the server if required though 
this should only be done after careful consideration of all consequences)

The BIND 'named.conf' is as follows (click to look at any file):

// MASTER & CACHING NAME SERVER for EXAMPLE, INC.
// MAINTAINED BY: ME MYSELF ALONE
// CHANGELOG:
// 1. 9 july 2003 - DID SOMETHING
// 2. 16 july 2003 - DID SOMETHING ELSE
// 3. 23 july 2003 - DID SOMETHING MORE
//
options 
{
    directory "/var/named";
    // VERSION STATEMENT - INHIBITED FOR SECURITY
    // (AVOIDS HACKING ANY KNOWN WEAKNESSES)
    version "get lost";
    // OPTIONAL - DISABLES ALL TRANSFERS
    // SLAVES ALLOWED IN ZONE CLAUSES
    allow-transfer { "none"; };
    // CLOSED DNS - PERMITS ONLY LOCAL IPs TO ISSUE RECURSIVE QUERIES
    // REMOVE IF AN OPEN DNS REQUIRED TO SUPPORT ALL USERS
    // OR ADD ADDITIONAL RANGES 
    allow-recursion { 192.168.3.0/24; };
};
//
// LOG TO /var/log/named/example.log ALL EVENTS FROM 
// INFO UP IN SEVERITY (NO DEBUG)
// DEFAULTS TO USE 3 FILES IN ROTATION
// BIND 8.x logging MUST COME FIRST IN THIS FILE
// BIND 9.X PARSES THE WHOLE FILE BEFORE USING THE LOG
// FAILURE MESSAGES UP TO THIS POINT ARE IN (syslog) 
// TYPICALLY /var/log/messages
//
logging
{
    channel example_log
    {
        file "/var/log/named/example.log" versions 3 size 2m;
        severity info;
        print-severity yes;
        print-time yes;
        print-category yes;
    };
    category default
    {
        example_log;
    };
};
// REQUIRED ZONE FOR RECURSIVE QUERIES
zone "." 
{
    type hint;
    file "root.servers";
};
zone "example.com" in
{
    type master;
    file "master/master.example.com";
    // ENABLE SLAVES ONLY
    allow-transfer { 192.168.23.1; 192.168.23.2; };
};
// REQUIRED LOCAL HOST DOMAIN
zone "localhost" in
{
    type master;
    file "master.localhost";
    allow-update{ none; };
};
// LOCALHOST REVERSE MAP
zone "0.0.127.in-addr.arpa" in
{
    type master;
    file "localhost.rev";
    allow-update{ none; };
};
// REVERSE MAP FOR CLASS C 192.168.0.0
zone "0.168.192.IN-ADDR.ARPA" in
{
    type master;
    file "192.168.0.rev";
};
    
A Master server without the caching service is shown under Authoritative Only.



6.3 Slave (Secondary) DNS Server

The functionality of the slave name server was previously described.



Slave Name Server Configuration

The BIND DNS configuration provides the following functionality:

'slave' DNS for example.com
provides 'caching' services for all other domains
provides recursive query services to local resolvers only (a closed DNS - 
note in configuration file shows how to Open the server if required)


Note: 
Since we are defining the slave the alternate sample file is used throughout 
this example configuration with all servers being internal to the domain.

The BIND 'named.conf' is as follows (click to look at any file):

// SLAVE & CACHING NAME SERVER for EXAMPLE, INC.
// MAINTAINED BY: ME MYSELF ALONE
// CHANGELOG:
// 1.  9 july 2003 - DID SOMETHING
// 2. 16 july 2003 - DID SOMETHING ELSE
// 3. 23 july 2003 - DID SOMETHING MORE
//
options 
{
    directory "/var/named";
    // VERSION STATEMENT - INHIBITED FOR SECURITY
    // (AVOIDS HACKING ANY KNOWN WEAKNESSES)
    version "not currently available";
    // ALLOWS NOTIFIES ONLY FROM MASTER
    allow-notify { 192.168.0.1 };
    // DISABLES ALL ZONE TRANSFER REQUESTS
    allow-transfer{ "none" };
    // CLOSED DNS - PERMITS ONLY LOCAL IPs TO ISSUE RECURSIVE QUERIES 
    // REMOVE IF AN OPEN DNS REQUIRED TO SUPPORT ALL USERS 
    // OR ADD ADDITIONAL RANGES 
    allow-recursion { 192.168.3.0/24; };
};
//
// LOG TO /var/log//named/example.log ALL EVENTS 
// FROM INFO UP IN SEVERITY (NO DEBUG)
// DEFAULTS TO USE 3 FILES IN ROTATION
// BIND 8.x LOGGING MUST COME FIRST IN THIS FILE
// BIND 9.x PARSES THE WHOLE FILE BEFORE USING THE LOG
// FAILURE MESSAGES UP TO THIS POINT ARE IN (syslog)
// TYPICALLY /var/log/messages
//
logging
{
    channel example_log
    {
        file "/var/log/named/example.log" versions 3 size 2m;
        severity info;
        print-severity yes;
        print-time yes;
        print-category yes;
    };
    category default
    {
        example_log;
    };
};
// REQUIRED ZONE FOR RECURSIVE QUERIES
zone "." 
{
    type hint;
    file "root.servers";
};
// SEE NOTES BELOW
zone "example.com" in
{
    type slave;
    file "slave/slave.example.com";
    masters { 192.168.0.1; };
};
// REQUIRED LOCAL HOST DOMAIN
zone "localhost" in
{
    type master;
    file "pri.localhost";
    allow-update{ none; };
};
// LOCALHOST REVERSE MAP
zone "0.0.127.in-addr.arpa" in
{
    type master;
    file "localhost.rev";
    allow-update{ none; };
};
// REVERSE MAP FOR CLASS C 192.168.0.0 (SEE NOTES)
zone "0.168.192.IN-ADDR.ARPA" IN 
{
    type slave;
    file "sec.192.168.0.rev";
    masters { 192.168.0.1; };
};

Notes: 
The slave zone file 'slave/slave.example.com' is optional and allows storage
of the current records - minimising load when named is restarted. To create this
file initially just open and save an empty file. BIND will complain the first 
time it loads but not thereafter.
The reverse map for the network (zone 0.168.192.IN-ADDR.ARPA) is defined as
a slave for administrative convenience - you need to maintain only one copy - 
but it could be defined as a 'master' with a standard reverse map format.
A single 'masters' IP address is used specifying ns1.example.com.



6.4 Caching Only DNS Server

The functionality of the Caching Only name server was previously described.


Caching Only Name Server Configuration

The BIND DNS configuration provides the following functionality:

The name server is not a 'master' or 'slave' for any domain
provides 'caching' services for all domains
provides query services to local resolvers only (a closed DNS - note in 
configuration file shows how to Open the server if required)
The BIND 'named.conf' is as follows (click to look at any file):


// CACHING NAME SERVER for EXAMPLE, INC.
// maintained by: me myself alone
// CHANGELOG:
// 1.  9 july 2003 - DID SOMETHING
// 2. 16 july 2003 - DID SOMETHING ELSE
// 3. 23 july 2003 - DID SOMETHING MORE
//
options 
{
    directory "/var/named";
    // VERSION STATEMENT - INHIBITED FOR SECURITY
    // (AVOIDS HACKING ANY KNOWN WEAKNESSES)
    version "not currently available";
    // DISABLES ALL ZONE TRANSFER REQUESTS
    allow-transfer{ "none"; };
    // CLOSED DNS - PERMITS ONLY LOCAL IPs TO ISSUE QUERIES 
    // REMOVE IF AN OPEN DNS REQUIRED TO SUPPORT ALL USERS 
    // OR ADD ADDITIONAL IP RANGES 
    // IN THIS CASE EITHER allow-query OR allow-recursion CAN BE USED
    allow-query { 192.168.3.0/24; };
};
//
// LOG TO /var/log/example.log ALL EVENTS 
// FROM INFO UP IN SEVERITY (NO DEBUG)
// DEFAULTS TO USE 3 FILES IN ROTATION
// BIND 8.x LOGGING MUST COME FIRST IN THIS FILE
// BIND 9.x PARSES THE WHOLE FILE BEFORE USING THE LOG
// FAILURE MESSAGES UP TO THIS POINT ARE IN (syslog)
// TYPICALLY /var/log/messages
//
logging
{
    channel example_log
    {
        file "/var/log/named/example.log" versions 3 size 2m;
        severity info;
        print-severity yes;
        print-time yes;
        print-category yes;
    };
    category default
    {
        example_log;
    };
};
// REQUIRED ZONE FOR RECURSIVE QUERIES
zone "." 
{
    type hint;
    file "root.servers";
};
// REQUIRED LOCAL HOST DOMAIN
zone "localhost" in
{
    type master;
    file "master.localhost";
    allow-update{ none; };
};
// LOCALHOST REVERSE MAP
zone "0.0.127.in-addr.arpa" in
{
    type master;
    file "localhost.rev";
    allow-update{ none; };
};

Notes: 
The Caching only name server contains no zones (other than 'localhost') with
'master' or 'slave' types.
The reverse map zone has been omitted since it assumed that an external body
(ISP etc) has the master domain DNS and is therefore also responsible for the 
reverse map. It could be added if required for local operational reasons.



6.5 Forwarding (a.k.a. Proxy, Client, Remote) 
DNS Server

The functionality of the Forwarding name server was previously described.


Forwarding Name Server Configuration

The BIND DNS configuration provides the following functionality:

The name server is not a 'master' or 'slave' for any domain
provides 'caching' services for all domains
forwards all queries to a remote DNS from all local resolvers (Global 
forwarding)
limits query services to local resolvers only - this statement is designed 
to limit forwarding which both negates the effect of the forwarding server by 
increasing traffic loads and passes the bogus requests to the remote DNS 
potentially causing a DoS/DDos attack.

The BIND 'named.conf' is as follows (click to look at any file):


// FORWARDING & CACHING NAME SERVER for EXAMPLE, INC.
// maintained by: me myself alone
// CHANGELOG:
// 1.  9 july 2003 - DID SOMETHING
// 2. 16 july 2003 - DID SOMETHING ELSE
// 3. 23 july 2003 - DID SOMETHING MORE
//
options 
{
    directory "/var/named";
    // VERSION STATEMENT - INHIBITED FOR SECURITY
    // (AVOIDS HACKING ANY KNOWN WEAKNESSES)
    version "not currently available";
    forwarders { 10.0.0.1; 10.0.0.2; };
    forward only;
    // DISABLES ALL ZONE TRANSFER REQUESTS
    allow-transfer { "none"; };
    // CLOSED DNS - PERMITS ONLY LOCAL IPs TO ISSUE QUERIES 
    // REMOVE IF AN OPEN DNS REQUIRED TO SUPPORT ALL USERS 
    // OR ADD ADDITIONAL IP RANGES 
    // IN THIS CASE EITHER allow-query OR allow-recursion CAN BE USED
    allow-query {192.168.3.0/24; };
};
// LOG TO /var/log/example.log ALL EVENTS FROM
// INFO UP IN SEVERITY (NO DEBUG)
// DEFAULTS TO USE 3 FILES IN ROTATION
// BIND 8.x LOGGING MUST COME FIRST IN THIS FILE
// BIND 9.x PARSES THE WHOLE FILE BEFORE USING THE LOG
// FAILURE MESSAGES UP TO THIS POINT ARE IN (syslog)
// TYPICALLY /var/log/messages
logging
{
    channel example_log
    {
        file "/var/log/named/example.log" versions 3;
        severity info;
        print-severity yes;
        print-time yes;
        print-category yes;
    };
    category default
    {
        example_log;
    };
};
// REQUIRED LOCAL HOST DOMAIN
zone "localhost" in
{
    type master;
    file "pri.localhost";
    allow-update{ none; };
};
// LOCALHOST REVERSE MAP
zone "0.0.127.in-addr.arpa" in
{
    type master;
    file "localhost.rev";
    allow-update{ none; };
};

Notes:
The Forwarding name server typically contains no zones (other than 'localhost')
with 'master' or 'slave' types.
The reverse map zone has been omitted since it assumed that an external body
(ISP etc) has the master domain DNS and is therefore also responsible for the 
reverse map. It could be added if required for local operational reasons.
The forward option must be used in conjunction with a forwarders option. The
value 'only' will override 'recursive query' behaviour.
Since all queries are forwarded the root servers zone ('type hint') can be 
omitted.
Forwarding can be done on a zone basis in which case the values defined 
override the global options.




6.6 Stealth (a.k.a. Split or DMZ) DNS Server

The functionality of the Stealth name server was previously described. The 
following diagram illustrates the conceptual view of a Stealth (a.k.a. Split) 
DNS server system.


Split (Stealth) Server configuration


Figure 6.1 Split/Stealth Server configuration

The key issue in a 'Stealth' (a.k.a. Split) DNS system is that there is a clear
line of demarcation between the 'Internal' Stealth server(s) and the 'External'
or Public DNS servers(s). The primary difference in configuration is the 
'Stealth' Servers will provide a comprehensive set of services to internal user
to include caching and recursive queries and would be configured as a typical 
Master DNS, while the External server may provide limited services and would 
typically be configured as an Authoritative Only DNS server.

There are two critical points:

The zone file for the 'Stealth' server will contain both public and private
hosts, whereas the 'Public' server's master zone file will contain only public 
hosts.
To preserve the 'Stealth' nature it is vital that the PUBLIC DNS 
configuration does not include options such as 'master', 'allow-notify',
'allow-transfer', etc. with references to the IP of the 'Stealth' server. If the
Stealth servers IP where to appear in the Public DNS server and its file system
were to be compromised the attacker could gain more knowledge about the 
organisation - they can penetrated the 'veil of privacy' by simply inspecting 
the 'named.conf file.

    There are a number of articles which suggest that the view statement may be
used to provide similar functionality using a single server. This does not 
address the problem of the DNS host system being compromised and by simple 
'named.conf' file inspection additional data about the organisation being 
discovered. In a secure environment 'view' does not provide a 'Stealth DNS' 
solution if there is any possibility that a filesystem compromise can happen.




6.7 Authoritative Only DNS Server

The functionality of the Authoritative name server was previously described. If
security is not the primary requirement then the view statement may be used to 
provide 'Authoritative only' services to external users and more comprehensive 
services to internal users.

The configuration examples shown for authoritative only DNS servers all show the
zones as being type master;. Thus if two (or more) DNS servers are being used 
the master zone files would have to be made available separately to all the 
servers by an out-of-band process (using, say, SFTP). In general this is the 
safest configuration. In situations where the zone files are highly dynamic, 
practical considerations may require that one or all of the zones be slaved from
a single source. Zone transfer operations use TCP and are thus vulnerable to a 
new set of security and DoS threats. Avoid this configuration if possible, if 
not, as minimum secure the transfers with allow-transfer statements in the 
master zone clause and it may be worth considering use of TSIG to authenticate 
zone transfers.

An example configuration is shown below.


Authoritative Only Name Server Configuration

The BIND DNS configuration provides the following functionality:

'master' DNS for example.com
does NOT provide 'caching' services for any other domains
does NOT provide recursive query services for all resolvers (Iterative only)
optimised for maximum performance

The BIND 'named.conf' is as follows (click to look at any file):

// AUTHORITATIVE ONLY NAME SERVER for EXAMPLE, INC.
// MAINTAINED BY: ME MYSELF ALONE
// CHANGELOG:
// 1.  9 july 2003 - DID SOMETHING
// 2. 16 july 2003 - DID SOMETHING ELSE
// 3. 23 july 2003 - DID SOMETHING MORE
//
options 
{
    directory "/var/named";
    // VERSION STATEMENT - INHIBITED FOR SECURITY
    // (AVOIDS HACKING ANY KNOWN WEAKNESSES)
    version "not currently available";
    // DISABLE ALL RECURSION - AUTHORITATIVE ONLY
    recursion no;
    // DISABLES ALL ZONE TRANSFER REQUESTS IN THIS CASE 
    // FOR PERFORMANCE NOT SECURITY REASONS
    allow-transfer{ none; };
};
//
// LOG TO /var/log/example.log ALL EVENTS
// FROM INFO UP IN SEVERITY (NO DEBUG)
// DEFAULTS TO USE 3 FILES IN ROTATION
// BIND 8.x LOGGING MUST COME FIRST IN THIS FILE
// BIND 9.x PARSES THE WHOLE FILE BEFORE USING THE LOG
// FAILURE MESSAGES UP TO THIS POINT ARE IN (syslog)
// TYPICALLY /var/log/messages
//
logging
{
    channel example_log
    {
        file "/var/log/named/example.log" versions 3 size 2m;
        severity info;
        print-severity yes;
        print-time yes;
        print-category yes;
    };
    category default
    {
        example_log;
    };
};
zone "example.com" in
{
    type master;
    file "master/master.example.com";
};
// REVERSE MAP FOR CLASS C 192.168.0.0
zone "0.168.192.IN-ADDR.ARPA" in
{
    type master;
    file "192.168.0.rev";
};
// REQUIRED LOCAL HOST DOMAIN
zone "localhost" in
{
    type master;
    file "master.localhost";
    allow-update{ none; };
};
// LOCALHOST REVERSE MAP
zone "0.0.127.in-addr.arpa" in
{
    type master;
    file "localhost.rev";
    allow-update{ none; };
};

Notes:
The reverse mapping zone (zone "0.168.192.IN-ADDR.ARPA" ) was originally 
omitted from this server - given the use of reverse look-up by anti-spam systems
we have restored the reverse look-up zone. It would - in a perfect world without
spam - typically not be present on a performance oriented server.

BIND provides three more parameters to control caching, max-cache-size and 
max-cache-ttl neither of which will have much effect on performance in the above
case and allow-recursion which uses a list of hosts that are permitted to use 
recursion (all others are not) - a kind of poor man's 'view'.



6.8 View based Authoritative Only DNS Server
The functionality of the Authoritative name server was previously described. If
security is not the primary requirement then the view clause may be used to 
provide 'Authoritative only' services to external users and more comprehensive 
services to internal users.



View based Authoritative Only Name Server 
Configuration

The BIND DNS configuration provides the following functionality:

'master' DNS for example.com
does NOT provide 'caching' services for any external users
does NOT provide recursive query services for any external resolvers 
(Iterative only)
provides 'caching' services for internal users
provides recursive query services for internal users

The BIND 'named.conf' is as follows (click to look at any file):

// VIEW BASED AUTHORITATIVE ONLY NAME SERVER for EXAMPLE, INC.
// MAINTAINED BY: ME MYSELF ALONE
// CHANGELOG:
// 1.  9 july 2003 - DID SOMETHING
// 2. 16 july 2003 - DID SOMETHING ELSE
// 3. 23 july 2003 - DID SOMETHING MORE
//
// GLOBAL OPTIONS
options 
{
    directory "/var/named";
    // VERSION STATEMENT - INHIBITED FOR SECURITY
    // (AVOIDS HACKING ANY KNOWN WEAKNESSES)
    version "not currently available";
};
//
// LOG TO /var/log/example.log ALL EVENTS
// FROM INFO UP IN SEVERITY (NO DEBUG)
// DEFAULTS TO USE 3 FILES IN ROTATION
// BIND 8.x LOGGING MUST COME FIRST IN THIS FILE
// BIND 9.x PARSES THE WHOLE FILE BEFORE USING THE LOG
// FAILURE MESSAGES UP TO THIS POINT ARE IN (syslog)
// TYPICALLY /var/log/messages
//
logging
{
    channel example_log
    {
        file "/var/log/named/example.log" versions 3 size 2m;
        severity info;
        print-severity yes;
        print-time yes;
        print-category yes;
    };
    category default
    {
        example_log;
    };
};
// PROVIDE RECURSIVE QUERIES AND CACHING FOR INTERNAL USERS
view "goodguys" 
{
    match-clients { 192.168.0.0/24; }; // OUR NETWORK
    recursion yes;
    // REQUIRED ZONE FOR RECURSIVE QUERIES
    zone "." 
    {
        type hint;
        file "root.servers";
    };
    zone "example.com" 
    {
        type master;
        // PRIVATE ZONE FILE INCLUDING LOCAL HOSTS
        file "view/master.example.com.internal";
    };
    // REQUIRED LOCAL HOST DOMAIN
    zone "localhost" in
    {
        type master;
        file "master.localhost";
        allow-update{ none; };
    };
    // LOCALHOST REVERSE MAP
    zone "0.0.127.in-addr.arpa" in
    {
        type master;
        file "localhost.rev";
        allow-update{ none; };
    };
}; // END VIEW

// EXTERNAL HOSTS VIEW
view "badguys" 
{
    match-clients { "any"; }; // ALL OTHER HOSTS
    // RECURSION NOT SUPPORTED
    recursion no;
    zone "example.com" 
    {
        type master;
         // ONLY PUBLIC HOSTS
        file "view/master.example.com.external";
    };
}; // END VIEW

Notes:
All the required zones must be declared in each view.
The 'goodguys' view contains the root.servers, 'localhost' and reverse 
mapping file.
The 'badguys' view contains only the required zone files for which we will 
answer authoritatively.
The 'badguys' view may contain an edited version of the reverse map file.
Slave DNS Servers with View Clause When using Slave servers with view clauses it
is important to recall that, even when NOTIFY is used, the Slave always 
initiates the zone tranfer operation using an INCOMING DNS operation (TCP on 
Port 53 normally). To ensure the correct domain is transferred the 
match-clients and/or match-destinations statements associated with the views 
must ensure that the requesting Slave server's IP is directed to the view 
containing the zone file that should be tranferred.



6.9 Split Horizon using view clause

The functionality of the Split Horizon DNS was previously described. The view 
clause may be used to return different IP addresses to provide, say, 
geographically dispersed users with minimum access latency or even a level of 
load-balancing if you understand the service source-ip access profile (in this 
case the source-ip ranges in the example would be based on some analysis of 
incoming traffic not just geographic location).


View based Split Horizon

The BIND DNS configuration provides the following functionality:

Assume we want geographic users to get the lowest possible latency from a 
web service with a name of www.example.com
Assume we have a single worldwide email server called mail.example.com
Assume addresses 172.16.x.x originate in Mordor and we want them to be 
serviced by a local web server (172.16.1.1) we have installed in that land.
Assume addresses 172.15.x.x and 172.14.x.x originate in Gondor and we want 
them to be serviced by a local web server (17.15.1.1) we have installed in that
land.
All other originations will default to a www.example.com at 192.168.1.2
For simplicity we assume an authoritative only server is being configured.

The BIND 'named.conf' is as follows (click to look at any file):


// VIEW BASED GEOGRAPHIC DNS SERVER for EXAMPLE, INC.
// MAINTAINED BY: ME MYSELF ALONE
// CHANGELOG:
// 1.  9 july 2009 - DID SOMETHING
// 2. 16 july 2009 - DID SOMETHING ELSE
// 3. 23 july 2009 - DID SOMETHING MORE
//
// GLOBAL OPTIONS
options 
{
  directory "/var/named";
  // VERSION STATEMENT - INHIBITED FOR SECURITY
  // (AVOIDS HACKING ANY KNOWN WEAKNESSES)
  version "Name is Bind, James Bind";
  // AUTHORS NOTE: NO IDEA WHO CAME UP WITH THE CLEVER TEXT BUT IF YOU EMAIL 
  // WE'D BE MORE THAN HAPPY TO CREDIT IT YOU - YOU DESERVE IT
  allow-update{ none; };  // DEFAULTED IF NOT PRESENT
  recursion no;         // AUTHORITATIVE ONLY
};
//
// LOG TO /var/log/example.log ALL EVENTS FROM 
// INFO UP IN SEVERITY (NO DEBUG)
// DEFAULTS TO USE 3 FILES IN ROTATION
// BIND 9.x PARSES THE WHOLE FILE BEFORE USING THE LOG
// FAILURE MESSAGES UP TO THIS POINT ARE IN (syslog)
// TYPICALLY /var/log/messages
//
logging
{
    channel example_log
    {
       file "/var/log/named/example.log" versions 3 size 2m;
       severity info;
       print-severity yes;
       print-time yes;
       print-category yes;
    };
    category default
    {
       example_log;
    };
};
// MAP SERVICE TO GEOGRAPHIC ORIGINATION
view "gondor" 
{
    match-clients { 172.15/16; 172.14/16; }; // ORIGINATE IN GONDOR
    zone "example.com" 
    {
        type master;
        // ZONE FILE WILL RETURN www.example.com = 172.15.1.1
        file "view/master.example.com.gondor";
    };
}; // END VIEW

view "mordor" 
    {
    match-clients { 172.16/16; }; // ORIGINATE IN MORDOR
    zone "example.com" 
    {
        type master;
        // ZONE FILE WILL RETURN www.example.com = 172.16.1.1
        file "view/master.example.com.mordor";
    };
}; // END VIEW

// DEFAULT FOR EVERYTHING ELSE LIES IN A DEFAULT VIEW
view "default"
{
    match-clients { "any"; }; // MUST BE IN THE LAST CLAUSE
    zone "example.com" 
    {
        type master;
        // ZONE FILE WILL RETURN www.example.com WITH DEFAULT (WORLDWIDE) IP
        file "view/master.example.com.default";
    };
};

Notes:
All the required zones must be declared in each view.
For simplicity of configuration an authoritative only server is assumed and 
therefore contains no root.servers, 'localhost' or reverse mapping files.
The 'mordor' and 'gondor' view zone files map to a geographically local 
server.
The configuration uses the only the match-clients statement. Two other 
statements, match-destination and match-recursive-only, neither of which is 
applicable in the example, may also be used to select which view is used.

 Previous versions of this sample showed the default zones 
outside the view clauses which worked successfully in the original tests. At 
some point BIND, in its infinite wisdom, removed this feature. The rule, since 
at least BIND 9.5, is - if there is any view clause then all zones must be in 
view clauses.



Slave DNS Servers with View Clause
When using a Slave server with view clauses it is important to recall that, even
when NOTIFY is used, the Slave always initiates the zone tranfer operation using
an INCOMING DNS operation (TCP on Port 53 normally). To ensure the correct 
domain is transferred the match-clients and/or match-destinations statements 
associated with the views must ensure that the requesting Slave server's IP is 
directed to the view containing the zone file that should be tranferred.