Split DNS

This is an updated version of the 2002 edition

Burt Rosenberg
June 2013

Overview

Broadly speaking, computer resources in the department of computer science are divided into internal resources and external resources. External hosts can access external resources by reference to addresses in our global address block. At this time, that block is 192.31.89.0/24. Internal hosts access external resources by having their internal addresses rewritten (using NAT) to an address within the global address block.

Internal hosts always have addresses in the local address block. At this time, that block is 172.16.0.0/12. This block is subdivided into subnets with 4 bit subnet masks according to security level, making a /16 address, however this fact has no relevance for name resolution (using DNS).

The main concept of split dns is that internal hosts are directed to an internal domain name server for name resolution, external hosts are directed to an external domain name server for name resolution.


                         |           |           |
zone:       servers      |    lab    |   public  |  outside
                         |           |           |
                         |           |           |
DNS server: mcclellan    |    brag   |  pickett  | 
             | |         |     |  |  |    | | |  |
             | |               |  |       | | |
             | +--<=========>--+  |       | | +--<========> cs.miami.edu name resolution
             | primary/secondary  |       | |
             |                    |       | |
             +------->------------+-->----+ +--<==========> math.miami.edu servers
              forward non-local resolution    primary/secondary

Nameserver Zones, Primary and Secondary

Each name server serves for one or more domains, called zones. The combined math and cs departments are responsible for the correct functioning of name servers for the following five zones: These are global zones, connected by chains of references to global Internet infrastructure of DNS.

The cs department controls additional local zones, which are not linked to the global Internet infrastructure:

The responses to queries for names depends upon whether the query is resolved in a local or a global context. That is, whether the query is sent to a local or global name server, respectively.

It is customary to provide more than one domain name server for any domain, since the inability to contact a domain name server effectively removes hosts from the Internet. These backups are called secondary name servers, and the automatically download the names database from the primary name server. Since the secondaries download from the primary, a change in the name database takes some time to propagate.

The commands dig NS cs.miami.edu and dig NS math.miami.edu lists the authoritative name servers for the cs and math domains, respectively.

As of June 2013, the answers are:

==========================================

global$ dig ns cs.miami.edu

...

;; QUESTION SECTION:
;cs.miami.edu.			IN	NS

;; ANSWER SECTION:
cs.miami.edu.		720	IN	NS	ns-1596.awsdns-07.co.uk.
cs.miami.edu.		720	IN	NS	ns-350.awsdns-43.com.
cs.miami.edu.		720	IN	NS	phantom.math.miami.edu.
cs.miami.edu.		720	IN	NS	ns-641.awsdns-16.net.
cs.miami.edu.		720	IN	NS	ns-1425.awsdns-50.org.
cs.miami.edu.		720	IN	NS	ns1.cs.miami.edu.

==========================================

local$ dig ns cs.miami.edu

...

;; QUESTION SECTION:
;cs.miami.edu.			IN	NS

;; ANSWER SECTION:
cs.miami.edu.		3600	IN	NS	davis.cs.miami.edu.
cs.miami.edu.		3600	IN	NS	mcclellan.cs.miami.edu.

==========================================

global-and-local$ dig ns cs.miami.edu

...


;; QUESTION SECTION:
;math.miami.edu.			IN	NS

;; ANSWER SECTION:
math.miami.edu.		223	IN	NS	miavax.ir.miami.edu.
math.miami.edu.		223	IN	NS	umigw.miami.edu.
math.miami.edu.		223	IN	NS	phantom.math.miami.edu.
math.miami.edu.		223	IN	NS	ns1.cs.miami.edu.

==========================================

global-and-local$ dig ns -x 129.171.34

...

;; QUESTION SECTION:
;34.171.129.in-addr.arpa.	IN	NS

;; ANSWER SECTION:
34.171.129.in-addr.arpa. 3600	IN	NS	miavax.ir.miami.edu.
34.171.129.in-addr.arpa. 3600	IN	NS	ns1.cs.miami.edu.
34.171.129.in-addr.arpa. 3600	IN	NS	phantom.math.miami.edu.
34.171.129.in-addr.arpa. 3600	IN	NS	umigw.miami.edu.


