Split DNS

Taken from http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch04.html#id2549203

Setting up different views, or visibility, of the DNS space to internal and external resolvers is usually referred to as a Split DNS setup. There are several reasons an organization would want to set up its DNS this way.

One common reason for setting up a DNS system this way is to hide "internal" DNS information from "external" clients on the Internet. There is some debate as to whether or not this is actually useful. Internal DNS information leaks out in many ways (via email headers, for example) and most savvy "attackers" can find the information they need using other means.

Another common reason for setting up a Split DNS system is to allow internal networks that are behind filters or in RFC 1918 space (reserved IP space, as documented in RFC 1918) to resolve DNS on the Internet. Split DNS can also be used to allow mail from outside back in to the internal network.

Here is an example of a split DNS setup:

Let's say a company named Example, Inc. (example.com) has several corporate sites that have an internal network with reserved Internet Protocol (IP) space and an external demilitarized zone (DMZ), or "outside" section of a network, that is available to the public.

Example, Inc. wants its internal clients to be able to resolve external hostnames and to exchange mail with people on the outside. The company also wants its internal resolvers to have access to certain internal-only zones that are not available at all outside of the internal network.

In order to accomplish this, the company will set up two sets of name servers. One set will be on the inside network (in the reserved IP space) and the other set will be on bastion hosts, which are "proxy" hosts that can talk to both sides of its network, in the DMZ.

The internal servers will be configured to forward all queries, except queries for site1.internal, site2.internal, site1.example.com, and site2.example.com, to the servers in the DMZ. These internal servers will have complete sets of information for site1.example.com, site2.example.com, site1.internal, and site2.internal.

To protect the site1.internal and site2.internal domains, the internal name servers must be configured to disallow all queries to these domains from any external hosts, including the bastion hosts.

The external servers, which are on the bastion hosts, will be configured to serve the "public" version of the site1 and site2.example.com zones. This could include things such as the host records for public servers (www.example.com and ftp.example.com), and mail exchange (MX) records (a.mx.example.com and b.mx.example.com).

In addition, the public site1 and site2.example.com zones should have special MX records that contain wildcard (`*') records pointing to the bastion hosts. This is needed because external mail servers do not have any other way of looking up how to deliver mail to those internal hosts. With the wildcard records, the mail will be delivered to the bastion host, which can then forward it on to internal hosts.

Here's an example of a wildcard MX record:

*   IN MX 10 external1.example.com.

Now that they accept mail on behalf of anything in the internal network, the bastion hosts will need to know how to deliver mail to internal hosts. In order for this to work properly, the resolvers on the bastion hosts will need to be configured to point to the internal name servers for DNS resolution.

Queries for internal hostnames will be answered by the internal servers, and queries for external hostnames will be forwarded back out to the DNS servers on the bastion hosts.

In order for all this to work properly, internal clients will need to be configured to query only the internal name servers for DNS queries. This could also be enforced via selective filtering on the network.

If everything has been set properly, Example, Inc.'s internal clients will now be able to:

• Look up any hostnames in the site1 and site2.example.com zones.
• Look up any hostnames in the site1.internal and site2.internal domains.
• Look up any hostnames on the Internet.
• Exchange mail with internal AND external people.

Hosts on the Internet will be able to:

• Look up any hostnames in the site1 and site2.example.com zones.
• Exchange mail with anyone in the site1 and site2.example.com zones.

Here is an example configuration for the setup we just described above. Note that this is only configuration information; for information on how to configure your zone files, see the section called “Sample Configurations”

Internal DNS server config:

acl internals { 172.16.72.0/24; 192.168.1.0/24; };

acl externals { bastion-ips-go-here; };

options {
   ...
   ...
   forward only;
   forwarders {                                // forward to external servers
       bastion-ips-go-here;
   };
   allow-transfer { none; };                   // sample allow-transfer (no one)
   allow-query { internals; externals; };      // restrict query access
   allow-recursion { internals; };             // restrict recursion
   ...
   ...
};

zone "site1.example.com" {                      // sample master zone
 type master;
 file "m/site1.example.com";
 forwarders { };                               // do normal iterative
                                               // resolution (do not forward)
 allow-query { internals; externals; };
 allow-transfer { internals; };
};

zone "site2.example.com" {                      // sample slave zone
 type slave;
 file "s/site2.example.com";
 masters { 172.16.72.3; };
 forwarders { };
 allow-query { internals; externals; };
 allow-transfer { internals; };
};

zone "site1.internal" {
 type master;
 file "m/site1.internal";
 forwarders { };
 allow-query { internals; };
 allow-transfer { internals; }
};

zone "site2.internal" {
 type slave;
 file "s/site2.internal";
 masters { 172.16.72.3; };
 forwarders { };
 allow-query { internals };
 allow-transfer { internals; }
};

External (bastion host) DNS server config:

acl internals { 172.16.72.0/24; 192.168.1.0/24; };

acl externals { bastion-ips-go-here; };

options {
 ...
 ...
 allow-transfer { none; };                     // sample allow-transfer (no one)
 allow-query { internals; externals; };        // restrict query access
 allow-recursion { internals; externals; };    // restrict recursion
 ...
 ...
};

zone "site1.example.com" {                      // sample slave zone
 type master;
 file "m/site1.foo.com";
 allow-query { any; };
 allow-transfer { internals; externals; };
};

zone "site2.example.com" {
 type slave;
 file "s/site2.foo.com";
 masters { another_bastion_host_maybe; };
 allow-query { any; };
 allow-transfer { internals; externals; }
};

In the resolv.conf (or equivalent) on the bastion host(s):

search ...
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4