Split Horizon using views

View based Split Horizon

The BIND DNS configuration provides the following functionality:

1. Assume we want geographic users to get the lowest possible latency from a web service with a name of www.example.com
2. Assume we have a single worldwide email server called mail.example.com
3. 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.
4. 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.
5. All other originations will default to a www.example.com at 192.168.1.2
6. For simplicity we assume an authoritative only server is being configured.

View based Authoritative Only DNS Server

View based Authoritative Only Name Server Configuration

The BIND DNS configuration provides the following functionality:

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

Authoritative Only DNS Server

Authoritative Only Name Server Configuration

The BIND DNS configuration provides the following functionality:

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

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.

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 users 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:

1. 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.

2. 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

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

Forwarding Name Server Configuration

The BIND DNS configuration provides the following functionality:

1. The name server is not a 'master' or 'slave' for any domain
2. provides 'caching' services for all domains
3. forwards all queries to a remote DNS from all local resolvers (Global forwarding)
4. 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.

Caching Only DNS Server

Caching Only Name Server Configuration

The BIND DNS configuration provides the following functionality:

1. The name server is not a 'master' or 'slave' for any domain
2. provides 'caching' services for all domains
3. provides query services to local resolvers only (a closed DNS - note in configuration file shows how to Open the server if required)

Slave (Secondary) DNS Server

Slave Name Server Configuration

The BIND DNS configuration provides the following functionality:

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

Master (Primary) DNS Server

Master Name Server Configuration

The BIND DNS configuration provides the following functionality:

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

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.

1. All zone files are placed in /var/named/ (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:

   1. /var/named/master - master zone files
   2. /var/named/slave - slave zones files
   3. /var/named/views - where views are used

2. 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.

3. 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.

4. The root server zone file is called root.servers (typically called named.ca or named.root in BIND distributions).

5. The reverse mapping file name uses the subnet number and .rev i.e.. 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.

6. 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).

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:

1. A named.conf file describing the functionality of the BIND system. The entries in this file are fully described.
2. 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.
3. Depending on the configuration one or more required zone files describing the 'localhost' and root name servers.

Understanding and configuration of the regions

Provides DNS servers DNS namespace to be divided into zones that store information about the name of one or more DNS domains. The region become a reliable source for information about each analysis the domain name listed in this area. This lesson introduces you to the DNS zones and how they are configured.