global-and-local$ dig ns -x 192.70.171

...

;; QUESTION SECTION:
;171.70.192.in-addr.arpa.	IN	NS

;; ANSWER SECTION:
171.70.192.in-addr.arpa. 3600	IN	NS	miavax.ir.miami.edu.
171.70.192.in-addr.arpa. 3600	IN	NS	ns1.cs.miami.edu.
171.70.192.in-addr.arpa. 3600	IN	NS	umigw.miami.edu.
171.70.192.in-addr.arpa. 3600	IN	NS	phantom.math.miami.edu.


global-and-local$ dig ns -x 192.31.89

...

;; QUESTION SECTION:
;89.31.192.in-addr.arpa.		IN	NS

;; ANSWER SECTION:
89.31.192.in-addr.arpa.	720	IN	NS	phantom.math.miami.edu.
89.31.192.in-addr.arpa.	720	IN	NS	ns1.cs.miami.edu.
89.31.192.in-addr.arpa.	720	IN	NS	miavax.ir.miami.edu.

==========================================

Client-side resolution

In all unix derivatives, a host learns its domain servers from the file /etc/resolv.conf. Here is a sample such file:


> cat /etc/resolv.conf
domain cs.miami.edu
nameserver 172.20.0.2
nameserver 172.19.0.2

Users of DHCP can receive nameserver information from the DHCP server, and the local DHCP client can edit /etc/resolv.conf to include this information. Problems finding a nameserver can often be diagnosed by looking at this file.

Resolution of names outside of the local domain proceed normally: the Internet's bind tree is traversed to find the name server responsible for the name. Under certain circumstances it is possible that a local name is forced to resolve as if it were queried globally. For instance, www.cs.miami.edu could resolve as either 172.18.0.2 (local) or 192.31.89.3 (global), with the same effect. However this is controlled by the local name server and need not concern the client software.

Administrative notes

The dns system has been setup so that understanding of split dns is optional for users. Internal host, those with a 172.0.0.0/8 address, will have an /etc/resolv.conf directing the host to the internal DNS servers. External hosts, those traversing the Internet DNS tree, will find the external DNS server.

The local cs.miami.edu zone does need certain global names. Names in the cs.miami.edu domain which are not known to sherman will be unresolved. Sherman will not ask jackson for a matching global name, failing a matching local name.

For instance, www.cs.miami.edu could be considered a global name. One way or the other, the local zone server must know this name, or it will not be possible to reference www.cs.miami.edu internally. The perferred method to do this has not been determined. The most straightforward is an A record for www.cs.miami.edu straight to the global IP address of jackson. There are other possibilities.

We have had some problem with jackson, since it lies in the intersection of internal and external name domains. This is of no interest to anyone but system administrators, since this machine is isolated in the public zone. The resolution to the problem is to create the following /etc/host.conf file:

   hosts
   bind
This sends local resolution first to the /etc/hosts file, where it finds internal IP addresses, and then failing that, to the bind system (a.k.a. DNS) for external IP addresses. This feature is largely undocumented before FreeBSD 4.6.

Split DNS allows a machine name to bind to two different addresses. For instance, jackson is both 172.18.0.2 internally and 192.31.89.3 externally. This can be considered more of a fault than a virtue, and is not the justification for Split DNS. Split DNS allows the minimal functionality required for external operation to be placed in the public zone, and a fully functional DNS server placed internally. For instance, the internal DNS supports Dynamic DNS, the external DNS does not.

As a general rule, it should never be that a name gives two different behaviors unless at least one of the behaviors is that of no-response. For example, internally there are local bindings for www.cs.miami.edu and web.cs.miami.edu. The first gives the public web server the second gives the private web server. Therefore the name web.cs.miami.edu should be undefined in the global zone. Internally, web.cs.miami.edu gives a web pages, externally web.cs.miami.edu gives a no-response.

File History

Burt Rosenberg, 1 july 2002
update: 1 august 2002
update: 2 august 2002
update: 22 june 2013